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