Please explain what problem you try to solve. Bash doesn't do anything
of the kind. Why should we? Looks like a solution without a problem
I'll provide you an example script similar to one which I use, heavily
simplified to present only the specific issue:
set kern_tty=tty
menuentry "Start system" {
linux /kernel tty=$kern_tty […]
}
submenu "Kernel console configuration options" {
menuentry "Use serial console @ 115200 bd" {
set kern_tty=ttyS0,115200
export -g kern_tty
}
menuentry "Use screen" {
set kern_tty=tty
export -g kern_tty
}
}
submenu "System distribution" {
# […]
}
This is my primary use-case. I want to change environment variables
used from scopes above the scopes in which the submenus are executed.
This allows me to create an user-friendly bootable USB/CD image allowing
to perform configuration of the system before starting the system. Since
I have multiple options to configure, using deeply nested submenus would
be tiring for the user (since they would have to go through all the
menus on every boot) and it would not allow to save the settings for the
next boot using save_env.
Bash does have this, but it is the default behavior, unlike the behavior
in GRUB for the ‘submenu’ command. Consider this bash script:
$ cat test.sh
foo=bar
function uwu {
foo=baz
}
uwu
echo $foo
$ bash test.sh
baz
Assignemnt performed in a function takes effect in the parent scope.
If you run equivalent script in the GRUB (just prepend ‘set’ to the
assignment lines), the behavior is still exactly the same. However,
this is not true for when used from the ‘submenu’ command. Try this
in the GRUB:
set foo=bar
submenu "foo configuration" {
menuentry "set foo" {
set foo=baz
}
}
menuentry "display foo" {
echo $foo
read
}
When the latter menu entry is executed, it will still display “bar”,
because the ‘submenu’ creates a new environment variable scope.
The only two alternatives to this would be either creating a completely
custom interface using ‘echo’ and ‘read’, or creating a single flat
menu. The first option would make the pre-boot user interface harder to
use. The latter option will cause that the menu is a incomprehensible
mess, when there is a lot of configuration options.
And because I don't want to break compatibility with existing scripts,
I decided to make the exporting variables up from submenus explicit.
Thanks.
bindiff
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
