getopt() argument permuting considered risky

[Paul Eggert]

"Michael T Kerrisk" <mtk-lists@gmx.net> writes:

>    $ grep string "$user_supplied_filename"

> would normally be safe

No it wouldn't.  If $user_supplied_filename is "-" it reads stdin,
which typically will break the script.

This whole line of argument is a bit suspect.  Any paranoid script
should be vetting user-supplied-filenames anyway.  And slapdash
scripts are likely to be broken for many other reasons.  I don't think
the problem here is a serious one.

> 1. What are the chances of having this feature removed 
>     from glibc's getopt()?

Unlikely.  The code has been in the field for decades.  Like it or
not, it was put in there by someone who knew the POSIX spec well (and
even contributed to the spec, if memory serves).  Many people rely on
the current behavior.

As a practical matter, portable scripts cannot assume the
POSIX-specified behavior here.  At this point, I suspect it's more
likely that the POSIX spec will get changed than glibc.

> 2. Perhaps Linux distributors should be setting 
>    POSIXLY_CORRECT in their default shell start-up 
>    files?

No, POSIXLY_CORRECT breaks too many things.  And I don't like the idea
of GETOPT_POSIXLY_CORRECT either; it's not worth the hassle and opens
the floodgates for more XXX_POSIXLY_CORRECT vars.  Just fix your
scripts, if they're broken.  This is the least of your worries.