On Sun 25 Nov 2018 at 22:15:57 +0100, Rhialto wrote: > Actually, I would expect X to remain unset (or set as it was before) on > the next line. Just like it works with > > X=1 /some/external/command > > And that is what bash seems to do. Our /bin/{,k}sh however do set X (but > not in the exported environment). This may not be documented in sh(1) but here I find some description: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01 - If the command name is a special built-in utility, variable assignments shall affect the current execution environment. Unless the set -a option is on (see set), it is unspecified: ... Special-built-ins include the colon command: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#colon So what we do in sh conforms, and what bash does doesn't. However this still leaves me unsatisfied. "Special built-ins" seem to be those commands that cannot possibly be implemented as external commands: break colon continue dot eval exec exit export readonly return set shift times trap unset There are two weird things with this list: : doesn't need to be a special built-in at all. It can be implemented perfectly well the same as /usr/bin/true. cd is missing, yet it can't possibly be implemented externally. So I suppose I would amend my proposal to do this in the more sensible way, and make cd special, and : not special. And even for the special built-ins, I find it not obvious that the assignment should work differently. There is nothing won with it. You can as easily write X=1; cd / as X=1 cd / if you want $X to be 1 in the next line. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond
Attachment:
signature.asc
Description: PGP signature