Re: [PATCH] Making exported variables really global

[Andreas Born]

Am 04.03.2012 18:55, schrieb Andreas Vogel:
> 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).
Personally, I like that solution best.
What's the problem? Currently there's no way and absolutely no way to 
reliably get data from a submenu to a parent menu. This makes it 
impossible to use submenus e.g. for settings menus.
By sharing the context this would not only be consistent with 
menuentries but while significantly improving the situation it can't 
cause any major harm. In case somebody relies on variables being local, 
I'm pretty sure there's always a solution to achieve similar behaviour 
by multiple variables. So making the context shared wouldn't create any 
real troubles. But the way it is now - separate context for submenu - 
does create problems. For example no settings menus and there's no 
solution for that need at all! As in my opinion this is a major 
applications for submenus something should be done about it.
> 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).
While I could live with such a solution, it seems just flawed to me. 
Such a construct introduces unecessary complexity and inconsistency. If 
there's such a switch for submenus why shouldn't there be one for 
source, menuentry, ...?
As pointed out previously a separated context offers pretty much nothing 
that's not possible with a shared one, so in most cases --shared 1 would 
be fine. But having to write every time --shared 1 after a submenu or 
submenu_shared is quite cluttered. The use of such constructs doesn't 
create the impression of a well designed language for my part either.
> 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.
I don't really like this one. It introduces a completely new and 
complicated behaviour, which is not commonly found among other software, 
especially not with bash.
I see the risk that even with very good documentation, this 
implementation leads to unexpected results. And I think it could happen 
that users won't be able to understand what's causing the problems 
because shared and local variables are mixed. Such unintuitive solutions 
should be avoided wherever possible and there are two other 
possibilities which are in my view much better.


Anyway, just some thoughts from a user.

Andreas