Is there any standard that covers the portability of running a command after variable assignment on the same line?
APPLE="cider" echo hi
How portable is something like that? Where will it work and where won't it?
Also: my shell scripts start with #!/bin/sh if that makes any difference.
As long as you're using a POSIX compliant shell, yes.
From the POSIX definition of shell command language: (relevant points in bold)
A "simple command" is a sequence of optional variable assignments and redirections, in any sequence, optionally followed by words and redirections, terminated by a control operator.
When a given simple command is required to be executed (that is, when any conditional construct such as an AND-OR list or a case statement has not bypassed the simple command), the following expansions, assignments, and redirections shall all be performed from the beginning of the command text to the end:
The words that are recognized as variable assignments or redirections according to Shell Grammar Rules are saved for processing in steps 3 and 4.
The words that are not variable assignments or redirections shall be expanded. If any fields remain following their expansion, the first field shall be considered the command name and remaining fields are the arguments for the command.
Redirections shall be performed as described in Redirection.
Each variable assignment shall be expanded for tilde expansion, parameter expansion, command substitution, arithmetic expansion, and quote removal prior to assigning the value.
In the preceding list, the order of steps 3 and 4 may be reversed for the processing of special built-in utilities; see Special Built-In Utilities.
If no command name results, variable assignments shall affect the current execution environment. Otherwise, the variable assignments shall be exported for the execution environment of the command and shall not affect the current execution environment (except for special built-ins).
#!/bin/sh matters. From the POSIX definition of
The sh utility is a command language interpreter that shall execute commands read from a command line string, the standard input, or a specified file. The application shall ensure that the commands to be executed are expressed in the language described in Shell Command Language.
So basically it says that
sh must follow the rules we covered above.
So as long as you're on a POSIX compliant OS, you're good.
shto comply with the standard, it doesn't specify what path
shmust have so
/bin/shis not necessarily the POSIX shell and is actually the legacy Bourne shell on some platforms (essentially Solaris 10 and older nowadays). This won't hurt in this particular variable assignment case as this syntax long predates the POSIX standard. — Oct 24, 2013 at 05:42
/bin/shno. But it does mandate how
shmust behave. That's all that matters. You can't stick something else called
shthere and be POSIX compliant. — Oct 24, 2013 at 12:29
/bin/sh. What is mandatory is when using a compliant path, i.e.,
PATH=$(getconf PATH), running
shwill call the POSIX compliant shell. — Oct 24, 2013 at 13:01
var=x commandsyntax predates POSIX so there is no problem using a non POSIX still Bourne based shell in your case. — Oct 25, 2013 at 04:33
External links referenced by this document: