Re: Argument parser

[Marco Gerards]

"Yoshinori K. Okuji" <address@hidden> writes:

> 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.

I had nothing in mind, I just added it for completeness.  I can remove
this one.

> > 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.

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.

> > > * Does it support normal arguments, like the "foobar" in "ls
> > > foobar"?
> >
> > It does.
> 
> 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.

> > > * 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.

Oh, right.  I have used positive numbers starting with 1 for this.

> > > 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.

Ok.  Can I remove argc and argv too?  These aren't required anymore,
right?

> 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.

Yes, this is the main problem I had with this approach, starting
scanning all over.  The other main problem I had with this is that it
increases the size of the binary and that it is harder to read.

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.

> > 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.

Ok.

> > 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.

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

> > 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.

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.

> > 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.

Ok.

> > 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.

Ah, good. :)

> > 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.

Ok.

> > 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.

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 :(.

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

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.

> > 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.

Right.

> 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.

Oh, this would be nice.  Perhaps I will do this too.

> 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.

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.

Thanks,
Marco