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

Sergio Durigan Junior
2017-11-29T22:42:51Z

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