I really like these, I'll miss the -:b . My desired solution would be a way to turn off some or all switches. For some programs I'd disable for production, e.g. setuid, static compiled security related utils, we do a lot of these and I've wondered about security implications of these switches.
On Mar 13, 2023, at 11:13 AM, Peter Bex < peter@more-magic.net> wrote:
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").
Just dropping "--" from the arguments list is probably also not
desirable, because our option parser doesn't have any getopt-like
behaviour, so -xyz or --xyz aren't treated specially in any way.
Perhaps the safest here is to stop processing after reading ":-"
or some such (and discard it!) - that would be guaranteed to never
pass through to the program anyway, because it might be a runtime
option and already gets intercepted by the option parser.
Only potential issue is that it's not exactly standard when compared to
other programs...
What do y'all think?
Cheers,
Peter
|