> Date: Wed, 29 Apr 2009 16:32:38 -0400
> From: James Carlson <james.d.carlson at sun.com>
> Subject: Re: PSARC 2009/228 ls enhancements (draft opinion)
> Message-ID: <18936.47462.564131.634760 at gargle.gargle.HOWL>
>
> Danek Duvall writes:
>> On Wed, Apr 29, 2009 at 11:51:32AM -0700, Garrett D'Amore wrote:
>>
>>> The second concern pertained to the fact that for some of
>>> those same options, the presence of an argument is optional.
>>> The members present felt that while such an "optional argu-
>>> ment" might be ambiguous for a short flag, for long options
>>> there is no ambiguity (because of the separating "="), and
>>> hence the behavior is acceptable.
>> Long options aren't required to be separated from their option arguments
>> with an equals sign, though they can be -- they can also be separated by a
>> space:
>>
>> /usr/gnu/bin/ls --sort none
>>
>> and
>>
>> /usr/gnu/bin/ls --sort=none
>
> Ouch. That's not what the original project actually defined.
>
> If that's really what's being parsed with an optional argument, then I
> would withdraw my comments. Such a construction would need an
> explicit "the ARC knows this is wrong, but we're approving it anyway
> because of compatibility" note.
Jim,
The reason I asked to discuss ls during yesterday's meeting is that the
materials provided in the initial mail (before the man page was added to
the case directory) contained the following:
--color[=WHEN], --colour[=WHEN]
which shows WHEN as an optional option-argument to the --color and
--colour long options and indicates that the '=' is not required.
Since the description of the function that the case says is being used
to parse options says that the '=' can be replaced by a <blank> and the
next argument then becomes the option-argument the command line:
ls -l --color auto
is ambiguous. It can mean display all files in the current working
directory in color when the command is run from a tty, or it can mean
list the file 'auto' never using color. The commands:
ls -l --color=auto
and
ls -l --color= auto
are not ambiguous, but these are not the only allowed forms.
It also listed:
--time-style=[STYLE]
which shows that the '=' is required for this long option, and
presumably means that if STYLE is the empty string it is equivalent to
--time-style=locale.
The man page doesn't show any '=' in the descriptions of
--block-size size
--color when
--colour when
and
--time-style style
In this context, I'm not sure what any of these four long options
are supposed to do if an '=' is given on the command line, but it at
least seems to require that the option arguments are mandatory.
The man page also does not list any of the new long options in the
SYNOPSIS section and didn't make any adjustments to the ATTRIBUTES
section in the places where it indicates that -A, -b, -e, -E, -h, -S,
-v, -V, -@, -/, and -% are not covered by the standards (thereby
indicating that these new long option are required by the POSIX and
SUS specs. I assume all of these issues will be fixed before the
man page is published, but I would like the project team to acknowledge
that this needs to be fixed.
- Don
