All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <dkiper@net-space.pl>
To: Dimitri John Ledkov <dimitri.ledkov@canonical.com>, olaf@aepfle.de
Cc: The development of GNU GRUB <grub-devel@gnu.org>, phcoder@gmail.com
Subject: Re: submenu fails to see variables
Date: Wed, 8 Sep 2021 21:24:51 +0200	[thread overview]
Message-ID: <20210908192451.osdenmzsqubv3vzg@tomti.i.net-space.pl> (raw)
In-Reply-To: <CADWks+Ziy_XEXR3U2hoNx1Uzqf9rRhGBOjU3c4q3kSQHK4bLpw@mail.gmail.com>

On Tue, Sep 07, 2021 at 11:54:13AM +0100, Dimitri John Ledkov wrote:
> On Tue, Sep 7, 2021 at 10:30 AM Olaf Hering <olaf@aepfle.de> wrote:
> >
> > On Mon, Sep 06, Vladimir 'phcoder' Serbinenko wrote:
> >
> > > Le lun. 6 sept. 2021 à 12:49, Olaf Hering <olaf@aepfle.de> a écrit :
> > >     For some reason global variables are not seen in a submenu {} section.
> > >     Does anyone happen to know why this behavior is useful?
> > > You need to export variable to make it visible in submenu
> >
> > Thanks. This was less than obvious. I did not expect a command named 'export' in the context of grub.
> >
> > The documentation needs to be updated to state what the difference between 'set key=val', 'export key=val' and plain 'key=val' actually is.
>
> I have seen somewhere that some distros applied a patch to simply
> export all variables always; or like not to create new contexts for
> submenus, to keep the variable space the same.
>
> Imho keeping variable space global, and exported by default seems to
> lead to least surprises. But it is a behaviour change/break.

I would prefer to keep behavior as is and document it.

Dimitri, Olaf, could one of you do it?

Daniel


      reply	other threads:[~2021-09-08 19:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-06 10:46 submenu fails to see variables Olaf Hering
2021-09-06 13:39 ` Vladimir 'phcoder' Serbinenko
2021-09-07  9:30   ` Olaf Hering
2021-09-07 10:54     ` Dimitri John Ledkov
2021-09-08 19:24       ` Daniel Kiper [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210908192451.osdenmzsqubv3vzg@tomti.i.net-space.pl \
    --to=dkiper@net-space.pl \
    --cc=dimitri.ledkov@canonical.com \
    --cc=grub-devel@gnu.org \
    --cc=olaf@aepfle.de \
    --cc=phcoder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.