getopt: How does arraySep work?
jond at noreply.com
Thu Jul 16 05:03:36 UTC 2020
On Wednesday, 15 July 2020 at 07:12:35 UTC, Andre Pany wrote:
> On Tuesday, 14 July 2020 at 15:48:59 UTC, Andre Pany wrote:
>> On Tuesday, 14 July 2020 at 14:33:47 UTC, Steven Schveighoffer
>>> On 7/14/20 10:22 AM, Steven Schveighoffer wrote:
>>>> The documentation needs updating, it should say "parameters
>>>> are added sequentially" or something like that, instead of
>>>> "separation by whitespace".
>> Thanks for the answer and the pr. Unfortunately my goal here
>> is to simulate a partner tool written in C/C++ which supports
>> this behavior. I will also create an enhancement issue for
>> supporting this behavior.
>> Kind regards
> Enhancement issue:
> Kind regards
An enhancement is likely to hit some corner-cases involving list
termination requiring choices that are not fully generic. Any
time a legal list value looks like a legal option. Perhaps the
most important case is single digit numeric options like '-1',
'-2'. These are legal short form options, and there are programs
that use them. They are also somewhat common numeric values to
include in command lines inputs.
I ran into a couple cases like this with a getopt cover I wrote.
The cover supports runtime processing of command arguments in the
order entered on the command line rather than the compile-time
getopt() call order. Since it was only for my stuff, not Phobos,
it was an easy choice: Disallow single digit short options. But a
Phobos enhancement might make other choices.
IIRC, a characteristic of the current getopt implementation is
that it does not have run-time knowledge of all the valid
options, so the set of ambiguous entries is larger than just the
limited set of options specified in the program. Essentially,
anything that looks syntactically like an option.
Doesn't mean an enhancement can't be built, just that there might
some constraints to be aware of.
More information about the Digitalmars-d-learn