Re: [Feature Request]export extglob from environment

[Jan Schampera]

Hello Chet,
hello Raph,

I was involved in the discussion on IRC (Freenode / #bash) yesterday,
maybe I can give one or the other comment.

It took a while for us to find out why it happens. When we knew it, and
after some discussion, we agreed that the easiest way would be to make
Bash able to initialize the shopts from the environment, similar to
SHELLOPTS.

We discussed other ways, also non-Bash solutions, but they're all more
workarounds than solutions.

 - the environment needs extglob
 
 Not really.  In this particular case, you could have used `xterm -e'
 to run bash with the -O extglob option.

This isn't always possible, easy or even wanted. One of those
workarounds from above, IMHO.

 None of these are compelling.  Maybe a BASHOPTS analog to SHELLOPTS
 for `shopt' options.  It might be useful to provide a configuration
 option that defaults extglob to on, also.

I'd prefer some own transport variable in environment, like you said.
It's not only extglob that isn't transported, though for the rest it
doesn't result in syntax errors. Transporting these options would make
the behaviour more consistent and less surprising.

If a configure option exists or not is more a matter of taste I'd say.
But this particular problem would have been solved, yes :)

Regards,
Jan TheBonsai Schampera

Is this exploitable?

[Jon Seymour]

I am trying to parse untrusted strings and represent in a form that
would be safe to execute.

So assuming as-echo.sh defined as below for example:

cmd=echo
for a in $@
do
cmd=$cmd '${a/\'/''}'
done
echo $cmd
eval $cmd

Then:

as-echo.sh 'a' '$(foobar)' 'c'

would produce:

   echo 'a' '$b' 'c'
   a $b c

Is my code safe, or can someone maliciously choose arguments to
as-echo.sh that could cause it (as-echo.sh) to do something other than
write to stdout?

Can anyone point me to best practice for this kind of protection in bash?

jon.