Re: [RFA/RFC] Problem with '!' escaping with zsh/bash/ksh

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, May 03, 2003 at 11:36:01AM +0300, Eli Zaretskii wrote:
> > Date: Fri, 2 May 2003 16:34:58 -0700
> > From: Joel Brobecker <brobecker@gnat.com>
> > 
> > the following change introduced a problem when forking inferiors when
> > the path to the executable contains '!' characters. This only occurs
> > with sh-like shells, like zsh/bash/ksh. I have reproduced this on Linux
> > and HP/UX.
> > 
> >         * fork-inferior.c (fork_inferior): Add '!' to the list of
> >         characters that need to be quoted when building a string for the
> >         shell.  Quote '!' specifically with a backslash, since CSH chokes
> >         when trying to evaluate "str!str". 
> > 
> > Witness:
> > 
> >         (gdb) run
> >         Starting program: /home/brobecke/tmp/GEO_ENV!9.159/foo 
> >         zsh: no such file or directory: /home/brobecke/tmp/GEO_ENV\!9.159/foo
> >         
> >         Program exited with code 01.
> >         You can't do that without a process to debug.
> > 
> > As far as I can tell from the comments in fork_inferior and my own
> > experiments, the bang should be escaped only for C shells.
> 
> Are you saying that zsh doesn't support escaping of arbitrary
> characters with a backslash?  That is, under zsh, "\a" is not the same
> as "a"?  I'd be surprised.

No, I don't think that's what he's saying - and I'm not sure the
problem is understood correctly, but Joel, I don't have the original
message any more, so I might be mistaken...

By the time it gets to execve, we have:
execve("/home/drow/foo/foo\\!bar/ls", ["/home/drow/foo/foo\\!bar/ls"],

i.e. the backslash has been escaped too!



By the way... what would the general reaction be to supporting exec'ing
the program directly instead of through the shell?  At least as an
option, since it would be a bit of an interface/quoting change?

I've had several opportunities over the past couple of weeks to try to
debug ld.so in trace mode, and doing this from either gdb or gdbserver
is essentially impossible; because gdbserver can't yet set env
variables, and gdb runs a shell, so there's no way to set an env
variable to affect the program being debugged and not also gdbserver or
sh.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer