Very Computer

Is there a POSIX comment on this?  {,k,z}sh return /blah/blah/user,
bash returns foo.  I prefer bash's behaviour, but consensus seems to
be the other way.  Anything in the standard?

Rick.

Before I get a flood of replies telling me I left out the semicolon :-),
the construct
        var=value cmd
is supposed to modify and export the environment variable `var' only for
the invocation of `cmd'.  That is, while `cmd' is running, $var == value,
and when it exits, $var will have its original value.  My most common use
for this is debubbing.  A program checks for a DEBUG environment variable,
modifying it's actions accordingly.  To do a single debug run, I just
do
        DEBUG= cmd

The original posting was concerned with when variable substition is done
on a command line.  In {,k,z}sh, substitution is done before the fork
which sets up the subshell environment, while in bash it appears to be
done after.  My question is: which behaviour is standard?

Rick.

I don't know about posix, but I think that sh,ksh, and zsh get it right.

Quote:>Before I get a flood of replies telling me I left out the semicolon :-),

Of course, putting in the semi-colon will change the behaviour to be as you
wish it to be.

Here's why...

Quote:>The original posting was concerned with when variable substition is done
>on a command line.  In {,k,z}sh, substitution is done before the fork
>which sets up the subshell environment, while in bash it appears to be
>done after.  My question is: which behaviour is standard?

No, the substitution is done in the subshell, but parameter expansion
on $HOME is being done before "environment augmentation" is done.

I prefer the 'sh' behavour, because it is _the_ standard, upon
which other standards (posix) must be built.

No doubt the bash people will now tell me I'm wrong.  (I'm a zsh-user!)

With a semi-colon, the HOME=foo becomes a seperate command, and so
the shell variable is modified before it goes on to parse the echo command.

--


University of Glasgow               |..!mcsun!ukc!uk.ac.glasgow.dcs!sinclair
     No! Not the .sig virus again!  I thought I had removed it.

I hate following up my own articles...

Here's a puzzle that I don't understand, to do with what I've called
here "environment augmentation" and built-ins in both sh, and zsh...

$ xxx=ug echo $xxx .
.
$ echo $xxx .
ug .

This struck me as wrong, so I tried this...

$ yyy=ug /bin/echo $yyy .
.
$ echo $yyy .
.

The "."s are there just to fill what would otherwise be blank lines.

So, why does the variable get set for a built-in command, but not otherwise?
Or to put the question another way, why does it get set for
built-in commands, when experience tells me it shouldn't?

It makes some sense that it is because the shell doesn't need to
fork to do built-ins that the variable is getting set/updated when
it shouldn't.

Perhaps this should go into a new "sh programming considered harmful".

What does bash do for this?  Is there an analogous feature in rc?

--


University of Glasgow               |..!mcsun!ukc!uk.ac.glasgow.dcs!sinclair
           ---  Rave Culture: Don't techno for an answer.  ---

Quote:>Here's a puzzle that I don't understand, to do with what I've called
>here "environment augmentation" and built-ins in both sh, and zsh...
>$ xxx=ug echo $xxx .
>.
>$ echo $xxx .
>ug .
>So, why does the variable get set for a built-in command, but not otherwise?
>Or to put the question another way, why does it get set for
>built-in commands, when experience tells me it shouldn't?

I would call it a bug.

Quote:>What does bash do for this?  Is there an analogous feature in rc?

rc has local assignments that go away at the end of ANY kind of command.

Byron.

The (draft) standard requires /blah/blah/user.  The order things
happen in is as follows:

    1.  Words containing variable assignments and redirections are
        saved for processing in steps 3 & 4.

    2.  The remaining words are expanded.

    3.  Redirections are performed.

    4.  Variable assignments are expanded prior to assigning the
        value.

Steps 3 & 4 may be reversed for commands specified as being built-ins,
but not for any other commands (such as echo) that the shell chooses to
implement as built-ins.

BTW, the value of HOME after this command has completed must be
/blah/blah/user.  For specified built-ins it must be foo, but since
echo is not specified as a built-in it must behave as a normal command
regardless of whether it is implemented as a built-in.

[The above information is taken from an XPG4 draft, but since XPG4 has
adopted POSIX.2 it should be the same.]
--

UniSoft Limited, London, England.   Tel: +44 71 729 3773   Fax: +44 71 729 3273