Re: Normal mode commands

[Yoshinori K. Okuji]

On Thursday 25 December 2003 19:57, Marco Gerards wrote:
> `ls' with the options:
>
> --long  -- Long list
> --all   -- Show all files
> --human -- File sizes in a human readable format

With --long, what do you want to display? I think this kind of question 
is more important.

> `boot' which has no options
>
> I think this one should be hard-coded in normal mode.  What about
> adding this to command.c like the terminal and rescue commands?

No, most commands should be implemented in modules. Why not?

> `cat' which has just one argument, a file name
>
> I assume you'd also like this command, otherwise I will explain why
> I'd like it.

I agree.

> `cmp' which has just two arguments, the file names

Likewise.

> `find' which has one argument, a file name

Actually, I don't like this command, because the behavior is quite 
different from GNU's find utility.

So if you want to keep the same behavior, I'd like to change the name of 
this command.

> Is having bash like wildcards useful for PUPA?  It would be nice if
> you can use find to locate all your kernels for example, don't you
> think?  Something like: "find linux-*" or "find gnumach-*".

Yes, but wildcards should be implemented in the shell rather than in 
find? If wildcards are supported, you don't need to have find any 
longer. Because you can do this instead:

pupa> ls (*)/boot/vmlinuz*

I don't know if this syntax is good, though.

> `set' to list all variables when no argument was given, otherwise you
> can do something like:
>
> set foo=bar
>
> pupa_command_execute should be able to parse "foo=bar" directly
> without using any additional command.  With `unset', which requires
> one argument, you can unset a variable.

Very good.

> This works all the same as bash so most users don't need to learn a
> new set of commands.  I think set and unset should be added to
> command.c because they are quite important, right?

Maybe.

> The same is true for insmod, rmmod and lsmod.

Yes.

> And there are some environment variables that should be supported.
> What about these?:
>
> PAGER  --  When set to 1 the pager is on.
>
> PREFIX --  Instead of the prefix command.
>
> ROOT   --  The currently used root.

Good.

> To be honest, I don't know how this should work.  For my idea it
> would be nice if there was a `root' command that checks the root
> device and sets the ROOT env. variable.  The rootnoverify won't exist
> anymore because the user can set ROOT directly.  I'm sure there are
> better ways to do this.  I have never used rootnoverify so all this
> might be stupid...

My idea is having "hooks" for variables. For example:

/* This hook is called with the variable name NAME and the argument ARG,
   whenever the user tries to set this variable to a new value.  */
static pupa_err_t
write_hook (const char *name, const char *arg)
{
  if (is_anything_wrong (arg))
    return PUPA_ERR_INVALID_ARGUMENT;

  do_something (arg);
  return PUPA_ERR_NONE;
}

PUPA_MOD_INIT
{
  pupa_register_variable_hook ("ROOT",     /* The name of a variable. */
                               0,          /* A read hook.  */
                               write_hook, /* A write hook.  */
                               ...);
}

You can monitor variables in this way. I think GDB has the same concept.

> I can add a PS1 and PS2 variable without any trouble if you think
> that would be nice.  I won't need it but it's not hard to do.

Not necessary.

Okuji