Hopefully the following will illustrate some unexpected behaviour I
discovered:

   michael@cnspc18:~$ dash -c 'noop(){ true;}; x=1; noop; x=broken true; echo "x is now $x"'
   x is now 1
   michael@cnspc18:~$ dash -c 'noop(){ true;}; x=1; noop; x=broken noop; echo "x is now $x"'
   x is now broken

My understanding is that 'x=broken noop' shouldn't make the change to x
permanent. It shouldn't make a different whether the command is a normal
executable versus a shell function, right? o_O

In your example
  $ dash -c 'noop(){ true;}; x=1; noop; x=broken noop; echo "x is now $x"'
  x is now broken
dash's behaviour is what POSIX requires, and the same can be seen with
bash --posix and ksh93. The relevant section is XCU 2.9.5 Function
Definition Command.

The same thing applies to special builtins such as ':', exec and unset.
For example, these two both print 'good':
  dash -c 'x=bad; x=good :; echo $x'
  dash -c 'x=good; x=bad true; echo $x'
Again bash needs --posix here.

The idea behind special-casing some of the builtins is that the special
builtins must always be builtins and are treated like how the original
Bourne shell treated all builtins, while all other utilities may be
implemented as builtins or external programs and are treated like how
the original Bourne shell treated external programs (except that some of
them affect the shell environment in a way only a builtin can).

There is less historical basis for the treatment of assignments on
function calls, as such assignments had no effect whatsoever in the
original Bourne shell.

severity 587741 wishlist
tags 587741 + upstream wontfix
quit

Hi,

Thanks for writing.  Here is an explanation by Jilles Tjoelker. Sorry we
did not cc you on this before:

I'm keeping the report as a reminder to document it, but this behavior
in dash is not likely to change unless POSIX changes (see
http://www.opengroup.org/austin/ if you would like to work on that).

Thanks,
Jonathan