Grub version variable in shell

Grub version variable in shell

[Andreas Born]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

Hi,

it would be great to have a variable like version or grub_version in the 
shell. Sorry, if there is already such an option and I didn't find it. 
But I only saw cpu and platform as well as the feature variables.

This is useful, if you want to use some new feature or don't want to use 
some ugly workaround anymore, which you needed for an older version. 
Currently, I'm doing a check like 'if keymap' to show a minimal menu to 
pre-1.99 users with a warning that they're version is too old instead of 
giving them garbage if at all. But that check does not feel really 
reliable nor clean. ;)
Especially given the recent discussion regarding backwards incompatible 
changes, this would be a really big help even if they're only small 
changes. But I imagine there are other uses too. The early there is such 
a variable the more useful it is, but I wouldn't consider it critical.

On the other hand it's quite hard to parse a version string on the grub 
shell, especially if distributions choose to change it to some Brainf**k 
imitation. Or they give the code a major revamp and then don't change 
it. Well, maybe grub could get a Brainf**k parser at least. :D

For completeness two-line patch attached. (Untested)

Andreas Born

[-- Attachment #2: grub-version.patch --]
[-- Type: text/plain, Size: 402 bytes --]

=== modified file 'grub-core/normal/main.c'
--- grub-core/normal/main.c	2012-03-04 23:41:37 +0000
+++ grub-core/normal/main.c	2012-03-11 02:29:53 +0000
@@ -552,6 +552,8 @@
   grub_env_export ("grub_cpu");
   grub_env_set ("grub_platform", GRUB_PLATFORM);
   grub_env_export ("grub_platform");
+  grub_env_set ("grub_version", VERSION);
+  grub_env_export ("grub_version");
 }
 
 GRUB_MOD_FINI(normal)

Re: Grub version variable in shell

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

On 11.03.2012 03:40, Andreas Born wrote:
> Hi,
>
> it would be great to have a variable like version or grub_version in
> the shell. Sorry, if there is already such an option and I didn't find
> it. But I only saw cpu and platform as well as the feature variables.
>
> This is useful, if you want to use some new feature or don't want to
> use some ugly workaround anymore, which you needed for an older version. 
We don't use grub_version because it would give only very approximate
idea of features supported and so only marginally useful and is likely
to make devs use suboptimal method. Instead we define variables like
feature_foo. Good example is from root setting code:
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt10
--hint-efi=hd0,gpt10 --hint-baremetal=ahci0,gpt10  UUID
else
  search --no-floppy --fs-uuid --set=root UUID
fi

> Currently, I'm doing a check like 'if keymap' to show a minimal menu
> to pre-1.99 users with a warning that they're version is too old
> instead of giving them garbage if at all. But that check does not feel
> really reliable nor clean. ;)
> Especially given the recent discussion regarding backwards
> incompatible changes, this would be a really big help even if they're
> only small changes. But I imagine there are other uses too. The early
> there is such a variable the more useful it is, but I wouldn't
> consider it critical.
>
> On the other hand it's quite hard to parse a version string on the
> grub shell, especially if distributions choose to change it to some
> Brainf**k imitation. Or they give the code a major revamp and then
> don't change it. Well, maybe grub could get a Brainf**k parser at
> least. :D
>
> For completeness two-line patch attached. (Untested)
>
> Andreas Born
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Grub version variable in shell

[Andreas Born]

Am 11.03.2012 03:51, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 11.03.2012 03:40, Andreas Born wrote:
>> Hi,
>>
>> it would be great to have a variable like version or grub_version in
>> the shell. Sorry, if there is already such an option and I didn't find
>> it. But I only saw cpu and platform as well as the feature variables.
>>
>> This is useful, if you want to use some new feature or don't want to
>> use some ugly workaround anymore, which you needed for an older version.
> We don't use grub_version because it would give only very approximate
> idea of features supported and so only marginally useful and is likely
> to make devs use suboptimal method. Instead we define variables like
> feature_foo. Good example is from root setting code:
> if [ x$feature_platform_search_hint = xy ]; then
>    search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt10
> --hint-efi=hd0,gpt10 --hint-baremetal=ahci0,gpt10  UUID
> else
>    search --no-floppy --fs-uuid --set=root UUID
> fi
Thank you, I get your point.
Still I think version can be useful to exclude versions with bugs (or 
features) they do/(don't) have. For example on 1.98 I had to reexport 
all variables in every configfile. This was dirty and hard to maintain 
so I do not want to maintain this anymore. Instead of silently failing, 
I'd like to provide users of older versions with a very simple menu 
combined with a warning. (Usually in normal boot scenarios they're using 
my grub build anyway.) I don't see how this should be possible without 
my 'if keymap' hack. I think neither checking for a command existence 
nor a feature is a reliable method to always ensure a minimum version. 
Of course if you have a better idea, that's even more welcome.
Maybe something like a grub_version_min command? And possibly *_max?

Apart from that I guess it would be nice to have such a variable to 
display the version someplace or to check it. Yes, I know it is already 
displayed in multiple places, but I don't think in gfxmenus.

Did those feature variables even exist in 1.99?
>
>> Currently, I'm doing a check like 'if keymap' to show a minimal menu
>> to pre-1.99 users with a warning that they're version is too old
>> instead of giving them garbage if at all. But that check does not feel
>> really reliable nor clean. ;)
>> Especially given the recent discussion regarding backwards
>> incompatible changes, this would be a really big help even if they're
>> only small changes. But I imagine there are other uses too. The early
>> there is such a variable the more useful it is, but I wouldn't
>> consider it critical.
>>
>> On the other hand it's quite hard to parse a version string on the
>> grub shell, especially if distributions choose to change it to some
>> Brainf**k imitation. Or they give the code a major revamp and then
>> don't change it. Well, maybe grub could get a Brainf**k parser at
>> least. :D
>>
>> For completeness two-line patch attached. (Untested)
>>
>> Andreas Born
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Grub version variable in shell

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2518 bytes --]

On 11.03.2012 12:52, Andreas Born wrote:
> Am 11.03.2012 03:51, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> On 11.03.2012 03:40, Andreas Born wrote:
>>> Hi,
>>>
>>> it would be great to have a variable like version or grub_version in
>>> the shell. Sorry, if there is already such an option and I didn't find
>>> it. But I only saw cpu and platform as well as the feature variables.
>>>
>>> This is useful, if you want to use some new feature or don't want to
>>> use some ugly workaround anymore, which you needed for an older
>>> version.
>> We don't use grub_version because it would give only very approximate
>> idea of features supported and so only marginally useful and is likely
>> to make devs use suboptimal method. Instead we define variables like
>> feature_foo. Good example is from root setting code:
>> if [ x$feature_platform_search_hint = xy ]; then
>>    search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt10
>> --hint-efi=hd0,gpt10 --hint-baremetal=ahci0,gpt10  UUID
>> else
>>    search --no-floppy --fs-uuid --set=root UUID
>> fi
> Thank you, I get your point.
> Still I think version can be useful to exclude versions with bugs (or
> features) they do/(don't) have. For example on 1.98 I had to reexport
> all variables in every configfile. This was dirty and hard to maintain
> so I do not want to maintain this anymore. Instead of silently
> failing, I'd like to provide users of older versions with a very
> simple menu combined with a warning. (Usually in normal boot scenarios
> they're using my grub build anyway.) I don't see how this should be
> possible without my 'if keymap' hack. I think neither checking for a
> command existence nor a feature is a reliable method to always ensure
> a minimum version. Of course if you have a better idea, that's even
> more welcome.
Why not define "feature_bugXYZ_fixed" for bugs?
Which ones are missing in 2.00~beta1?
Then
if [ x$feature_bug_XYZ = xy ]; then
   <normal version>
else
   <bug-workaround version>
fi

>Did those feature variables even exist in 1.99?
They didn't but a missing variable is expanded to empty string so this
check works exactly as intended
> Maybe something like a grub_version_min command? And possibly *_max?
>
I don't see why you need it when you can check for features directly.
Distros often distribute older versions but with backported bugfixes and
check for exact features is better.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Grub version variable in shell

[Andreas Born]

Am 11.03.2012 13:47, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> Why not define "feature_bugXYZ_fixed" for bugs?
> Which ones are missing in 2.00~beta1?
In 1.98 there was that export issue, I already mentioned. When opening a 
new context with configfile e.g. variables were exported to the new 
context, but not marked anymore for reexport. So you had to reexport 
them yourself. No way I'm maintaining a workaround for that.
Then there were some pecularities regarding identifiers I think. Like I 
(always) had to use ${cfgprefix} and not $cfgprefix.
Back then I was also using for some reason function identifiers with 
quotes: function 'initmenu()'

Generally, I remember that versions parser to be very picky.

Some new features, which I use in my menu are:
- localization
- keymap (if keymap is probably fine here)
- gfxpayload
- read (or was that already there and I did not use it, if read could be 
problematic here though)
- terminal_input at_keyboard (if keymap maybe too?)

That relatively long list is why I'm not so happy with only the approach 
of feature_* or feature_bug_*_fixed. I'm wondering how you would decide 
which bugs/features get they're only variable and which ones not? The 
list would get quite long soon, if you're not very restrictive.

 From my point of view most users are using the (recommended) default 
methods to boot our LiveCD, which involves somehow loading the core.img 
usually as linux image. In that case the version of grub is predictable.
The few other users should just get a graceful failure message that 
they're version is too old, if it is. This gives them the chance to 
install a newer version or boot the LiveCD differently.
I don't care if I accidentally hit some backported bugfix, which is not 
common among Slackware anyway, and it would actually work, because all 
those feature checking is hard to maintain and one (me or the 
backporter) could easily miss something. In the latter case users 
wouldn't get a graceful failure anymore and would come back unhappy and 
complaining, while there could have been a simple message that tells 
them what to do and that the problem is their setup. That way we can 
even give them a comparably rudimentary menu to boot the LiveCD. 
Therefor I prefer hitting few users accidentally with a version check 
instead of failing non-gracefully for some. After all a check for the 
version would be easy to remove, while multiple feature checks aren't.

Sometimes it's just easier and thus less error-prone to draw a clear 
line. Especially as workarounds for backwards support can become very 
big or almost whole rewrites. That's when to draw a line in my opinion 
and that's the case with 1.98 at least for us. On the other hand when 
looking at the usage of the feature variables in 2.00 I see that it's a 
much better solution in that case.

> Then
> if [ x$feature_bug_XYZ = xy ]; then
>     <normal version>
> else
>     <bug-workaround version>
> fi
>
>> Did those feature variables even exist in 1.99?
> They didn't but a missing variable is expanded to empty string so this
> check works exactly as intended
>> Maybe something like a grub_version_min command? And possibly *_max?
>>
> I don't see why you need it when you can check for features directly.
> Distros often distribute older versions but with backported bugfixes and
> check for exact features is better.

Re: Grub version variable in shell

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On 11.03.2012 14:55, Andreas Born wrote:
> In 1.98 there was that export issue, I already mentioned. When opening
> a new context with configfile e.g. variables were exported to the new
> context, but not marked anymore for reexport. So you had to reexport
> them yourself. No way I'm maintaining a workaround for that. 
What do you think of possibility
if [ x$feature_bug1_fixed != xy -o x$feature_bug2_fixed != xy ]; then
   echo "Too old"
   <basic menu>
else
<complete version>
fi

We probably need a feature feature_200_release anyway since it will be
starting point for most of backward compatibility (compatibility is
loose with 1.99).
Perhaps feature_20x_release is the way to go.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Grub version variable in shell

[Andreas Born]

Am 11.03.2012 15:07, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 11.03.2012 14:55, Andreas Born wrote:
>> In 1.98 there was that export issue, I already mentioned. When opening
>> a new context with configfile e.g. variables were exported to the new
>> context, but not marked anymore for reexport. So you had to reexport
>> them yourself. No way I'm maintaining a workaround for that.
> What do you think of possibility
> if [ x$feature_bug1_fixed != xy -o x$feature_bug2_fixed != xy ]; then
>     echo "Too old"
>     <basic menu>
> else
> <complete version>
> fi
That's a possibility and how I probably would have used it. But it's 
still hard to decide which bugs get a feature and which not. For 
features it's similar, but probably a bit easier.
>
> We probably need a feature feature_200_release anyway since it will be
> starting point for most of backward compatibility (compatibility is
> loose with 1.99).
> Perhaps feature_20x_release is the way to go.
Yes, that would be fine with me too. I thought about that too, but 
actually I didn't quite see the difference between this and grub_version 
or grub_version_min.
Maybe there could be:
- feature_200_release: or whatever the version is if somebody
really only wants to test/support that one version
- feature_20x_release: or whatever appropriate for a series of
releases where it's possible to be backwards compatible

Thanks for your thoughts.

Andreas

Re: Grub version variable in shell

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]

On 11.03.2012 15:17, Andreas Born wrote:
> Am 11.03.2012 15:07, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> On 11.03.2012 14:55, Andreas Born wrote:
>>> In 1.98 there was that export issue, I already mentioned. When opening
>>> a new context with configfile e.g. variables were exported to the new
>>> context, but not marked anymore for reexport. So you had to reexport
>>> them yourself. No way I'm maintaining a workaround for that.
>> What do you think of possibility
>> if [ x$feature_bug1_fixed != xy -o x$feature_bug2_fixed != xy ]; then
>>     echo "Too old"
>>     <basic menu>
>> else
>> <complete version>
>> fi
> That's a possibility and how I probably would have used it. But it's
> still hard to decide which bugs get a feature and which not. For
> features it's similar, but probably a bit easier.
>>
>> We probably need a feature feature_200_release anyway since it will be
>> starting point for most of backward compatibility (compatibility is
>> loose with 1.99).
>> Perhaps feature_20x_release is the way to go.
> Yes, that would be fine with me too. I thought about that too, but
> actually I didn't quite see the difference between this and
> grub_version or grub_version_min.
> Maybe there could be:
> - feature_200_release: or whatever the version is if somebody
> really only wants to test/support that one version
> - feature_20x_release: or whatever appropriate for a series of
> releases where it's possible to be backwards compatible
>
feature_*_release wouldn't be removed for the next release.
> Thanks for your thoughts.
>
> Andreas
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Grub version variable in shell

[Andreas Vogel]

Am 11.03.2012 15:20, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 11.03.2012 15:17, Andreas Born wrote:
>> Yes, that would be fine with me too. I thought about that too, but
>> actually I didn't quite see the difference between this and
>> grub_version or grub_version_min.
>> Maybe there could be:
>> - feature_200_release: or whatever the version is if somebody
>> really only wants to test/support that one version
>> - feature_20x_release: or whatever appropriate for a series of
>> releases where it's possible to be backwards compatible
>>
> feature_*_release wouldn't be removed for the next release.
The feature_* variables are great. Anyway I support Andreas suggestion
having a GRUB version variable (like many other interpreters/shells are
using it, e.g. BASH, Perl, TCL).
BASH is using 2 variables for it: BASH_VERSION and BASH_VERSINFO. The
second one provides an easy way to get the version, sub-version, etc.
(and eliminates the problems with parsing Andreas was mentioning
before). GRUB could provide something similar, but that's just a thought
which came up right now.

Re: Grub version variable in shell

[Seth Goldberg]

If you're going to have a version string, perhaps more granularity over the major.minor would be good to have, perhaps even using the bzr commit number.  It would make tracking bugs easier from users as well.

  --S

On Mar 11, 2012, at 7:58 AM, Andreas Vogel <Andreas.Vogel@anvo-it.de> wrote:

> Am 11.03.2012 15:20, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> On 11.03.2012 15:17, Andreas Born wrote:
>>> Yes, that would be fine with me too. I thought about that too, but
>>> actually I didn't quite see the difference between this and
>>> grub_version or grub_version_min.
>>> Maybe there could be:
>>> - feature_200_release: or whatever the version is if somebody
>>> really only wants to test/support that one version
>>> - feature_20x_release: or whatever appropriate for a series of
>>> releases where it's possible to be backwards compatible
>>> 
>> feature_*_release wouldn't be removed for the next release.
> The feature_* variables are great. Anyway I support Andreas suggestion
> having a GRUB version variable (like many other interpreters/shells are
> using it, e.g. BASH, Perl, TCL).
> BASH is using 2 variables for it: BASH_VERSION and BASH_VERSINFO. The
> second one provides an easy way to get the version, sub-version, etc.
> (and eliminates the problems with parsing Andreas was mentioning
> before). GRUB could provide something similar, but that's just a thought
> which came up right now.
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Grub version variable in shell

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

On 11.03.2012 12:52, Andreas Born wrote:
>
> Apart from that I guess it would be nice to have such a variable to
> display the version someplace or to check it. Yes, I know it is
> already displayed in multiple places, but I don't think in gfxmenus. 
We can add a template @GRUB_WELCOME_STRING@ for gfxmenu

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Grub version variable in shell

[Andreas Vogel]

Am 11.03.2012 13:52, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 11.03.2012 12:52, Andreas Born wrote:
>> Apart from that I guess it would be nice to have such a variable to
>> display the version someplace or to check it. Yes, I know it is
>> already displayed in multiple places, but I don't think in gfxmenus. 
> We can add a template @GRUB_WELCOME_STRING@ for gfxmenu
Suggesting to use @GRUB_VERSION@ or at least to have it too in order
just to have the version on its own.