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

[Sergio Durigan Junior <sergiodj@redhat.com>]

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?

> 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.  I've always considered that passing '--' is the de facto way
of telling getopt (or argp) to stop processing.

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.

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