From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1S4KEu-00024L-Qf for mharc-grub-devel@gnu.org; Sun, 04 Mar 2012 17:49:16 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4KEs-00024F-Jk for grub-devel@gnu.org; Sun, 04 Mar 2012 17:49:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4KEq-0003KG-Ee for grub-devel@gnu.org; Sun, 04 Mar 2012 17:49:14 -0500 Received: from wp191.webpack.hosteurope.de ([80.237.132.198]:56104) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4KEq-0003KC-4j for grub-devel@gnu.org; Sun, 04 Mar 2012 17:49:12 -0500 Received: from p54ba7a6e.dip.t-dialin.net ([84.186.122.110] helo=neptun.omega.ssw.de); authenticated by wp191.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1S4KEo-0008Mw-HK; Sun, 04 Mar 2012 23:49:10 +0100 Received: from localhost (localhost [127.0.0.1]) by neptun.omega.ssw.de (Postfix) with ESMTP id 74F67E180A8; Sun, 4 Mar 2012 23:49:09 +0100 (CET) X-Virus-Scanned: amavisd-new at omega.ssw.de Received: from neptun.omega.ssw.de ([127.0.0.1]) by localhost (neptun.omega.ssw.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISDPAaPVyoxF; Sun, 4 Mar 2012 23:48:58 +0100 (CET) Received: from [192.168.2.43] (p640.fritz.box [192.168.2.43]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by neptun.omega.ssw.de (Postfix) with ESMTP id 58434E180A7; Sun, 4 Mar 2012 23:48:58 +0100 (CET) Message-ID: <4F53F155.5010104@anvo-it.de> Date: Sun, 04 Mar 2012 23:48:53 +0100 From: Andreas Vogel User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: [PATCH] Making exported variables really global References: <4F536941.8070805@anvo-it.de> <4F536B8A.6060501@gmail.com> <4F537261.3070402@anvo-it.de> <4F5377CA.4020709@gmail.com> <4F539556.4070709@anvo-it.de> <4F53AC9D.7080108@anvo-it.de> <4F53D8B7.5010205@googlemail.com> In-Reply-To: <4F53D8B7.5010205@googlemail.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de; andreas.vogel@anvo-it.de; 1330901352; d82c9ee4; X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.237.132.198 Cc: Andreas Born X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 22:49:16 -0000 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? >> 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." 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. Options 3) just enhances this paradigm and treats global vars as read/write instead of readonly. The comparison with bash is senseless - we are talking about a menu system and not about subshells in general. Andreas