tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: X=1 : (was Re: /bin/sh redirect without command failure mode)

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:

  - 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:

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 /

    X=1 cd /

if you want $X to be 1 in the next line.

___ Olaf 'Rhialto' Seibert  -- "What good is a Ring of Power
\X/ rhialto/at/      -- if you're Speak." - Agent Elrond

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index