Stephen Harris 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.
How does the shell know that there's no command without evaluating, and
if it evaluates left to right, why isn't the result the same? Actually
I found the answer to that, which is that
name=val command
is processed like
(name=val; command)
which also explains why the value isn't left lingering for the next
operation.
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.
I find it much easier to understand code written to keep setting/using
values in the smallest scope possible.
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 ( )
Which would be more meaningful in a document that explains when and how
the () tokens are handled...
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 :-)
Section 7.8 of this might be close to what I remember seeing.
http://books.google.com/books?id=_mbgnxL-QvoC&pg=PA140&lpg=PA140&dq=shell+evaluation+order+of+operations&source=web&ots=SI7CFQOJ6b&sig=WRWpWZskGXOI8VJhIt1eHeeqfVs#PPA162,M1
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.
But I find compact code most 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.
I don't trust test cases on one implementation to be portable unless
they match the documented behavior.
And
that included 1100 line scripts than run a messaging system :-)
Maybe it would only have taken a couple hundred lines if you took
advantage of order of operations on each line... But my rule of thumb
is that if I expect something to fill more than a page, I'd start in
some other language.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
