Re: Priority of --help

[Bob Proulx]

Eric Blake wrote:
> On the libvirt list, the question was raised on what happens if you have
> a long command line, but then forget the arguments of an option that
> requires an argument, so you try to add --help in-place to learn them.

It doesn't seem difficult to do C-a first before adding --help.

> In the name of a better user experience, should we audit all coreutils
> to find places where we have early exits during option parsing, and fix
> them to be a two-pass parse so that 'program --option-that-takes-arg
> --help --help' universally prints help (from the second --help that
> landed in the option position) rather than complaining about the first
> --help being an invalid argument to the option?

Let me make an interpretation.  You want to parse options from right
to left instead of from left to right.  (Yes, I know that isn't what
you are proposing.  I am just working the debate.)

The feeling being proposed is that parsing from left to right doesn't
match with a user typing on the keyboard because wherever they are on
the line is at the right and therefore the right most side of the line
should be the highest priority.  That is basically what is being said
when one allows a high priority option to the right of lower priority
options on the left.

So I know that actually you are proposing a two pass parsing process.
Pass one look for high priority options.  Pass two if there aren't any
high priority options look for lower priority options.  But there are
only three magic numbers in the universe.  0, 1, and many.  Two is
just a special case of "many".  Whenever I hear two I always read that
as "many".

To be blunt, I don't like it.  In this locale we read from left to
right.  We type in from left to right.  I think left to right should
be the priority order.  It is easy to understand.  It is easy to
document.

Frankly I have never liked the present GNU getopt parser that allows
options anywhere on the line.  That is a reason for needing the -- end
of options option that isn't needed otherwise.  For me it created a
complication that was better when it was simpler.  Creating a multiple
pass option approach with a prioritized list of options I think adds
more to the complexity than it provides in user interface capability.

If you try to teach a beginner the command line today there are
already too many special cases.  I have been trying to explain them to
people recently and there is a lot of history that explains how we got
to this point.  A new person hasn't seen any of it.  Keeping things
simpler is better.

Is it really too difficult to C-a to the beginning of the line?

And as far as long command lines goes one could C-k to kill the entire
rest of the line and then C-y to paste it back in after reading the
help.

I do tend to do this sequence sometimes.

  $ foo one two three four five six seven eight nine ten
                                                        ^ cursor
                                                        C-a
  $ foo one two three four five six seven eight nine ten
    ^ cursor
    C-k
  $ ls  # or 'foo --help', or whatever
  ...
  $ 
    ^ cursor
    C-y
  $ foo one two three four five six seven eight nine ten
                                                        ^ cursor

Then continue editing the line with the new found information.  If I
have killed something else in between then C-] y (M-y, ESC y) rotates
back through the kill ring selecting the previous until I arrive at
the one I want.

Just my 2 cents.

Bob