[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Making exported variables really global

From: Andreas Born
Subject: Re: [PATCH] Making exported variables really global
Date: Mon, 05 Mar 2012 00:39:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120220 Thunderbird/10.0.2

Am 04.03.2012 23:48, schrieb Andreas Vogel:
First of all thanks for your detailed comment.

Am 04.03.2012 22:03, schrieb 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.
It seems you are missing the point here. Option 1) describes the
situation like it is right now and means not to change the code and not
being able to have submenus which are able to set variables in the
callers context. As far as I understood Vladimirs first answer, there is
already some kind of common understanding that this is something what
should be changed in the future.

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.
As far as I understood your comment, you're voting for option 2) but
without needing to specify that the context should be shared with the
calling context. In other words sharing the context should be enabled by
default. Right?
Yes. Somehow missed that 1) wasn't about this. Sorry. Let's call it 4), which would be: no new context is created with submenus.

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.
The rule for this option is very simple and can be expressed in one
sentence: "Regarding the menu system, all exported variables have a
global scope."
Yes, but no matter where and how prominent you put it who reads this?
And not introducing the complexity of contexts with subshells, which offer little benefit here, makes it even easier.
BTW, right now GRUB makes a difference between local (unexported) and
global (exported) vars: global vars are "handed over" to the context of
submenus, local vars not.
That's the same distinction subshells make so it's a common and well-known concept.
  Options 3) just enhances this paradigm and
treats global vars as read/write instead of readonly.
We actually then have three cases (there are 2 with 4) and even with 2) ):
 1) local variables: only visible in the current context
 2) exported/global variables: copied to new contexts
 3) really global variables: copied back and forth between contexts
This is unnecessarily complicated and using 3) only with a special command like submenu doesn't make the distinction easier to grasp.
In my view this is even easier:
"In the menu system there is one shared context."
And this behaves like menuentries.
The comparison with bash is senseless - we are talking about a menu
system and not about subshells in general.
Bash and it's concepts are well known. On the other hand introducing new, not commonly used concepts makes it unnecessarily hard to use and understand the grub shell. Why make it complicated if you can keep it simple?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]