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

[Peter Bex]

On Mon, Mar 13, 2023 at 09:35:53PM +0100, felix.winkelmann@bevuta.com wrote:
> > 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.

I know, my point is that this change breaks backwards compatibility.
Let's say one has a pre-existing program which has no flag handling
code.  For example a simple program that only accepts file names on
its command line, but doesn't do option processing.

Let's say the user would like to "harden" the invocation to said
program, they'd have to _add_ the "--".  This would then be interpreted
by said program as a file name.

My point is that said program would still be able to parse run-time
options (because that's baked in to each program).  Therefore, it makes
sense to have the run-time option parser be 100% transparent to the
program and have its own way of stopping processing, invisible to the
program.

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

Of course.  In fact, I think it would make more sense to simply tell the
runtime options parser to stop after the first non-"-:"-prefixed
argument.  That makes runtime argument stuffing harder and allows it
to play nice with _any_ option parser, and makes the "--" behaviour
automatically work if the program already handles getopt-style options.

Note that this is _also_ a backward compatibility breaker, but IMO the
lesser of two evils as it doesn't introduce spurious command line
arguments into existing programs.

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

Indeed.  It might make sense, but the point was to be able to disable
runtime option processing, and IMO that should be possible even without
requiring the program to cooperate.

Note that it's also a very easy thing to forget to handle "--" specially
in programs that don't use a gettext-style options parser (i.e., all of
the core tools!  If we do go with this approach, all those would need to
be patched to handle "--" as well because they all have hand-rolled
options parsers.  Most of my own programs do, too).

Cheers,
Peter

signature.asc
Description: PGP signature