Re: getopt() argument permuting considered risky

[Måns Rullgård <mru at kth dot se>]

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

>> > "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.

>> > >    b) The existing behaviour is a security risk, as
>> > >       described above.
>> > >
>> > > 2. Perhaps Linux distributors should be setting
>> > >    POSIXLY_CORRECT in their default shell start-up
>> > >    files?
>> >
>> > Doing so would also alter lots of useful behavior from various GNU
>> > tools.
>> 
>> This is what I'm not sure of.  Do you know of specific examples?
>> 
>> (Oops, maybe you're meaning behaviours not related to getopt().
>> In that case I see your point, and, yes, it's true.  On first read,
>> I thought you were meaning that changing the getopt() behaviour
>> would remove the "useful behaviour", but I guess you are
>> making the more general point.)

That's what I was thinking of.

> Actually, this makes me think of a third suggestion:
>
> 3. Add an environment variable: GETOPT_POSIXLY_CORRECT (or
>    somesuch) to specifically affect the behavior of getopt().

That would probably be the least intrusive solution.

-- 
Måns Rullgård
mru@kth.se