Re: RFA: Support Windows extended error numbers in safe_strerror

[Daniel Jacobowitz <drow@false.org>]

On Mon, Feb 06, 2006 at 12:47:58AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 5 Feb 2006 16:56:59 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > > Isn't the shell used to allow redirection and shell-like quoting from
> > > the gdb command-line?  Lack of redirection, at least, is an occasional
> > > complaint about gdb-under-cygwin.
> > 
> > That's right; and we certainly can't ditch that support.  But what we
> > do today is pass the command line arguments directly to a shell, which
> > means all sorts of worrying about quoting, and also means that we get
> > Bourne shell behavior if the user has an appropriate $SHELL, or C shell
> > if they're using csh/tcsh, et cetera.  I don't know if anyone takes
> > advantage of that as a feature, but it's sure confusing!
> 
> I don't see why this is confusing at all.  The point is that the user
> should type the command arguments as if she were typing at the shell's
> prompt, and feel exactly the same.  So I don't see why we need to
> worry about quoting--just passing the args verbatim to the shell
> should do the trick.  Or am I missing something?

This way you can't write documentation for GDB that says how the
arguments to "run" behave - you have to reference another program,
and we're not even sure which program it is half the time.

I'd rather be able to have a chapter in the manual saying "this is how
you use globbing, if you want to", and "this is how you escape
arguments", and "this is how you redirect stderr to a file, if your
platform supports that".

Bonus: we could make that work with remote targets, too, by redirecting
the Remote File I/O stdout and stderr channels.  I will be doing some
work with both file I/O and remote argument passing over the next
month; I may revisit this and write a proposal...

-- 
Daniel Jacobowitz
CodeSourcery