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: Måns Rullgård <mru at kth dot se>
- To: "Michael T Kerrisk" <mtk-lists at gmx dot net>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Wed, 04 Aug 2004 12:56:08 +0200
- Subject: Re: getopt() argument permuting considered risky
- References: <yw1x7jsfw6od.fsf@kth.se> <26812.1091615037@www49.gmx.net>
"Michael T Kerrisk" <mtk-lists@gmx.net> writes:
>> >> > [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.
That's of course a potential problem. I didn't think of that.
--
Måns Rullgård
mru@kth.se