Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Don Beusee" <Don.Beusee@oracle.com>
To: muller@cerbere.u-strasbg.fr
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: small enhancements to gdb here..
Date: Thu, 30 Nov 2000 15:04:00 -0000	[thread overview]
Message-ID: <200011302304.eAUN44e28315@dbeusee.us.oracle.com> (raw)

>>- additional arg syntax in user-defined commands:
>>     $#        number of args
>>     $*        all args
>>     $N        specific arg (where N is a number from 1 to 9).  $1 is the 
>> first
>>               arg (same as $arg0).
>>     ${NN}     NN can be any number between 1 and MAXUSERARGS (10 currently).
>>     ${ENV}    environment variable
>>- a user command referencing an argument not provided on the command returns
>>   an empty string, not an error.
>
>   But this conflict with the history $n expansion !

Not really.  History expansion doesn't occur in user-defined functions.

>Why not only keep $*, $# ${NN}

Compatability requires $argN.  It is deprecated though.

>About ${ENV}
>why shouldn't we also support things like
>   ${$i}}
>   if $i is a convinience variable then we would be able to write
>
>    for ($i=0,i<$#,i++) do
>       print arg $i is ${$i}}

This could be useful. but not easy to implement.  I will let a gdb developer do that if they want.

>Otherwise I don't think it is really useful to restrict to environment 
>variables,
>we could also search for ENV in the program being debugged.
>  So ${I}
>would give arg number 5 is I is convertable into a int a has the value 5.

I don't consider that useful, but someone else can make that enhancement if they wish. The purpose of ${ENV} is to simply expand to the value of the environment variable.  It isn't to get the ENVth argument value. i.e ${USER} would expand to the value of the $USER environment variable.

>Anyhow any way to get the Nnth arg where N is a variable would be most welcome.

If someone finds a need, they can do it.  I didn't have such a need, so I didn't do it.  This suggestion would collide with the one above regarding $i use in a for loop.

>One more question, are there no languages that accept
>variables beginning with digits ?
>
>I hope not, but maybe it is worth to ask ourselves this question !

How is that relevant to the enhancements I made?

-Don

---- Forwarded Message ----

From muller@cerbere.u-strasbg.fr Tue Nov 21 00:50:50 2000
X-Sender: muller@ics.u-strasbg.fr
Date: Tue, 21 Nov 2000 09:50:21 +0100
To: "Don Beusee" <Don.Beusee@oracle.com>
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
Subject: Re: small enhancements to gdb here..
Cc: gdb-patches@sourceware.cygnus.com
Mime-Version: 1.0


At 08:57 21/11/00 , vous avez icrit:
>Hi,
>
>I originally sent this email to gnu-gdb@gnu.org before I saw the 
>CONTRIBUTE file.  I reformatted the diff output to your 
>specifications.  The diff's are based on 5.0 distribution at GNU's ftp site.
>
>I have patches for 3 small enhancements to improve convenience:
>
>- allow O/S commands directly from gdb when no match for internal command.
>- additional arg syntax in user-defined commands:
>     $#        number of args
>     $*        all args
>     $N        specific arg (where N is a number from 1 to 9).  $1 is the 
> first
>               arg (same as $arg0).
>     ${NN}     NN can be any number between 1 and MAXUSERARGS (10 currently).
>     ${ENV}    environment variable
>- a user command referencing an argument not provided on the command returns
>   an empty string, not an error.

   But this conflict with the history $n expansion !

Why not only keep $*, $# ${NN}

About ${ENV}
why shouldn't we also support things like
   ${$i}}
   if $i is a convinience variable then we would be able to write

    for ($i=0,i<$#,i++) do
       print arg $i is ${$i}}

Otherwise I don't think it is really useful to restrict to environment 
variables,
we could also search for ENV in the program being debugged.
  So ${I}
would give arg number 5 is I is convertable into a int a has the value 5.

Anyhow any way to get the Nnth arg where N is a variable would be most welcome.


One more question, are there no languages that accept
variables beginning with digits ?

I hope not, but maybe it is worth to ask ourselves this question !




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




             reply	other threads:[~2000-11-30 15:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-30 15:04 Don Beusee [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-11-30 15:26 Don Beusee
2000-11-30 15:38 ` Michael Snyder
     [not found] <200011210757.eAL7vJx28709@dbeusee.us.oracle.com>
2000-11-21  0:50 ` Pierre Muller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200011302304.eAUN44e28315@dbeusee.us.oracle.com \
    --to=don.beusee@oracle.com \
    --cc=gdb-patches@sourceware.cygnus.com \
    --cc=muller@cerbere.u-strasbg.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox