On 6/25/05, Joel VanderWerf <vjoel / path.berkeley.edu> wrote:

> >>Is that the right behavior though? Maybe after the first non-option
> >>string (in this case "please use the"), the parser should assume that
> >>the rest of the strings are also not options.
> >
> > Isn't the POSIX behavior to use "--" as a option/non-option barrier?
> >
> > I.e.:
> >
> > ls -l  # lists all files in long format
> > ls -- -l # list a file named "-l"
> 
> On the command line, yes. But I'm asking about arguments to the
> OptionParser#on method. Are you suggesting to use "--" as a barrier
> string in that context too?

Not necessarily asking for (nor NOT asking for) that behavior, but I
do think that it would be an easy metaphor to consider carrying
forward.  Consistency and all that... (yeah yeah, I know the Emerson
quote. <g>)

> It seems to me the best solution is to assume that once #on has
> encountered a non-option (i.e., descriptive text) in its list of
> arguments then all subsequent arguments should be treated as descriptive
> text. That would ensure that, if your text refers to option names, then
> reformatting your text will not cause them to be treated as options.
> Would any useful behavior be lost that way?

Probably not.  I can't say that I've seen (m)any command line tools
that would behave differently (although the "gem" command seems oddly
backwards to me in this...)