This page is part of the web mail archives of SRFI 37 from before July 7th, 2015. The new archives for SRFI 37 contain all messages, not just those from before July 7th, 2015.
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