This is the mail archive of the
mailing list for the glibc project.
Re: getopt() argument permuting considered risky
- From: Paul Eggert <eggert at CS dot UCLA dot EDU>
- To: "Michael T Kerrisk" <mtk-lists at gmx dot net>
- Cc: libc-alpha at sources dot redhat dot com, Geoff Clare <geoff at gclare dot org dot uk>
- Date: Wed, 04 Aug 2004 10:40:18 -0700
- Subject: Re: getopt() argument permuting considered risky
- References: <email@example.com>
"Michael T Kerrisk" <firstname.lastname@example.org> 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
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.