[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
Re: [PATCH] stop run-time option processing after "--", felix . winkelmann, 2023/03/13