This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: getopt() argument permuting considered risky
- From: "Michael T Kerrisk" <mtk-lists at gmx dot net>
- To: Måns Rullgård <mru at kth dot se>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Wed, 4 Aug 2004 12:23:57 +0200 (MEST)
- Subject: Re: getopt() argument permuting considered risky
- References: <yw1x7jsfw6od.fsf@kth.se>
> >> > [why argument permutation is bad]
> >> >
> >> > > Some suggestions:
> >> > >
> >> > > 1. What are the chances of having this feature removed
> >> > > from glibc's getopt()?
> >> > >
> >> > > I realise that the argument is probably: "it will
> >> > > break existing applications". Some responses:
> >> > >
> >> > > a) Is that really true: are there really applications
> >> > > that depend on this non-standard behaviour?
> >> >
> >> > The only difference I see would be that the user would be required to
> >> > pass option arguments before non-option arguments.
> >>
> >> Yes, but I'm not sure what point you are making?
>
> My point is that everything that is possible with the current behavior
> will still be possible, without any changes to applications. Those
> applications which use/allow the permutation will work equally well
> without it, if the user knows to place the options correctly on the
> command line. IMHO, this is no huge requirement, since many
> applications already depend on the order of options and non-options.
Affecting the interactive user is perhaps the more minor problem.
Potentially, there may be existing scripts, or (for example)
instances of the use of execve() (and friends) in C programs
written with glibc's getopt() in mind that depend on the
permuting behaviour. I don't know of specific cases (which is
why I asked), but if they exist, then changing the getopt()
behaviour would break them.
Cheers,
Michael
--
Michael Kerrisk
mtk-lists@gmx.net
NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler!
GMX DSL = supergünstig & kabellos http://www.gmx.net/de/go/dsl