Re: shell wildcard expansion (un)safety

[Jakub Wilk <jwilk () jwilk net>]

* Solar Designer <solar () openwall com>, 2024-11-06 05:12:
> Can the shells do anything to mitigate this?

Bash and glibc's getopt() tried to mitigate this back in 1996/1997, but 
it didn't work out.

* https://sourceware.org/cgit/glibc/commit/?id=bf079e19f50d64aa5e05b5e1
> author  Zack Weinberg <zackw () panix com>        2017-03-29 16:58:58 -0400
[...]
> getopt: remove USE_NONOPTION_FLAGS
>
> glibc's implementation of getopt includes code to parse an environment 
> variable named _XXX_GNU_nonoption_argv_flags_ (where XXX is the current 
> process's PID in decimal); but all of it has been #ifdefed out since 
> 2001, with no official way to turn it back on.
>
> According to commentary in our config.h.in, bash version 2.0 set this 
> environment variable to indicate argv elements that were the result of 
> glob expansion and therefore should not be treated as options, but the 
> feature was "disabled later" because "it caused problems". According 
> to bash's CHANGES file, "later" was release 2.01; it gives no more 
> detail about what the problems were.
>
> Version 2.0 of bash was released on the last day of 1996, and version 
> 2.01 in June of 1997. Twenty years later, I think it is safe to assume 
> that this environment variable isn't coming back.

--
Jakub Wilk