[CentOS] bash - safely pass untrusted strings?

[Les Mikesell]

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