Re: [PATCH] Make 'symbol-file' not care about the position of command line arguments

[Sergio Durigan Junior <sergiodj at redhat dot com>]

On Wednesday, November 29 2017, Pedro Alves wrote:

> On 11/29/2017 10:42 PM, Sergio Durigan Junior wrote:
>> On Wednesday, November 29 2017, Pedro Alves wrote:
>> 
>>> On 11/29/2017 09:44 PM, Sergio Durigan Junior wrote:
>>>> This is a bug that's been detected while doing the readnever work.
>>>> Currently if you use the 'symbol-file' command you have to be careful
>>>> about the position of each argument you pass on the command line.
>>>> This is because while parsing its arguments, if the command detects a
>>>> filename, it promptly calls 'symbol_file_add_main_1' without waiting
>>>> to see if there are other args on the line.  This only affects the
>>>> '-readnow' argument so far, but while implementing the '-readnever'
>>>> command it also affected it.
>>>>
>>>
>>> Testcase or it didn't happen?  :-)
>> 
>> Can we negotiate this?  :-)
>> 
>> I absolutely agree (and should have written about it in the commit log),
>> but it's easier to write a testcase for the -readnever.  Actually, I
>> have one already written.  So I'd like to "postpone" the testcase until
>> the readnever feature is in.  OK?
>
> Doesn't -readnow work for that just the same?

Well, yeah, I've just confirmed that it's possible to match
"...expanding to full symbols..." when -readnow is used, so it's
possible to provide a testcase even now, indeed.

I'll wait until we reach a conclusion on whether this patch is useful or
not, and then submit the testcase along with v2.

>>> I hadn't really understood what this was about in the other thread.
>>> (Now I do.)  I wonder whether it's really desirable to make this
>>> work.  It seems to me that it's much more usual in GDB for option
>>> processing to stop at the first argument that doesn't start
>>> with '-'?  I.e., like getopt on most platforms.  (The related
>>> add-symbol-file command stands out as quite odd to me for
>>> explicitly wanting '-'-options after non-'-' options...)
>> 
>> I didn't know getopt stopped processing after the first non-'-'
>> argument.
>
> Most implementations of getopt do.  GNU getopt is known for
> reordering non-'-' arguments.  You can override that by
> setting POSIXLY_CORRECT in the environment, for example.
>
>> I've always considered that passing '--' is the de facto way
>> of telling getopt (or argp) to stop processing.
>
> "--" is used to stop processing options when you want to pass
> a non-option argument that starts with "-", like imagine if you
> wanted to pass a filename that starts with "-" to symbol-file
> (the filename is not an option.)

Ah, true, that makes sense.

>> 
>> I find it very confusing to have positional arguments in a command line.
>> This is not intuitive, and there's usually no indication that the
>> command expects a fixed position for its arguments (as is the case with
>> 'symbol-file', for example).  I consider this to be a bug, if you ask
>> me.
>
> In this case it's right there in the online help (since Tom's patch):
>
>  (gdb) help symbol-file
>  Load symbol table from executable file FILE.
>  Usage: symbol-file [-readnow] FILE

Sorry, but to me this doesn't say much.  I read this help and think "Oh,
-readnow can be passed as an option, OK."  Maybe that's my fault, but if
I was writing a command like "symbol-file FILE" and just remembered that
I wanted -readnow, I would include it in the end of the line.  In fact,
that's exactly what happened when I was testing -readnever.  I saw that
the flag had no effect when the last parameter, which made me go after
the cause.

> Note that supporting non-option arguments before options
> is impossible for commands that need to handle raw arguments.
> I.e., commands that want to supporting passing arguments
> arguments with spaces, without forcing the user to wrap it
> all in quotes.  Like "break -q function (int)", or
> "print /x EXPRESSION_WITH_SPACES", etc.  (I have a WIP series
> that adds '-'-options to "print", btw.)
> It's good to keep the possibility of the command being extended
> in that direction in mind.  It doesn't seem to be the case
> here, but that's the angle I was coming from.

I agree, but that's not the case with 'symbol-file' or
'add-symbol-file', right?  I mean, their only non-option argument is the
FILE, which won't have spaces (or will, but they'll be quoted like they
should).

Sorry for being so persistent, but I was bit by this bug and it wasn't
nice.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/