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&...
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.