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