On Tue, Feb 26, 2008 at 11:16:27PM -0600, Les Mikesell wrote:
> Yes, but I'm looking for what happens before and after. Why does
> unset foo
> foo=bar >$foo
> do something you might expect, but
> unset foo
> foo=bar echo $foo >$foo
> doesn't?
What would you expect the last to do? "foo=bar echo $foo" only sets "foo"
inside the scope of the "echo" statement, so in the scope of ">$foo" the
variable is unset. In the first case there's no command so the shell is
evaluating left-to-right and it works. I actually wouldn't code written
that, myself! Too close to obfuscation; much easier written as two lines;
foo=bar
> $foo
for ease of understanding.
> Or why doesn't
> unset foo
> foo=bar echo $foo
> work like you'd expect while
It does work like I'd expect; $foo is evaulated by the current shell to be
null, and then it's set to bar for the execution of the "echo" statement.
But echo doesn't use the variable, it merely prints what was passed on
the command line (ie nothing)
> unset foo
> foo=bar some_other_command
> will put foo in the environment for the other command?
It worked the same in both cases. Note
foo=bar some_other_command $foo
will do the same as the echo case above. eg
bash-3.00$ ls
bash-3.00$ touch file1 file2 file3
bash-3.00$ foo=bar ls $foo
file1 file2 file3
Remember, "$foo" is evaluated by the calling shell and not by the "echo"
sub-process (or builtin, depending on sh variant) nor the "ls" process,
and in that context it's still unset.
> And how does this relate to ||, && and things on the right hand side of
> |'s in terms of evaluation order and side effects?
Mostly you can think of those things as causing subprocesses, so each part
can be wrapped in ( )
eg
foo=bar a_command | env | grep foo
is close enough to
( foo=bar a_command ) | ( env ) | ( grep foo )
for evaluation purposes.
The "foo" variable is only set in the scope of "a_command" and so env never
sees it.
> I'm sure I saw a simple list of the order of operations for the bourne
> shell years ago with about 6 steps and which are repeated if you add an
I've never seen one. I'm not even sure I could write one :-)
> must still do the steps in the same order to be compatible. You really
> need to know this to do anything even slightly complicated and I'm
Not really. Mostly if you find yourself hitting that sort of problem
then you're writing overly complicated code and are probably better off
refactoring it into something more readable.
I've been coding in ksh for 18 years now and haven't had to worry too
much about precedence that simple test cases can't answer for me. And
that included 1100 line scripts than run a messaging system :-)
--
rgds
Stephen
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
