`gud-common-init'

`gud-common-init'

[Paul Pogonyshev]

As far as I can tell, `gud-common-init' does not try to handle
command lines like this:

	--option "enquoted argument with spaces"

If it does, there must be a bug that prevents the above command
line from being parsed into arguments correctly.

Is this behaviour not seemed desirable?  Maybe it should be
implemented?  (I'm willing to have a try.)

Paul

`gud-common-init'

[Nick Roberts]

 > As far as I can tell, `gud-common-init' does not try to handle
 > command lines like this:
 > 
 > 	--option "enquoted argument with spaces"
 > 
 > If it does, there must be a bug that prevents the above command
 > line from being parsed into arguments correctly.
 > 
 > Is this behaviour not seemed desirable?  Maybe it should be
 > implemented?  (I'm willing to have a try.)

Can you give real example of where this would be needed other than a file
which has spaces in its name. I think that we previously decided not to
encourage this practice.

Nick

Re: `gud-common-init'

[Paul Pogonyshev]

>  > As far as I can tell, `gud-common-init' does not try to handle
>  > command lines like this:
>  >
>  > 	--option "enquoted argument with spaces"
>  >
>  > If it does, there must be a bug that prevents the above command
>  > line from being parsed into arguments correctly.
>  >
>  > Is this behaviour not seemed desirable?  Maybe it should be
>  > implemented?  (I'm willing to have a try.)
>
> Can you give real example of where this would be needed other than a file
> which has spaces in its name. I think that we previously decided not to
> encourage this practice.

Actually I tried to debug `etags' with command line

	etags --language none --regex '/^Pattern[ \t]+[a-zA-Z0-9]+/' ...

I agree it's not something you need every day, but it came out as a big
surprise for me when I saw how this command line was passed to `etags'.

Paul

Re: `gud-common-init'

[Nick Roberts]

 > Actually I tried to debug `etags' with command line
 > 
 > 	etags --language none --regex '/^Pattern[ \t]+[a-zA-Z0-9]+/' ...
 > 
 > I agree it's not something you need every day, but it came out as a big
 > surprise for me when I saw how this command line was passed to `etags'.

M-x gdb

Run gdb (like this): gdb etags

(gdb) r --language none --regex '/^Pattern[ \t]+[a-zA-Z0-9]+/' ...

Does this work for you?


Nick

Re: `gud-common-init'

[Paul Pogonyshev]

Nick Roberts wrote:
>  > Actually I tried to debug `etags' with command line
>  >
>  > 	etags --language none --regex '/^Pattern[ \t]+[a-zA-Z0-9]+/' ...
>  >
>  > I agree it's not something you need every day, but it came out as a big
>  > surprise for me when I saw how this command line was passed to `etags'.
>
> M-x gdb
>
> Run gdb (like this): gdb etags
>
> (gdb) r --language none --regex '/^Pattern[ \t]+[a-zA-Z0-9]+/' ...
>
> Does this work for you?

Wow, I managed to use GDB for all this time without knowing this...
Thanks for the hint.

The only inconvenience is that it is more difficult to restart
debugging session with the very same arguments after you quit GDB,
but I agree it's way to minor a problem to bother.

Paul

Re: `gud-common-init'

[Nick Roberts]

 > The only inconvenience is that it is more difficult to restart
 > debugging session with the very same arguments after you quit GDB,
 > but I agree it's way to minor a problem to bother.

Don't quit GDB then. If you've edited and recompiled your program you might
have to reset your breakpoints but apart from that, if you then type "r" GDB
should run with the same arguments. That way you can also access the shell
history.


Nick

Re: `gud-common-init'

[Stefan Monnier]

>> --option "enquoted argument with spaces"
[...]
> Can you give real example of where this would be needed other than a file
> which has spaces in its name. I think that we previously decided not to
> encourage this practice.

While it´s generally not encouraged I think it´d be good not to mess up when
the needs comes up.  In PCL-CVS I wrote cvs-string->strings (and
a corresponding cvs-strings->string) to handle that.

It´s similar to split-string except that it understands the "..." notation
of Elisp (with escapes and all: it just uses `read´ to handle it).  I think
something like that should be added to subr.el since it comes in handy for
any application that needs to prompt for a command and then needs to
decompose it.


        Stefan

Re: `gud-common-init'

[Nick Roberts]

 > While it´s generally not encouraged I think it´d be good not to mess up when
 > the needs comes up...

Well the price paid is lisp code that is harder to understand.


 >                   ...  In PCL-CVS I wrote cvs-string->strings (and
 > a corresponding cvs-strings->string) to handle that.

Its funny you should say that since in the previous thread (gud.el changes) I
thought you were the one who wasn't keen on the change. AFAIK the last message
in that thread was mine (Sun, 6 Jul 2003 03:37:34 +0100):


RMS> But if shell quoting is the wrong format for this use,
RMS> then comint-arguments is not right for it.  In that case,
RMS> this statement is probably right:

You>     I think we need something similar to cvs-string->strings in subr.el
You>     (and a corresponding strings->string).

Me> As Richard is agreeable to this and since you wrote pcvs-util.el, can I
Me> suggest that you make this change.

Me> Please note, however that I had to change cvs-string->strings slightly
Me> because split-string has been re-defined and can now output null strings:

Me> --- pcvs-util.el.~1.19.~        2003-05-10 11:27:06.000000000 +0100
Me> +++ pcvs-util.el        2003-06-28 17:43:22.000000000 +0100
Me> @@ -223,8 +223,8 @@
Me>  The SEPARATOR regexp defaults to \"\\s-+\"."
Me>    (let ((sep (or separator "\\s-+"))
Me>         (i (string-match "[\"]" string)))
Me> -    (if (null i) (split-string string sep)     ; no quoting:  easy
Me> -      (append (unless (eq i 0) (split-string (substring string 0 i) sep))
Me> +    (if (null i) (split-string string sep t)   ; no quoting:  easy
Me> +      (append (unless (eq i 0) (split-string (substring string 0 i) sep t))
Me>               (let ((rfs (read-from-string string i)))
Me>                 (cons (car rfs)
Me>                       (cvs-string->strings (substring string (cdr rfs))

Me> Then only one line need be changed in gud.el:

Me> --- gud.el.~1.3.~       2003-06-19 01:54:57.000000000 +0100
Me> +++ gud.el      2003-06-28 17:17:02.000000000 +0100
Me> @@ -2297,7 +2297,7 @@
Me>  ;; for local variables in the debugger buffer.
Me>  (defun gud-common-init (command-line massage-args marker-filter
Me>                                      &optional find-file)
Me> -  (let* ((words (split-string command-line))
Me> +  (let* ((words (cvs-string->strings command-line))
Me>          (program (car words))
Me>          (dir default-directory)
Me>          ;; Extract the file name from WORDS

Me> though cvs-string->strings will no doubt have another name when it's moved to
Me> subr.el


Nick

Re: `gud-common-init'

[Stefan Monnier]

> Its funny you should say that since in the previous thread (gud.el
> changes) I thought you were the one who wasn't keen on the
> change. AFAIK the last message in that thread was mine (Sun, 6 Jul 2003
> 03:37:34 +0100):

There must have been a misunderstanding.  I do think that
cvs-string->strings should be moved to subr.el first, tho, because it is
wrong for gud.el to require something like pcvs-util.


        Stefan