Re: cmdline.ss library in PLT

[Anthony Carrico <acarrico@xxxxxxxxxxxx>]

On Tue, 24 Sep 2002, Robert Bruce Findler wrote:

> > 2. Cmdline seems to support more than one argument per option. Args-fold
> > supports 0 or 1 arguments per option, following the lead of POSIX/GNU
> > guidelines.
>
> This turns out to be useful for many things. One I use a lot in plt
> scheme is loading a library:
>
>   mzscheme -L errortrace.ss errortrace -r myscript.ss
>
> is a convient way to debug my script: the first three arguments specify
> that the debugging code is loaded before the script is executed. The -L
> flag means "take the next two arguments and pass them to `require' as a
> library". In this case:
>
>   (require (lib "errortrace.ss" "errortrace"))
>
> Without multiple argument commandline options, this becomes tricky.

I can see how this would be useful. You can actually almost do it with the
current args-fold, by collecting the additional arguments with the
operand-processor (I say almost, because you couldn't catch extra
arguments that look like options), but obviously it would only be
realistic to do this in a pinch for a quirky interface.

> Does the GNU/POSIX spec give a rationale for only allowing single
> arguments?

I haven't seen any explicit rationale, as in most areas they seem to have
just standardized the historical design.

I have some questions about multiple arguments, since I have never used
them or seen them used:

1. What do they look like?

Long option arguments look like this:
  --foo=bar

so do long option multiple arguments look like this:
  --foo=bar1 bar2

Does this seem strange, somehow?

Short option arguments look like this:
  -fbar
or
  -f bar

so do short option multiple arguments look like this:
  -fbar1 bar2
or
  -f bar1 bar2

2. How do multiple option arguments interact with optional option
arguments? There is already ambiguity which must be resolved when dealing
with optional option arguments, and with grouped short options, do
multiple option arguments make things worse? Perhaps not.

3. Usually when you need something like multiple option arguments, you
just sub-parse a single option argument. For example:

  -f "bar1 bar2"

Given this existing idiom, is it worth upsetting the status quo with a new
feature? Would it confuse application users, who probably expect the old
idiom?

  -Anthony Carrico