Re: [PATCH] specify arguments to debugee from commandline (second try)

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Deephanphongs, David]

Eli Zaretskii wrote:
> On Thu, 7 Jun 2001, David Deephanphongs wrote:
> > GDB will escape the following characters within an inferior argument:
> > ^|&#<>\"'`$*?[](); \{}
> >                   ^----space
> 
> The function which implements this should be OS-dependent.  What you 
> wrote might work for /bin/sh, but not for non-Posix systems such as 
> MS-Windows.

I've been trying to figure out how to do this..
My problem is that I haven't figured out where the target-specific 
initialization occurs in GDB.
Is it just dependent on which files get linked in?

Dave

Re: [PATCH] specify arguments to debugee from commandline (secondtry)

[Michael Snyder]

"Deephanphongs, David" wrote:
> 
> Eli Zaretskii wrote:
> > On Thu, 7 Jun 2001, David Deephanphongs wrote:
> > > GDB will escape the following characters within an inferior argument:
> > > ^|&#<>\"'`$*?[](); \{}
> > >                   ^----space
> >
> > The function which implements this should be OS-dependent.  What you
> > wrote might work for /bin/sh, but not for non-Posix systems such as
> > MS-Windows.
> 
> I've been trying to figure out how to do this..
> My problem is that I haven't figured out where the target-specific
> initialization occurs in GDB.
> Is it just dependent on which files get linked in?

All initialization in GDB occurs in functions whose names
begin with "_initialize".  Look in any *-tdep.c file.

Re: [PATCH] specify arguments to debugee from commandline (second try)

[David Deephanphongs]

This patch allows the user to pass the arguments to the program to be
debugged on the command line.

When the option -run is encountered, gdb stops processing options.  It
treats the first argument after -run as the program name, and
everything that follows is treated as the arguments to the debuggee.

This patch is sans a formal changelog and documentation fixes, I'll
add them if the patch is accepted.

Changes (from gdb+dejagnu-20010327):

inferior.h: change get/set_inferior_arg prototypes to 
get/set_inferior_args prototypes.  get/set_inferior_arg do
not appear anywhere in the code.

main.c: process the -run argument.  
I do this in two passes - the first pass calculates the length of the
argument string, the second pass strcpy and strcat's the arguments
into the buffer.
I do the actual assignment of the inferior_argument variable after the
command file is processed - this will allow the commandline to override
the command file.

	
===== PATCH =====
diff -c3p gdb-orig/inferior.h gdb/inferior.h
*** gdb-orig/inferior.h	Tue Mar 13 18:31:13 2001
--- gdb/inferior.h	Fri Mar 30 12:12:51 2001
*************** extern void tty_command (char *, int);
*** 267,275 ****
  
  extern void attach_command (char *, int);
  
! extern char *get_inferior_arg (void);
  
! extern char *set_inferior_arg (char *);
  
  /* Last signal that the inferior received (why it stopped).  */
  
--- 267,275 ----
  
  extern void attach_command (char *, int);
  
! extern char *get_inferior_args (void);
  
! extern char *set_inferior_args (char *);
  
  /* Last signal that the inferior received (why it stopped).  */
  
diff -c3p gdb-orig/main.c gdb/main.c
*** gdb-orig/main.c	Tue Mar  6 03:21:10 2001
--- gdb/main.c	Fri Mar 30 16:10:46 2001
*************** captured_main (void *data)
*** 168,173 ****
--- 168,177 ----
  
    long time_at_startup = get_run_time ();
  
+   /* Arguments for the inferior program from the commandline. */
+   char *cmdline_inf_args = 0;
+   int cmdline_inf_args_flag = 0;
+ 
    START_PROGRESS (argv[0], 0);
  
  #ifdef MPW
*************** captured_main (void *data)
*** 284,289 ****
--- 288,294 ----
        {"windows", no_argument, &use_windows, 1},
        {"statistics", no_argument, 0, 13},
        {"write", no_argument, &write_files, 1},
+       {"run", no_argument, 0, 14},
  /* Allow machine descriptions to add more options... */
  #ifdef ADDITIONAL_OPTIONS
        ADDITIONAL_OPTIONS
*************** captured_main (void *data)
*** 300,305 ****
--- 305,318 ----
  	if (c == EOF)
  	  break;
  
+ 	/* A -run argument stops the option processing
+ 	   immediately. */
+ 	if (c == 14)
+ 	  {
+ 	    cmdline_inf_args_flag = 1;
+ 	    break;
+ 	  }
+ 
  	/* Long option that takes an argument.  */
  	if (c == 0 && long_options[option_index].flag == 0)
  	  c = long_options[option_index].val;
*************** extern int gdbtk_test (char *);
*** 468,490 ****
  
      /* OK, that's all the options.  The other arguments are filenames.  */
      count = 0;
!     for (; optind < argc; optind++)
!       switch (++count)
! 	{
! 	case 1:
! 	  symarg = argv[optind];
! 	  execarg = argv[optind];
! 	  break;
! 	case 2:
! 	  /* FIXME: The documentation says this can be a "ProcID". as well. */
! 	  corearg = argv[optind];
! 	  break;
! 	case 3:
! 	  fprintf_unfiltered (gdb_stderr,
  			  "Excess command line arguments ignored. (%s%s)\n",
  			  argv[optind], (optind == argc - 1) ? "" : " ...");
! 	  break;
! 	}
      if (batch)
        quiet = 1;
    }
--- 481,538 ----
  
      /* OK, that's all the options.  The other arguments are filenames.  */
      count = 0;
!     if (cmdline_inf_args_flag)
!       {
! 	int arg_len = 1; /* \0 */
! 	int i;
! 	
! 	/* Run through all the arguments to find out how long of a buffer
! 	   we need. */
! 	for (i=optind+1; i<argc; i++)
! 	  {
! 	    arg_len += strlen (argv[i]);
! 	    arg_len += 1; /* for the space that comes after the argument */
! 	  }
! 	cmdline_inf_args = xmalloc( arg_len );
! 	for (; optind < argc; optind++)
! 	  {
! 	    switch (++count)
! 	      {
! 	      case 1:
! 		symarg = argv[optind];
! 		execarg = argv[optind];
! 		break;
! 	      case 2:
! 		strcpy( cmdline_inf_args, argv[optind] );
! 		break;
! 	      default:
! 		strcat (cmdline_inf_args, " ");
! 		strcat (cmdline_inf_args, argv[optind]);
! 		break;
! 	      }
! 	  }
!       }
!     else
!       {
! 	for (; optind < argc; optind++)
! 	  switch (++count)
! 	    {
! 	    case 1:
! 	      symarg = argv[optind];
! 	      execarg = argv[optind];
! 	      break;
! 	    case 2:
! 	      /* FIXME: The documentation says this can be a "ProcID". 
! 		 as well. */
! 	      corearg = argv[optind];
! 	      break;
! 	    case 3:
! 	      fprintf_unfiltered (gdb_stderr,
  			  "Excess command line arguments ignored. (%s%s)\n",
  			  argv[optind], (optind == argc - 1) ? "" : " ...");
! 	      break;
! 	    }
!       }
      if (batch)
        quiet = 1;
    }
*************** extern int gdbtk_test (char *);
*** 669,678 ****
        catch_command_errors (source_command, cmdarg[i], !batch, RETURN_MASK_ALL);
      }
    xfree (cmdarg);
! 
    /* Read in the old history after all the command files have been read. */
    init_history ();
  
    if (batch)
      {
        /* We have hit the end of the batch file.  */
--- 717,732 ----
        catch_command_errors (source_command, cmdarg[i], !batch, RETURN_MASK_ALL);
      }
    xfree (cmdarg);
!   
    /* Read in the old history after all the command files have been read. */
    init_history ();
  
+   if (cmdline_inf_args_flag)
+     {
+       /* Set the inferior arguments now, so we can override the command file. */
+       set_inferior_args (cmdline_inf_args);
+     }
+ 
    if (batch)
      {
        /* We have hit the end of the batch file.  */

Re: [PATCH] specify arguments to debugee from commandline (second try)

[David Deephanphongs]

Right..  No comments at all on this one.

So - there are three ways to pass arguments to the inferior process:

1) as an escaped string: My favorite, but no-one else seems to like it.
Pro: can be treated as just another option by the wrapper functions
(gdb, xxgdb, etc.)

Cons: can make arguments with quotes, etc., much more difficult to
write.
Could require parsing inside GDB to allow for escape sequences; e.g.,
if we are attempting to debug grep.

2) gdb [<various options>] -run <progname> <inf_arg1> .. <inf_argn>
Pro: Simple for the user to invoke GDB from the commandline - just
go back to the beginning of the line, and type "gdb -run" in front
of the command.

Cons: changes format of gdb.  Harder for wrapper programs to adapt
to it.

3) like X: when gdb encounters -- on the command line, all the
following arguments are treated as arguments to the inferior process.

Pro: simple to use.  Doesn't change syntax as much as 2.  Precedent
for it already exists.  

Con: breaks anything that uses core files that are named "--",
although that's probably not too likely.

4) like 3), but with a --args-enable option that turns it on -
this preserves perfect compatability with all the existing
scripts.

At this point, 99.5% of the work is done towards any of these options.
My personal preference is towards 1) or 4).

Which way do I need to go to get a patch in?

Dave

-- 
The thing between Death's triumphant digits was a fly from the dawn of
time. It was the fly in the primordial soup. It had bred on mammoth
turds.  It wasn't a fly that bangs on window panes, it was a fly that
drills through walls.
        -- Death goes fishing
           (Terry Pratchett, Mort)

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Alexandre Oliva]

On Apr  3, 2001, David Deephanphongs <deephan@erols.com> wrote:

> At this point, 99.5% of the work is done towards any of these options.
> My personal preference is towards 1) or 4).

Speaking as someone who isn't officially involved in the
decision-making of GDB, I'm leaning towards 3.  --run (that I had
suggested originally) may imply gdb will actually start the program,
instead of just setting up the argument list.  `--' is better in this
sense.  I don't see much need of --args-enable; one can always use
./-- instead of -- if their core file is named --.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Tom Tromey]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

Alexandre> Speaking as someone who isn't officially involved in the
Alexandre> decision-making of GDB, I'm leaning towards 3.  --run (that
Alexandre> I had suggested originally) may imply gdb will actually
Alexandre> start the program, instead of just setting up the argument
Alexandre> list.  `--' is better in this sense.  I don't see much need
Alexandre> of --args-enable; one can always use /-- instead of -- if
Alexandre> their core file is named --.

I agree `--run' isn't best name.

However the problem with `gdb foo -- arg1 arg2 arg3' is that it
inserts the `--' between the command and the arguments.

This complicates inserting the `gdb' invocation into shell scripts.
Code like this (which does occur from time to time):

    "$@"

becomes:

    foo="$1"
    shift
    gdb "$foo" -- ${1+"$@"}

(which also introduces script-visible side effects...)
rather than simply:

    gdb --run "$@"

Maybe I'm missing an easier way to do it.

My desire for this feature is that it be trivial to drop in place.
That will maximize its usefulness.

One option would be:

    gdb -- prog arg1 arg2 arg3

That is a change from existing gdb use though.  Plus then you have to
decide what to do when somebody inevitably tries:

    gdb prog -- somethingelse arg1 arg2 arg3

(An error wouldn't be unreasonable though.)

Tom

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Alexandre Oliva]

On Apr  6, 2001, Tom Tromey <tromey@redhat.com> wrote:

> However the problem with `gdb foo -- arg1 arg2 arg3' is that it
> inserts the `--' between the command and the arguments.

In the case of a wrapper script, which would probably be the most
common use of this feature, the command will be in $0, and the
argument list in $@.  So, to debug cc1, you'd probably do:

mv cc1 cc1.bin
echo 'exec ${DEBUGGER-gdb} "$0".bin -- ${1+"$@"}' > cc1
chmod +x cc1

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Tom Tromey]

>>>>> "David" == David Deephanphongs <deephan@erols.com> writes:

David> 1) as an escaped string: My favorite, but no-one else seems to
David> like it.

I can explain why I don't like it.  Sometimes I debug gcc.  gcc runs
other programs, which are usually the ones I really want to debug.
Doing this is currently a pain -- I have to run `gcc -v' and then cut
and paste the resulting command line into gdb.  Sometimes I find it
hard to find the command line I want, and I always find this process
annoying.

I'd like to modify gcc so I can invoke: `gcj --debug jc1 ...' and have
gcc automatically insert `gdb --run' before the jc1 invocation.  Then
gdb will come up with the arguments magically set.

Likewise I'd like to be able to simply insert `gdb --run' into shell
scripts or any other program-launching code to get the debugger to do
the tedious work for me.

If we make the argument to `--run' a single string, then every place I
want to do this will have to deal with quoting issues and the like.
In places like gcc, where the arguments are already broken out into a
vector, I'd have to add special code to reassemble the vector into a
string.  In shell scripts this is very hard to do.

If `--run' accepts multiple arguments, then `gdb --run' can be dropped
in to most places with ease.  For instance in shell scripts it is just
trivial.  For something that is manipulating an argument vector, it
just means growing the vector by 2 slots.

David> 3) like X: when gdb encounters -- on the command line, all the
David> following arguments are treated as arguments to the inferior
David> process.

David> Pro: simple to use.  Doesn't change syntax as much as 2.
David> Precedent for it already exists.

The precedent here is not only in X but also in GNU.  GNU getopt
already has special handling for `--' arguments.  Search for `--' in
src/libiberty/getopt.c.

David> Con: breaks anything that uses core files that are named "--",
David> although that's probably not too likely.

It is entirely possible that this case already doesn't work, due to
the special handling of `--' in GNU getopt.  Has anybody tried it?

David> 4) like 3), but with a --args-enable option that turns it on -
David> this preserves perfect compatability with all the existing
David> scripts.

My personal opinion is that this isn't necessary.

David> Which way do I need to go to get a patch in?

I don't know.  You don't have to please me, that's for sure.  I offer
the above to explain my thinking on the subject.  This is a feature
I've wanted literally for years.

Tom

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Date: 05 Apr 2001 22:29:35 -0600
> 
> I'd like to modify gcc so I can invoke: `gcj --debug jc1 ...' and have
> gcc automatically insert `gdb --run' before the jc1 invocation.  Then
> gdb will come up with the arguments magically set.
> 
> Likewise I'd like to be able to simply insert `gdb --run' into shell
> scripts or any other program-launching code to get the debugger to do
> the tedious work for me.

Wouldn't such use get you in trouble in some cases anyway?  The
arguments you put after "gdb --run" are evaluated by the shell, so
what GDB sees is not exactly what you typed.  I'd imagine that in some
cases this would produce subtle differences between "gdb --run" and
issuing the `run' command inside GDB.

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Date: 06 Apr 2001 09:52:16 -0600
> 
> Maybe you mean that redirections won't work as expected.

Redirection is one thing I thought about.  But anything else that has
side effects, such as setting variables or computing expressions,
could potentially work differently as well.

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Pierre Muller]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

At 18:26 06/04/01 , vous avez écrit:
> > From: Tom Tromey <tromey@redhat.com>
> > Date: 06 Apr 2001 09:52:16 -0600
> >
> > Maybe you mean that redirections won't work as expected.
>
>Redirection is one thing I thought about.  But anything else that has
>side effects, such as setting variables or computing expressions,
>could potentially work differently as well.

   File expansion would also occur, no ?

   By the way, does this occur to args given by set args ?
   Probably not, but I am not sure here.

   Sometimes it would be helpful to get the shell to expand the
args before passing them to the program, but
in other case you explicitly don't want this.

   If we add "--" option support
it would give a simple way of getting this shell expansion
as opposed to using 'set args' later.

   But this again prooves that there are really subtle issues here!



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Tom Tromey]

>>>>> "Pierre" == Pierre Muller <muller@cerbere.u-strasbg.fr> writes:

>> > Maybe you mean that redirections won't work as expected.

>> Redirection is one thing I thought about.  But anything else that has
>> side effects, such as setting variables or computing expressions,
>> could potentially work differently as well.

Pierre>    File expansion would also occur, no ?

Pierre>    By the way, does this occur to args given by set args ?
Pierre>    Probably not, but I am not sure here.

Yes, file expansion happens when you use `run' in gdb as well.
That's because gdb uses the shell to launch the inferior.

At least, with native Unix debugging.  I don't know how arguments are
handled by embedded targets.

I personally want --run for my native debugging.  So I'm not too
concerned about how embedded targets handle strange cases here.


One idea would be for gdb to have a way to set a vector of arguments
in addition to a string of arguments.  Then the target could decide
what to do with the vector: quote it for the shell in Unix, do
whatever is right for DOS (I don't know), or just pass them to the
remote (?) for embedded targets.  That would push quoting decisions to
the target, where they presumably belong.

Tom

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Andrew Cagney]

Tom Tromey wrote:
> 
> >>>>> "Pierre" == Pierre Muller <muller@cerbere.u-strasbg.fr> writes:
> 
> >> > Maybe you mean that redirections won't work as expected.
> 
> >> Redirection is one thing I thought about.  But anything else that has
> >> side effects, such as setting variables or computing expressions,
> >> could potentially work differently as well.
> 
> Pierre>    File expansion would also occur, no ?
> 
> Pierre>    By the way, does this occur to args given by set args ?
> Pierre>    Probably not, but I am not sure here.
> 
> Yes, file expansion happens when you use `run' in gdb as well.
> That's because gdb uses the shell to launch the inferior.
> 
> At least, with native Unix debugging.  I don't know how arguments are
> handled by embedded targets.
> 
> I personally want --run for my native debugging.  So I'm not too
> concerned about how embedded targets handle strange cases here.

I'd suggest ignoring embedded targets for the moment.  Most of them
don't even allow command line arguments.  If:

	gdb --XXX ...

is made to work for the native case then someone else can fix the
embedded case.

Anyway, I think people have generally agreed that being to type:

	$ foo bar boof woftam
	$ gdb --??? !$

is preferable to:

	$ gdb --args=`something goes here`

It is a case of user convenience winning over correctness.

The next question is to do with the exact arg name.  I've several
comments:

	o	xterm uses -e program arguments

	o	I think of --run ... as more for
		the complete load'n'go case.
		GDB sets the arguments and fires
		up the program.  Only when the
		program crashes does GDB start.

Any way, if the --??? option is added then, we're one step short of the
--run that everyone really wants.	

	Andrew

Re: [PATCH] specify arguments to debugee from commandline (second try)

[David Deephanphongs]

Thus spake Andrew Cagney (ac131313@cygnus.com):

> Anyway, I think people have generally agreed that being to type:
> 	$ foo bar boof woftam
> 	$ gdb --??? !$
> 
> is preferable to:
> 
> 	$ gdb --args=`something goes here`
> 
> It is a case of user convenience winning over correctness.
> 
> The next question is to do with the exact arg name.  I've several
> comments:
> 
> 	o	xterm uses -e program arguments
> 

I've actually discovered a compatability problem with the way I was
planning on (re)implementing this (using '--' as the "all following
arguments go to inferior"   switch).  Someone could use '--' to
escape a wierd core file:
gdb progname -- -e
(where -e is the core file.)

I'm going to (re)implement the arg. patch with a -e like interface..
Mind you, -e is taken already (it's equivalent to --exec).
I tend to favor --args, myself, so unless there are any objections...
	gdb <opts...> progname --args <inf_args...>


Dave

-- 
"*Veni, vici*...Vetinari."
        -- (Terry Pratchett, Jingo)

Re: [PATCH] specify arguments to debugee from commandline (second try)

[David Deephanphongs]

Ok, here's the latest revision of the command-line args patch.

Syntax:
gdb [various options] --args <progname> <inferior arguments>

GDB will escape the following characters within an inferior argument:
^|&#<>\"'`$*?[](); \{}
                  ^----space

One thing I'm a little confused about - I thought that GNU getopt
(and getopt_long_only) moved arguments to the beginning of argv,
but that doesn't seem to be the case.
with an  argv that looks like this: {"gdb", "ls", "--args", "-l"}
I expect it to look like this (after getopt is called):
{"gdb", "--args", "ls", "-l"}
That doesn't happen, though.  Is it being forced into compatability
mode somehow?

Anyway, that's why it's 'gdb <opts> --args <progname> ...' instead
of 'gdb <opts> <progname> --args ...'

This isn't a proper patch - there's indentation issues with some of
the old argument parsing code.  I'm leaving the indentation alone
right now so I don't obscure the actual changed code (I had to put an
'if' around all the old program-name/corearg code).

---- Begin patch ----

*** gdb/main.c	Thu Jun  7 00:56:39 2001
--- cmdline_arg_gdb/main.c	Thu Jun  7 00:58:56 2001
*************** captured_main (void *data)
*** 168,173 ****
--- 168,177 ----
  
    long time_at_startup = get_run_time ();
  
+   /* Arguments for the inferior program from the commandline. */
+   char *cmdline_inf_args = 0;
+   int cmdline_inf_args_flag = 0;
+ 
    START_PROGRESS (argv[0], 0);
  
  #ifdef MPW
*************** captured_main (void *data)
*** 281,286 ****
--- 285,291 ----
        {"windows", no_argument, &use_windows, 1},
        {"statistics", no_argument, 0, 13},
        {"write", no_argument, &write_files, 1},
+       {"args", no_argument, 0, 14},
  /* Allow machine descriptions to add more options... */
  #ifdef ADDITIONAL_OPTIONS
        ADDITIONAL_OPTIONS
*************** captured_main (void *data)
*** 297,302 ****
--- 302,314 ----
  	if (c == EOF)
  	  break;
  
+ 	/* We stop argument processing instantly if we get a -args option. */
+ 	if (c == 14)
+ 	{
+ 	  cmdline_inf_args_flag = 1;
+ 	  break;
+ 	}
+ 
  	/* Long option that takes an argument.  */
  	if (c == 0 && long_options[option_index].flag == 0)
  	  c = long_options[option_index].val;
*************** extern int gdbtk_test (char *);
*** 463,470 ****
        use_windows = 0;
  #endif
  
-     /* OK, that's all the options.  The other arguments are filenames.  */
      count = 0;
      for (; optind < argc; optind++)
        switch (++count)
  	{
--- 475,522 ----
        use_windows = 0;
  #endif
  
      count = 0;
+     /* If we have commandline arguments, then we expect the next argument
+        to be the program name, and the following arguments to be arguments
+        to the inferior process. */
+     if (cmdline_inf_args_flag)
+       {
+ 	int arg_len = 1; /* EOS */
+ 	int i;
+ 	char *cmdline_end; /* points to end of cmdline_inf_args. */
+ 
+ 	/* Run through all the arguments to determine what size buffer
+ 	   we need. */
+ 	for (i=optind+1; i<argc; i++)
+ 	  {
+ 	    arg_len += shell_escape_strlen (argv[i]);
+ 	    arg_len += 1; /* We'll put a space after the argument. */
+ 	  }
+ 	cmdline_inf_args = xmalloc (arg_len);
+ 	cmdline_inf_args[0] = 0; /* Starts out null. */
+ 	for (; optind<argc; optind++)
+ 	  {
+ 	    switch (++count)
+ 	      {
+ 	      case 1:
+ 		symarg = argv[optind];
+ 		execarg = argv[optind];
+ 		break;
+ 	      case 2:
+ 		/* Escape first string into cmdline_inf_args */
+ 		shell_escape_string (cmdline_inf_args, argv[optind]);
+ 		break;
+ 	      default:
+ 		strcat (cmdline_inf_args, " ");
+ 		cmdline_end = cmdline_inf_args + strlen (cmdline_inf_args);
+ 		shell_escape_string (cmdline_end, argv[optind]);
+ 		break;
+ 	      }
+ 	  }
+       }
+     else
+       {
+     /* OK, that's all the options.  The other arguments are filenames.  */
      for (; optind < argc; optind++)
        switch (++count)
  	{
*************** extern int gdbtk_test (char *);
*** 485,490 ****
--- 537,543 ----
      if (batch)
        quiet = 1;
    }
+   }
  
  #if defined(TUI)
    /* Should this be moved to tui-top.c:_initialize_tui()? */
*************** extern int gdbtk_test (char *);
*** 669,674 ****
--- 722,733 ----
  
    /* Read in the old history after all the command files have been read. */
    init_history ();
+ 
+   if (cmdline_inf_args_flag)
+     {
+       /* Set the inferior arguments now, so we can override the command file. */
+       set_inferior_args (cmdline_inf_args);
+     }
  
    if (batch)
      {
*** gdb/utils.c	Thu Jun  7 00:56:40 2001
--- cmdline_arg_gdb/utils.c	Thu Jun  7 00:01:05 2001
*************** address_to_host_pointer (CORE_ADDR addr)
*** 3045,3047 ****
--- 3045,3080 ----
    ADDRESS_TO_POINTER (builtin_type_ptr, &ptr, addr);
    return ptr;
  }
+ 
+ static char *shell_escape_chars = "^|&#<>\"'`$*?[](); \\{}";
+ int shell_escape_strlen (char *string)
+ {
+   int len;
+   
+   len = 0;
+   while( *string )
+     {
+       len++; /* Count each non-zero character once. */
+       if (strchr (shell_escape_chars, *string))
+ 	len++; /* If it needs to be escaped, count the '\' as well. */
+ 	  string++;
+     }
+ 
+   return len;
+ }
+ 
+ void shell_escape_string (char *dest, char *source)
+ {
+   while( *source )
+     {
+       /* If the next char. needs to be escaped... */
+       if( strchr (shell_escape_chars, *source) )
+ 	{
+ 	  *dest = '\\';  /* ...escape the next char. */
+ 	  dest++;
+ 	}
+       *dest = *source;
+       dest++;
+       source++;
+     }
+ }
*** gdb/defs.h	Thu Jun  7 00:52:40 2001
--- cmdline_arg_gdb/defs.h	Thu Jun  7 01:01:35 2001
*************** extern void init_page_info (void);
*** 519,524 ****
--- 519,526 ----
  extern CORE_ADDR host_pointer_to_address (void *ptr);
  extern void *address_to_host_pointer (CORE_ADDR addr);
  
+ extern int shell_escape_strlen (char *string);
+ extern void shell_escape_string (char *dest, char *source);
  /* From demangle.c */
  
  extern void set_demangling_style (char *);

------ End patch -------

-- 
By and large, the only skill the alchemists of Ankh-Morpork had discovered
so far was the ability to turn gold into less gold.
        -- (Terry Pratchett, Moving Pictures)

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Eli Zaretskii]

On Thu, 7 Jun 2001, David Deephanphongs wrote:

> GDB will escape the following characters within an inferior argument:
> ^|&#<>\"'`$*?[](); \{}
>                   ^----space

The function which implements this should be OS-dependent.  What you 
wrote might work for /bin/sh, but not for non-Posix systems such as 
MS-Windows.

To avoid ugly OS-specific #ifdef's, perhaps we should add a hook function 
pointer whcih a port could set to point to its private function.  Then 
the code you wrote could be the default.

> One thing I'm a little confused about - I thought that GNU getopt
> (and getopt_long_only) moved arguments to the beginning of argv,
> but that doesn't seem to be the case.

This is controlled by the first character of the third argument to 
`getopt' and `getopt_long_only': if that first character is `-' or `+', 
`getopt' behaves differently as to the ordering of the options.  See the 
comments in getopt.c about the "enum ordering" type.

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:

>> Maybe you mean that redirections won't work as expected.

Eli> Redirection is one thing I thought about.  But anything else that
Eli> has side effects, such as setting variables or computing
Eli> expressions, could potentially work differently as well.

I doubt there is any way to get perfect behavior in every conceivable
situation.

I'm not sure I follow you though.  Are you saying that some other
approach should be taken?  If so, what?

Tom

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Date: 06 Apr 2001 12:12:22 -0600
> 
> I'm not sure I follow you though.  Are you saying that some other
> approach should be taken?  If so, what?

No, I'm saying that I don't think this problem has a general
solution.  So we should decide up front what cases we want to support
and which ones not.

Re: [PATCH] specify arguments to debugee from commandline (second try)

[David Deephanphongs]

Thus spake Eli Zaretskii (eliz@delorie.com):

> > From: Tom Tromey <tromey@redhat.com>
> > Date: 06 Apr 2001 12:12:22 -0600
> > 
> > I'm not sure I follow you though.  Are you saying that some other
> > approach should be taken?  If so, what?
> 
> No, I'm saying that I don't think this problem has a general
> solution.  So we should decide up front what cases we want to support
> and which ones not.

I'm not convinced that we want to support any special handling...
We could force the user to just escape everything appropriately:

If they want equivalent to:
set args "this is a" test
force them to do:
gdb echo -- \"this is a\" test

This is just like sed, grep, et al. do it.

Dave
-- 
Gravity is a habit that is hard to shake off.
        -- (Terry Pratchett, Small Gods)

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Eli Zaretskii]

> Date: Wed, 11 Apr 2001 01:35:53 -0400
> From: David Deephanphongs <deephan@telocity.com>
> 
> Thus spake Eli Zaretskii (eliz@delorie.com):
> 
> > > From: Tom Tromey <tromey@redhat.com>
> > > Date: 06 Apr 2001 12:12:22 -0600
> > > 
> > > I'm not sure I follow you though.  Are you saying that some other
> > > approach should be taken?  If so, what?
> > 
> > No, I'm saying that I don't think this problem has a general
> > solution.  So we should decide up front what cases we want to support
> > and which ones not.
> 
> I'm not convinced that we want to support any special handling...
> We could force the user to just escape everything appropriately:
> 
> If they want equivalent to:
> set args "this is a" test
> force them to do:
> gdb echo -- \"this is a\" test

But that's exactly what Tom was trying to avoid!  His intent was to
allow substitution of "gdb COMMAND --run ARGS" for each case of
"COMMAND ARGS" in a mechanical way, which means ARGS should not be
modified in any way.

In other words, Tom was not talking about a user who types a command
at the shell prompt, but about a script that should behave the same in
both of these situations.  A human can easily be asked to escape
special characters in a command, but a shell script cannot do that
without lots of tricky and shell-dependent code.

Re: [PATCH] specify arguments to debugee from commandline (second try)

[David Deephanphongs]

Thus spake Eli Zaretskii (eliz@delorie.com):

> > From: David Deephanphongs <deephan@telocity.com>
> > 
<snip>
> > 
> > I'm not convinced that we want to support any special handling...
> > We could force the user to just escape everything appropriately:
> > 
> > If they want equivalent to:
> > set args "this is a" test
> > force them to do:
> > gdb echo -- \"this is a\" test
> 
> But that's exactly what Tom was trying to avoid!  His intent was to
> allow substitution of "gdb COMMAND --run ARGS" for each case of
> "COMMAND ARGS" in a mechanical way, which means ARGS should not be
> modified in any way.

I'm still not convinced that it's appropriate for /gdb/ to do the
escaping - if it's being put into a script, it's much easier to do
it in perl than C..

What characters need to be escaped, anyway?  It seems like it much
differ from shell to shell.

Dave
-- 
- "You pay for it before you eat it? What happens if it's dreadful?"
- "That's why."
        -- (Terry Pratchett, Moving Pictures)

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Tom Tromey]

>>>>> "David" == David Deephanphongs <deephan@telocity.com> writes:

David> I'm still not convinced that it's appropriate for /gdb/ to do
David> the escaping - if it's being put into a script, it's much
David> easier to do it in perl than C..

I won't claim that what I want is best.  I can only claim that my
suggestions support my goals.  I do think my goals are reasonable.

First, my primary use for a feature like this is in scripts and other
places where a program gets launched.  While it might be useful
interactively, I don't think that is the most important use.  This is
why I'm for putting the executable name after the `--': I think it is
more important to design for the script case than for the interactive
case.

Requiring the caller to do the quoting means that scripts will never
invoke gdb directly.  Instead I'll have to write another program to
wrap gdb and quote the command line for me.

That seems needless, especially given that requiring interactive users
to quote the command line will suck.

For instance, you can't type

    gdb foo -- ' a b c '

Instead you must type

    gdb foo -- '\ a\ b\ c\ '

I can't really call this intuitive or friendly.

Sure, you can use the wrapper program interactively too.  But that
seems weird: if you want to use this feature, you always have to use a
wrapper program.  Why not just build it the convenient way the first
time?

David> What characters need to be escaped, anyway?  It seems like it
David> much differ from shell to shell.

On Unix it doesn't really differ very much.  For most common shells
you can simply quote all the weird characters with `\'.

Tom

Re: [PATCH] specify arguments to debugee from commandline (second try)

[David Deephanphongs]

Thus spake Tom Tromey (tromey@redhat.com):

> David> I'm still not convinced that it's appropriate for /gdb/ to do
> David> the escaping - if it's being put into a script, it's much
> David> easier to do it in perl than C..
> 
<snip>

> 
> Requiring the caller to do the quoting means that scripts will never
> invoke gdb directly.  Instead I'll have to write another program to
> wrap gdb and quote the command line for me.
> 

I suppose that depends on what you are using to automate GDB...

Frankly, if you are going to automate it, you might as well use a command
file - it's just as easy.


> That seems needless, especially given that requiring interactive users
> to quote the command line will suck.
> 
> For instance, you can't type
> 
>     gdb foo -- ' a b c '
> 
> Instead you must type
> 
>     gdb foo -- '\ a\ b\ c\ '
> 
> I can't really call this intuitive or friendly.

I can understand that.. I generally don't like programs doing things
like that automatically for me, though... I always run into cases where
the program misinterprets what I want it to do.

Actually, though, unless you needed to preserve the correct # of spaces,
you could just escape the apostrophes.


<snip>
> 
> David> What characters need to be escaped, anyway?  It seems like it
> David> much differ from shell to shell.
> 
> On Unix it doesn't really differ very much.  For most common shells
> you can simply quote all the weird characters with `\'.
> 
> Tom

Wierd characters being what, precisely?  I'm tempted to just escape
everything that's not a letter or number..


Dave
-- 
"Why's it called Ming?" said the Archchancellor, on cue.
The Bursar tapped the pot. It went *ming*.
        -- Discworld archeology revealed
           (Terry Pratchett, Moving Pictures)

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Tom Tromey]

>>>>> "David" == David Deephanphongs <deephan@telocity.com> writes:

>> Instead you must type
>> gdb foo -- '\ a\ b\ c\ '

David> I can understand that.. I generally don't like programs doing
David> things like that automatically for me, though... I always run
David> into cases where the program misinterprets what I want it to
David> do.

David> Actually, though, unless you needed to preserve the correct #
David> of spaces, you could just escape the apostrophes.

The whole point is to preserve the arguments as-is.

I feel like we're not really communicating here.  Perhaps we have
different goals.  My goal is to see this feature implemented in a way
that works in a way I know would be useful for me.  Your goal seems to
be to make the implementation simple (which, btw, is not a criticism
on my part.  That's often an admirable goal; I just happen to disagree
in this instance).

Since we're also the only ones talking I'm inferring that nobody else
cares about drilling down on this subject any more.  My future
replies, if any, will be off-list unless somebody asks otherwise.

David> Wierd characters being what, precisely?  I'm tempted to just
David> escape everything that's not a letter or number..

From a program I wrote a long time ago:

  /* These are the characters that are special to the shell.  We
     include `^' because SunOS /bin/sh treats it as a synonym for
     `|'.  */
  return (actually_encode_string (t, "^|&#<>\"'`$*?[](); \\{}", 0));

I believe this includes sh variants and derivates plus csh.  Feel free
to use this.

I agree this isn't completely perfect.  Someone could use a shell
where `Z' is a special character.  However I disagree that "we can't
make it perfect" means "we shouldn't do anything at all".

Tom

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Todd Whitesel]

> The whole point is to preserve the arguments as-is.
...
> Since we're also the only ones talking I'm inferring that nobody else
> cares about drilling down on this subject any more.  My future
> replies, if any, will be off-list unless somebody asks otherwise.

Before you disappear, let me just chime in from the peanut gallery that I
find the whole "crunch inferior arguments through sh" to be uncomfortable.

Can't we just have two command line routes, one that uses sh, and one that
does not (it would just execvp the arguments for the most part) ?

That way people who want "it works like the run command" get their option
and people who want "debug whatever I was running durnit" get theirs.

Todd Whitesel
toddpw @ best.com

Re: [PATCH] specify arguments to debugee from commandline (second try)

[David Deephanphongs]

Thus spake Tom Tromey (tromey@redhat.com):

> >>>>> "David" == David Deephanphongs <deephan@erols.com> writes:
> 
> David> Con: breaks anything that uses core files that are named "--",
> David> although that's probably not too likely.
> 
> It is entirely possible that this case already doesn't work, due to
> the special handling of `--' in GNU getopt.  Has anybody tried it?

As it turns out, this /doesn't/ work.
Alright, the '--' way is an acceptable option.

Dave

-- 
"It's going to look pretty good, then, isn't it," said War testily, "the
One Horseman and Three Pedestrians of the Apocralypse."
        -- The Four Horsemen of the Apocralypse encounter
           unexpected difficulties
           (Terry Pratchett, Sourcery)

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Tom Tromey]

>>>>> "David" == David Deephanphongs <deephan@erols.com> writes:

David> This patch allows the user to pass the arguments to the program
David> to be debugged on the command line.

I'm very interested in this functionality, so I looked at this patch.

David> I do this in two passes - the first pass calculates the length
David> of the argument string, the second pass strcpy and strcat's the
David> arguments into the buffer.

Unfortunately your patch doesn't do this in a safe way.

Suppose I invoke: gdb --run foo "arg with space" bar

My reading of the code is that the inferior arguments will be set to
`arg with space bar' -- which will yield a different result than what
is desired.

I believe for this to work properly the code that calls
set_inferior_arg() must quote the strings for the shell.  This isn't
too hard to do -- simply put a `\' before each special character.  The
list of special characters is relatively shell-independent (weirdly
enough); using a superset won't hurt.

Tom

Re: [PATCH] specify arguments to debugee from commandline (second try)

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Date: 05 Apr 2001 22:20:56 -0600
> 
> I believe for this to work properly the code that calls
> set_inferior_arg() must quote the strings for the shell.  This isn't
> too hard to do -- simply put a `\' before each special character.

This quoting will only work on Unix and GNU/Linux platforms.