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

Pedro Alves
2017-11-30T00:34:58Z

On 11/30/2017 12:08 AM, Sergio Durigan Junior wrote:
> On Wednesday, November 29 2017, Pedro Alves wrote:
>
> 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 don't mind this going in, provided it comes with a testcase.

>>> 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.
>

... which points out that we should really handle "--", for
the possibility of such filenames.

(At some point we should really come up with some getopt-like
API that can be used by all the commands that also use gdb_argv,
to help with normalizing the interface, and also to make it
easier to add new options to commands.)

>> 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?

Yes, that's what I said - "it doesn't seem to be the case here".

Are we still negotiating? Can I get you to make
"add-symbol-file" process options in any position too? :-)

> 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.

Thanks,
Pedro Alves