Unix & Linux
shell posix
Updated Fri, 20 May 2022 04:59:54 GMT

Is it shell portable to run a command on the same line after variable assignment?

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:

  1. The words that are recognized as variable assignments or redirections according to Shell Grammar Rules are saved for processing in steps 3 and 4.

  2. 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.

  3. Redirections shall be performed as described in Redirection.

  4. 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).

Also, yes #!/bin/sh matters. From the POSIX definition of sh:

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.

Comments (5)

  • +0 – A small comment about your last point. While POSIX mandates sh to comply with the standard, it doesn't specify what path sh must have so /bin/sh is 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  
  • +0 – It doesn't mandate that it reside at /bin/sh no. But it does mandate how sh must behave. That's all that matters. You can't stick something else called sh there and be POSIX compliant. — Oct 24, 2013 at 12:29  
  • +0 – This is incorrect. A POSIX compliant operating system is free to provide a non POSIX compliant /bin/sh. What is mandatory is when using a compliant path, i.e., PATH=$(getconf PATH), running sh will call the POSIX compliant shell. — Oct 24, 2013 at 13:01  
  • +0 – Thanks Patrick. To touch on what @jlliagre said, I've read that /bin/sh may be a bourne compatible shell but not necessarily POSIX compatible? Is that true? I installed the heirloom shell (a port of the original bourne shell) and it tested fine with my example. I also tested zsh on Ubuntu just to see what would happen and I didn't get any error like in llua's example. — Oct 24, 2013 at 17:12  
  • +1 – @test As I wrote in my earlier comment, the var=x command syntax predates POSIX so there is no problem using a non POSIX still Bourne based shell in your case. — Oct 25, 2013 at 04:33