chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] stop run-time option processing after "--"


From: felix . winkelmann
Subject: Re: [PATCH] stop run-time option processing after "--"
Date: Mon, 13 Mar 2023 21:35:53 +0100

> On Mon, Mar 13, 2023 at 10:37:30AM +0100, felix.winkelmann@bevuta.com wrote:
> > Another problem with run-time option processing pointed out by
> > florz. This allows passing arguments that look like run-time
> > options, when preceded by "--".
>
> This needs more thought - simply adding "--" to stop it from processing
> options leaves us with ("--") as the first command-line argument.
> In other words, "./my-program -:a100 -- foo" is seen as '("--" "foo")
> when you ask for (command-line-arguments), while the intention probably
> was '("foo").

Actually not. Currently "--" is not specially handled, so it makes
no difference whether r/t options are passed or not ("command-line-arguments")
returns exactly the same. With or without this patch, "--" will be
seen by user code. If the program does not parse the command line, having
a "--" has no effect. If it does, it is probably a good idea (and
good style) to be aware of it and handle the case appropriately. For
"my-program" above, the "--" in the example invocation is immaterial.
But if "my-program" does process the command-line, it may be
appropriate to handle "--" anyway (mostly to distinguish its own options
from non-option arguments).


felix




reply via email to

[Prev in Thread] Current Thread [Next in Thread]