Re: Argument parser

[Yoshinori K. Okuji]

Hi Marco,

On Monday 08 December 2003 19:16, Marco Gerards wrote:
> > Well, my question is that I don't see how useful ARG_TYPE_CHAR is.
>
> I had nothing in mind, I just added it for completeness.  I can
> remove this one.

Then, it is better to remove it. If you find any situation where 
ARG_TYPE_CHAR could be useful, you can re-add it later.

> Well, this is a feature of popt I really liked.  This way the parser
> takes care of type checking so the command doesn't have to do this.
> This can reduce code size a bit and it is just convenient.

I see.

> > Can you tell me how to get normal arguments?
>
> In the example the `option_parser' function will be called with as
> key `PUPA_KEY_ARG' and the argument in ARG.

Isn't it difficult? For example, if you define a command which takes two 
essential arguments, how do you implement this command with your 
parser?

> The advantage of my approach is that the code related to the
> arguments and the code of the command itself are truly separated. 
> Another advantage is that it is easy to detect errors with the
> existing code and to integrate the "--help" and "--usage" arguments.

Automatic "--help" option is really great. I like it very much.

> With my parser "ls -a foo -l" works perfectly.  Actually it is not
> hard at all to make it GCS complaint.

It is easy until you start implementing the real function of ls. This is 
the same question above, but how do you separate an option parser from 
the real function completely? Using a linked list to store arguments?

> I assume I have some freedom here.  You can have a look at my patches
> and we can discuss them if you'd like a command or not.

Exactly. But I prefer dicussing what should be implemented before you 
start implementing things, so that you don't lose your time 
unnecessarily.

> I thought about this too.  I actually wrote some generic code to do
> this today.  With my code you can put the pager on and off.  It is
> easy to change this so it works like GRUB.  I didn't know about this
> feature because I'm still using GRUB 0.90 :(.

Please take a try with the latest. 0.90 is too old.

> I have chosen to use "-?" as the short version of "--help" because
> all programs that use argp, of which many GNU programs I guess, have
> that as the short option too.  The reason to use "-h" for ls is that
> this is what users might expect because the GNU version of ls works
> the same way.

Ummh, you are right, ls uses -h for another purpose. But I don't think 
this is so good.

> What is the advantage of such scripting language?  What kind of
> problems can be solved using such language?  Please let me know if
> you know what you want to do.

That's the same question as RMS asked me.

In brief, because there are many unusual requests for GRUB. Most of them 
are not useful for ordinary users at all. And, sometimes a request is 
only useful for one who asks it. So I think it is really stupid to add 
a new command or a new option into GRUB when a new feature is 
requested.

For example, there is a wish that you can "rotate" the default boot 
entry. I think it would be even difficult for most people to just 
understand why it is useful. Implementing this feature is quite easy, 
but I don't think it is worth doing that in the official source code.

For such a rare wish, a scripting language enlightens people to extend 
GRUB by themselves very easily.

Another reason is portability. Writing portable C code is a nightmare.

If you want to see more details, see the archive of bug-grub. But I 
guess you know how a scripting language is useful, as you understand 
variables are useful. Variables are a feature required for a scripting 
language, aren't them? If you think variables are useful, why not 
conditionals? Don't you think this kind of code would be nice:

if test $TERM = serial; then
  extra_args="console=ttyS1"
else
  extra_args=""
fi

linux /boot/vmlinuz root=/dev/hda1 ro $extra_args
boot

By a scripting language, I don't mean a feature-rich language, like 
Python or Scheme. In a past discussion, Gordon preferred a meta 
language, but I myself prefer a simple and small language, such as Lua, 
Forth, or Bourne shell. :)

Okuji