Re: PLT conformance, multi-arg flags, and spaces before arguments Matthew Flatt (27 Sep 2002 02:38 UTC)

Re: PLT conformance, multi-arg flags, and spaces before arguments Matthew Flatt 27 Sep 2002 02:37 UTC

At Thu, 26 Sep 2002 20:55:32 -0400 (EDT), Anthony Carrico wrote:
> On Thu, 26 Sep 2002, Matthew Flatt wrote:
>
> > On parsing multiple flag arguments:
>
> [...]
>
> I'm not very passionate about this issue. My objective was just to
> implement the POSIX/GNU conventions (or at least a general interpretation
> of those guidelines), so I'm still inclined not to add this feature.

That seems fine to me.

I should have been clearer --- I didn't mean to argue for this feature
in the SRFI. I was just responding to earlier comments.

> > On combining a flag and its argument:
> >
> > The other troublesome change for us would be allowing a flag's argument
> > to be combined with the flag (i.e., leaving out the space). This seems
> > to be a deprecated convention. (Posix guideline 6 says "don't do it,
> > but you can if you want". The SRFI says "for historical reasons".) Is
> > there strong support for continuing it?
>
> It is silly, and it is also strange that long arguments use "=", whereas
> short options take the next program argument (or the rest of the current
> one). I guess Unix wasn't designed, it just kind of evolved.
>
> > The SRFI seems to depart from both Posix and GNU (as documented) in
> > allowing multiple flag names to follow "-" *and* argument without a
> > space for the last flag. Is that actually supported by GNU, and/or am I
> > overlooking something in the Posix guidelines?
>
> POSIX: Options without option-arguments should be accepted when grouped
>   behind one '-' delimiter.
>
> GNU: Multiple options may follow a hyphen delimiter in a single token if
>   the options do not take arguments. Thus, -abc is equivalent to -a -b -c.
>
> It is open to a little interpretation, but I think Matthew is strictly
> correct. I followed what I thought was existing practice and liberally
> interpreted "the options" as "the leading options". This interpretation
> allows examples like those on the Debian tar man page:
>   tar -xvvf foo.tar
>   tar -xvvzf foo.tar.gz
>   tar -cvvf foo.tar foo/
>
> Matthew, do you believe that "foo.tar" should be treated as an operand, or
> are you just pointing out that the guidelines must be stretched to
> accommodate common practice?

Actually, I was concerned about this possibility:

  tar -xvvffoo.tar

I'm happy with

  tar -xvvf foo.tar

In other words, I like the more general sharing of a single '-'. It's
the token-collapsing convention that bothers me, especially when it's
combined with a shared '-', as in the former example above.

> I think that once you allow the trailing option to have an argument,
> it should behave the same as other option arguments.

We agree on this point, and that's why I'd rather not have token
collapsing anywhere with short-name flags. :)

Thanks,
Matthew