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.
On Thu, 26 Sep 2002, Matthew Flatt wrote: > On parsing multiple flag arguments: > ... > I mention this because it seems like employing " " or "," as a > flag-argument delimitter (e.g., for -L in MzScheme) would be making that > same mistake again. But Posix also has experience behind it, so what am > I missing? I had thought of that, and sort of hoped it would stay under the rug :). I must admit that this is a very good argument for the PLT convention. POSIX: When multiple option-arguments are specified to follow a single option, they should be presented as a single argument, using commas within that argument or <blank>s within that argument to separate them. I hate to be in the impossible position of defending a Posix guideline, but the best counter-argument I can come up with, is that the Posix convention allows sub-parsing an arbitrary number of sub-arguments, where-as the PLT convention does not (unless you enforce operands to follow all options, something relaxed by GNU). 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. Did anyone in the PLT-style camp try patching the reference code without breaking the POSIX/GNU compatibility. Did you like the results? > 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? [BTW, that was an honest question, I expected that this SRFI would generate some controversy, since it is based on something very ill defined]. GNU: An option and its argument may or may not appear as separate tokens. (In other words, the whitespace separating them is optional.) Thus, -o foo and -ofoo are equivalent. As for the "*and*" in Mathew's point, I think that once you allow the trailing option to have an argument, it should behave the same as other option arguments. Thank you for weighing in. As I wrote in the SRFI draft, "there are many common (often conflicting) ways take care of this task, so a custom processor is often necessary; however, many programmers (and their users) would welcome a convenient interface supporting common guidelines." It is an array-of-strings interface with a lot of historical baggage. I'm sure that many programs would benefit from a cool non-POSIX/GNU argument processor, but that would be another SRFI. -Anthony Carrico