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

[Pedro Alves <palves@redhat.com>]

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