Re: Normal mode commands

[Marco Gerards]

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

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

The file size and the filename.  One line for every file or
directory.  Do you want me to add something else?

> > `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?

In that case I wonder why the terminal and rescue commands are not in
a module.

[...]

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

Sure.  What would be a good name?

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

It would be better if wildcards would be implemented by the shell.

> pupa> ls (*)/boot/vmlinuz*

This looks interesting.

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

I don't see any problems, why?

[...]

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

Depending on what?

[...]

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

Right.  How will root and rootverify differ for PUPA?

Thanks,
Marco