PLT conformance, multi-arg flags, and spaces before arguments
Matthew Flatt
(26 Sep 2002 19:09 UTC)
|
Re: PLT conformance, multi-arg flags, and spaces before arguments
Anthony Carrico
(27 Sep 2002 00:52 UTC)
|
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
Anthony Carrico
(27 Sep 2002 13:30 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