pupa-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Argument parser


From: Yoshinori K. Okuji
Subject: Re: Argument parser
Date: Mon, 15 Dec 2003 19:19:16 +0100
User-agent: KMail/1.5

On Sunday 14 December 2003 02:14, Marco Gerards wrote:
> > 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?
>
> In the structure that is used to store the state of the parser you
> have to include a counter, for example:

A counter is not enough. You need complete information, but not only the 
number of arguments. Consider "ls foo -l bar -h baz".

> > 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?
>
> Possibly.  The function will be called for every argument.  If you
> would like to see an example I can write one.

It's too bad. It's far from simple. If you have an array, you can just 
do "argv[0]" and "argv[1]".

> > Ummh, you are right, ls uses -h for another purpose. But I don't
> > think this is so good.
>
> Why don't you like it?  The '-?' short option is already used by
> other GNU programs too, I don't remember GNU programs using '-h' for
> help, more often '-h' is used for other purposes.  AFAIK --help
> doesn't even have a short option.

Because -? is difficult to input in reality. If you implement shell 
wildcards, you must input it as "-\?", and backslash is really 
difficult to input in many keyboards.

> > 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.
>
> This means that it should be possible for PUPA to store stuff on
> disk.  This should not be hard to do, but this is something we need
> to discuss.  The best thing to me seems pre-allocating some blocks on
> disk (by using a file of course) and reading and writing to this
> file.

It can be implemented as "simple mathematics + savedefault", so you 
don't need any new feature actually.

> A bourne shell like language seems nice to me (especially because
> people don't have to learn a new scripting language).  Forth usually
> gives me a headache but I must admit I did not really try to write
> something useful using forth.

I share the same feeling with you.

Okuji




reply via email to

[Prev in Thread] Current Thread [Next in Thread]