From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1S6iBH-00060A-Di for mharc-grub-devel@gnu.org; Sun, 11 Mar 2012 08:47:23 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6iBE-000600-AS for grub-devel@gnu.org; Sun, 11 Mar 2012 08:47:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6iBC-0004Lf-Ca for grub-devel@gnu.org; Sun, 11 Mar 2012 08:47:19 -0400 Received: from mail-we0-f169.google.com ([74.125.82.169]:34242) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6iBC-0004LZ-37 for grub-devel@gnu.org; Sun, 11 Mar 2012 08:47:18 -0400 Received: by werj55 with SMTP id j55so3012261wer.0 for ; Sun, 11 Mar 2012 05:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=3fgNu0zsin3A5OuUkAjlb+Pl3UsHn1dbWBLPuxQmv1U=; b=sqOCYtSXb07WUOb68LPt+rbrmYOU6g/QivKSTE7/XXzaDLDn8zjH8XO0j8UWa3rUWh Ab3jlK+hhbiGYM0HZORRPckGAUFv89qhaP5XDbeaZn84Ul49K8mpmIcrF4XASLkwpZUb T8+LP12UxgpPmiayZh8b455kJa/sqsIn2zJ4tWciIdEMBuidu/+Zykqy05faBYz1DL/X sEndLUmMl7M1RqhvdQfL2j663FcT27EqPZUafR4g1apxA6QtLNZQouJd8yRbxLqwQSxp EK0f2LBns0oRPR997Wvr7+trcJ8tCrz+lJBX/A5btueqP9V/zM/QPZV+W1pyGsSkQROs E6GQ== Received: by 10.180.95.34 with SMTP id dh2mr19325712wib.15.1331470035743; Sun, 11 Mar 2012 05:47:15 -0700 (PDT) Received: from fedora.x201.phnet (104-9.203-62.cust.bluewin.ch. [62.203.9.104]) by mx.google.com with ESMTPS id e6sm20844029wix.8.2012.03.11.05.47.13 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 05:47:14 -0700 (PDT) Message-ID: <4F5C9ECF.5010707@gmail.com> Date: Sun, 11 Mar 2012 13:47:11 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: Grub version variable in shell References: <4F5C10A0.1060802@googlemail.com> <4F5C1321.1050403@gmail.com> <4F5C920D.7070808@googlemail.com> In-Reply-To: <4F5C920D.7070808@googlemail.com> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig73301930CD89A67EBFD658F7" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 74.125.82.169 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, 11 Mar 2012 12:47:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig73301930CD89A67EBFD658F7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11.03.2012 12:52, Andreas Born wrote: > Am 11.03.2012 03:51, schrieb Vladimir '=CF=86-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 fin= d >>> 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 =3D xy ]; then >> search --no-floppy --fs-uuid --set=3Droot --hint-bios=3Dhd0,gpt10 >> --hint-efi=3Dhd0,gpt10 --hint-baremetal=3Dahci0,gpt10 UUID >> else >> search --no-floppy --fs-uuid --set=3Droot 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 =3D xy ]; then else 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. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig73301930CD89A67EBFD658F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk9cns8ACgkQNak7dOguQgktTwEAk8oGe4ZqV+F4/osjYyJsCzvF wXIbcHaWdXhui0D9sI4A/32PsGXyGnN6dRm1tUg94CTWwq+1WItIA/9aOoZ8uo6L =r7Yw -----END PGP SIGNATURE----- --------------enig73301930CD89A67EBFD658F7--