On Thu, 22 May 2014 09:31:24 +0200 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com> 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
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
