Re: [PATCH] Allow user-defined functions to override builtins.

[Glenn Washburn]

On Thu, 22 May 2014 09:31:24 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> wrote:

> On 19.05.2014 08:37, Glenn Washburn wrote:
> > Currently, builtin commands take precedence over user-defined
> > functions.  This patch reverses that precedence, so that users can
> > "override" builtin commands.  Builtin commands may be accessed by
> > issuing the command prefixed by an '@' character.
> > 
> Overriding builtins sounds like a bad idea. For once it creates a
> language which is heavily dependent on context. This gets hairy and
> messy very fast.

I think that the power it provides compensates for that.  The user
should definitely know what they are doing, but I'd expect that of
anyone writing grub functions.  Most modern programming languages,
including bash, which grub script appears to be modeled after, supports
this.  Ultimately it allows for more flexibility and power for the grub
user (at the cost of allowing them to shoot themselves in the foot if
they so desire).

> > My motivation for this change is to hook insmod in loaded
> > configfiles which set $prefix to a different location than
> > desired.  If there are any changes needed to help get this
> > functionality included, please let me know.
> > 
> Could you detail your usercase more? $prefix is the location where
> modules are, why not just set it to right location?

The problem is that I want to load arbitrary grub config files from
various installs and have them work.  Ideally setting the correct root
and prefix, then loading the config file should work.  However, in some
(many?) cases this causes grub to crash because the config file will
invariably load modules which are built for the grub that installed the
config file, not the grub that is loading the config file.

But the prefix variable is used for other things in the loaded config
file.  So if I change the prefix to be that of the running grub to load
the correct modules, other parts of the config will break (for
instance, loading fonts or locales).

So my solution is to hook the insmod command, so that modules are
loaded from the path specified by the prefix_modules variable.  I had
been thinking of suggesting on the list to have separate variables for
the different uses of $prefix, but I think this is a better approach.

Another use case I can image is it could be used to disable certain
commands on the command line (but still allow them to be available to
scripts.  And I could probably come up with more cases.

This is definitely a useful feature for me.
Glenn

signature.asc
Description: PGP signature