Re: Argument parser

[Yoshinori K. Okuji]

On Monday 08 December 2003 00:39, Marco Gerards wrote:
> It's just like all other ARG_TYPE_'s.  It checks if the used argument
> is of the right type.  So the argument parser can check if the
> arguments are of the right type.  In this case it checks for a single
> char.  Does this answer your question or did I misunderstand you?

Well, my question is that I don't see how useful ARG_TYPE_CHAR is.

> Right.  I have used strtoul out of laziness for now.  I will write
> pupa_strtol or change this into ARG_TYPE_UINT.  To me it seems
> ARG_TYPE_UINT is ok, what do you think?

Maybe. I'm not sure if it is a good idea to specify the type of an 
argument in this way.

> > * Does it support normal arguments, like the "foobar" in "ls
> > foobar"?
>
> It does.

Can you tell me how to get normal arguments?

> > * shortarg should have the type int instead of char.
>
> I can do this.  Why do you want this?

Because sometimes it is better to have only a long option. In this case, 
it is a custom to specify a negative integer for the character code of 
a short option. You can see this in the source code of the grub shell.

> > For example, you can extend the pupa_register_command to accept
> > information on options of a registered command. Then, probably it
> > is also necessary to change the arguments to a callback function
> > for a command.
>
> I'm not sure what you mean with this callback function.

For example, the function "pupa_cmd_hello" in the hello module.

> To be honest, I have my doubts about using something like
> "pupa_parser_get_option".  There is not much code required for this
> parser callback function.  And this pupa_parser_get_options will be
> much harder to write.  To me it seems the best that the command is
> told which options there are, it shouldn't ask for them.  Perhaps I
> just worked too often with argp and I got brainwashed by it. :)

A similar thing applies to me. I'm now used to scripting languages, so I 
believe that smaller code is better. Zero code is the best. :)

BTW, if you don't care about the efficiency, it is quite trivial to 
write such a function -- You just need to start parsing from the 
beginning each time when pupa_parser_get_option is called. This is 
stupid, but computers are fast enough.

> What about adding the struct hello_arguments (for example) to the
> options structure and using this to tell the command which options
> are used (see my example in my previous mail now this works).  If
> this doesn't make sense to you I can show you some code to
> demonstrate this.

Please. As C is a strong-typed language, I guess it is not trivial to 
pass such a structure.

> It would make sense to call the command (pupa_cmd_hello for example)
> with a filled argument structure in this case.  However, is it
> required to call it with a list of remaining arguments (like 'foo' in
> 'ls foo')?  This is only a good idea if this is used because it is a
> lot of work to implement.  Even if this isn't implemented it is
> possible to parse those options with "option_parser".

That depends on how to scan arguments. If you assume POSIX semantics, 
you can pass a part of arguments as it is. In POSIX, this has 2 
arguments:

ls -a foo -l

while GNU treats -l as an option.

Personally, I don't think PUPA should follow GNU strictly in this case, 
because it is quite rare for people to notice this difference.

> I have started working on normal mode today.  Can you explain me even
> a bit more how you'd like to see it?

I try. I have many vague ideas about it, but not clear yet.

> I expect the main job is just to implement all commands GRUB has.

No. Please select which commands should be implemented, which commands 
should be heavily modified, which commands should be removed. 
Compatibility is not very important.

> Should the user load all these commands by just loading them by
> adding them to the core image or by loading them using pupa.conf?

I think the best way would be 1) to load all modules specified in the 
config file, then 2) to load some basic commands implicitly.

> Do
> you want to make a subdirectory for every command in the PUPA
> sourcetree like it was done for "hello"?

No. "hello" has a good reason to have its own directory, because it is a 
general example of how to make a module for PUPA. But digging many 
subdirectories sounds awful for me.

> Is it ok to make the commands a bit more feature rich than the GRUB
> commands?

Sure. But I'd like to apply the same rule as GRUB here: Add new features 
only if they are really useful. I don't want to see the chaos again.

> ls [OPTIONS...] [DIR]
> List devices and files
>
> -l, --long              Show a long list with more information
> -h, --human-readable            Print sizes in a human readable
> format -a, --all               List all files
>     --more              Wait for a keypress after each displayed
> screen -?, --help              Display help
> -u, --usage             Show how to use this command

--more is bad. It should be implemented in a general way. GRUB does this 
by an internal pager functionality. I don't know if PUPA should use 
another way.

You shouldn't use -h. I'd like to reserve it for the short version of 
--help.

> Are there some GRUB commands that shouldn't be implemented?  I had a
> look at the GRUB commands and some were a bit confusing, for example:
> fstest, testload, ioprobe, etc.  I'd appreciate any information about
> the commands that should be added and how you'd like to see this.

Yes, there are many bad commands in GRUB. For example, the behavior of 
debug is inconsistent against that of fstest. install is like an 
assembly programming. rootnoverify instead of "root --noverify". They 
suck.

Apart from such stupid commands, I think it would be better to make PUPA 
more shell-like and to reduce the number of commands. That is, it is 
good to support variables so that you don't need to type different 
commands just for setting some information.

For example, I'd like to do this:

pupa> printenv
ROOT=(fd0)
DEBUG=0
pupa> tmp=$DEBUG
pupa> DEBUG=1
...do some tests...
pupa> DEBUG=$tmp

Support for variables is desirable. It makes PUPA very flexible, and 
make sure that PUPA is more consistent than GRUB.

BTW, there is a plan to add a scripting language into GRUB. It is 
impossible with GRUB 0.x, but it is possible with GRUB 2 (PUPA). I 
still don't know what kind of language would be the best, though.

Okuji