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 at gmail.com