dash, ksh, mksh, and zsh all agree with POSIX. seems like bash is the
exception (so POSIX is at least "right" in their limited sense of
"describe existing behavior").

i've forwarded a version of this question to the POSIX mailing list,
since there are few things that they like to argue about more than
historical shell behaviors :-)

(but i'm expected "WAI, bash is wrong", even though bash makes the most sense.)

On Sun, Jun 9, 2019 at 4:07 PM Rob Landley <[email protected]> wrote:
>
> I've reached the part of the posix shell stuff (section 2.9.1: simple 
> commands)
> that specifies this behavior, and posix is wrong:
>
>   If no command name results, or if the command name is a special built-in or
>   function, 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 as a side-effect of the expansions performed in step 4.
>
> A) This is not what bash does, or has ever done:
>
>   $ hello() { echo boing=$BOING; }
>   $ BOING=123 hello
>   $ echo $BOING
>   $
>
> B) doing it would be STUPID because there's no reason to DO an assignment on 
> the
> same line rather than on the previous line unless you want to constrain the
> lifetime of the variables. (The semicolon character exists, you can do X=y; 
> echo
> $X; It's literally one extra character.)
>
> Rob
> _______________________________________________
> Toybox mailing list
> [email protected]
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Reply via email to