Re: bash - safely pass untrusted strings?

["Bart Schaefer" <barton.schaefer@xxxxxxxxx>]

On Wed, Feb 27, 2008 at 11:13 AM, Garrick Staples <garrick@xxxxxxx> wrote:
>
>  'name=val >$name' is a weird case that I can't explain.  It is not related to
>  'name=val command' because there is no command.  It acts like two statements
>  when syntacticaly it is one.  It think it is a bug.  Avoid it.

The tidbit that no one has pointed out yet is that redirections are
not actually part of the command in the sense that you might think
they are.

These are all the same:

$ >foo echo bar
$ echo >foo bar
$ echo bar >foo

The command is "echo bar" no matter where you put the redirection.  Hence this:

$ foo=bar

and this:

$ foo=bar >$foo

are exactly the same in so far as the execution of "foo=bar" is
concerned; and "foo=bar" all by itself is the special construct that
means "assign foo in the current shell", so that's what happens.  On
the other hand

$ foo=bar echo

is syntax that means (as has previously been explained) "assign foo in
the process environment of echo" so nothing happens in the current
shell.

The other tidbit (see the book link Les posted) is that assignments
happen very early and redirections happen very late, in the order of
evaluation.

If you really want to warp your brain, try this one (not in your only
login shell, though):

$ 2>$foo foo=yourOutputIsHere exec

And stop thinking from left to right.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos