Re: [PATCH] Making exported variables really global

[Andreas Vogel]

Am 04.03.2012 17:16, schrieb Andreas Vogel:
> Am 04.03.2012 15:10, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> On 04.03.2012 14:47, Andreas Vogel wrote:
>>> Am 04.03.2012 14:18, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>>>> On 04.03.2012 14:08, Andreas Vogel wrote:
>>>>> Hi all,
>>>>>
>>>>> This tiny patch makes exported variables really global. Right now
>>>>> exported variables are set in the context of a submenu when running
>>>>> it.
>>>>> But any changes to those vars are lost when leaving the submenu. This
>>>>> patch sets and exports all vars in the calling context for the submenu
>>>>> which are exported in the context of the submenu.
>>>> We follow the bash behaviour. And the bash behaviour is exactly what
>>>> GRUB does:
>>>> address@hidden:14:15:11:~/grub2/bzr/mainline$ bash
>>>> address@hidden:14:15:15:~/grub2/bzr/mainline$ export XYZ=x
>>>> address@hidden:14:15:19:~/grub2/bzr/mainline$ exit
>>>> address@hidden:14:15:20:~/grub2/bzr/mainline$ echo $XYZ
>>>>
>>>> address@hidden:14:15:24:~/grub2/bzr/mainline$
>>>>
>>> I understand your point, but IMHO we do need to be able to set global
>>> vars in submenus, that's my patch about.
>>>
>>> Otherwise how can you use a "Settings..." submenu to configure
>>> environment variables which are used by other menu entries for booting?
>>> The analogy with bash is not useful here.
>> We can add a command with traits of both "menuentry" (same context,
>> same menu) and "submenu" (new context, new menu), sth like
>> submemu_source (same context, new menu) 
> Yes, that's one possible solution.
>
> Why establishing a new command instead of using an option for submenu,
> let's say "--export 0|1"?

Please let me summarize this issue after thinking about it again:

Right now the submenu command opens a new context. All exported vars in
the parent context are also exported to the new context of the submenu.
This is the same behaviour like for Unix shells. The menuentry command
doesn't open a new context, it runs in the context of the caller.

For submenus there are 3 possibilities for how to behave:

1) Create a new context and run the submenu in the new context. After
exiting the submenu, all variables in the submenu context are lost (this
is the current behavior).

2) Don't create a new context and run the submenu in the same context as
the caller. This would be the same behavior as for menuentry commands.
This can be implemented by having a separate submenu command (e.g.
submenu_source, or submenu_shared) or introducing a new submenu option
(e.g. --shared 0| 1).

3) Create a new context for the submenu. On exit all exported
environment variables in the submenu context are exported to the context
of the caller. By this you have the advantage that all local
(unexported) variables in the submenu context are really local, even for
further submenu entries in the submenu, but all exported variables are
global for the whole menu tree. Like for option 2) this can be achieved
by establishing a new command or using an new option for the submenu
command. But this behavior can also be the default behavior for submenus
without the need to be able to enable/disable it.


As I'm quite unfamiliar with the internal design of GRUB, I'm not sure
what option is most adequate, even though I'd vote for option 3).

I cannot see the point why it's so important to run a submenu in its own
shell (= context) and why menuentries of a submenu shouldn't be able to
access the same environment variables like the menuentries of a parent
menu. In my opinion the analogy to shells and sub-shells in Unix isn't
really adequate because for me a menu tree is an entity on its own,
regardless of being implemented as commands (like in GRUB) or using some
kind of configuration file defining the menu tree.
On the other side i see some advantages for submenus having their own
context, e.g. to have local environment variables which don't 'pollute'
the calling context. That's the reason why I vote for option 3) with the
addition that it's not

Please excuse my lengthy exploration about this issue, but it's a very
important point for GRUB. Not being able to set globally defined
environment variables (= exported toplevel context vars) in submenus
prevented until now having customization submenus and doing a search in
I-Net about this issue, I've found a lot of posts desperately asking for
this feature.

As you can see from my patch in the OP, the modification is quite simple
and from what i can see the implementation of the other options
presented above are not much more complicated.

I'm willing to implement and supply whatever will be decided in the hope
that we can get it into the upcoming version. We just need to get a
final decision. So any comments are, as always, highly welcomed.

Andreas