From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1S6Y4W-0001xb-DA for mharc-grub-devel@gnu.org; Sat, 10 Mar 2012 20:59:44 -0500 Received: from eggs.gnu.org ([208.118.235.92]:44866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6Y4U-0001x6-8e for grub-devel@gnu.org; Sat, 10 Mar 2012 20:59:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6Y4Q-0004Pd-Jj for grub-devel@gnu.org; Sat, 10 Mar 2012 20:59:41 -0500 Received: from wp191.webpack.hosteurope.de ([80.237.132.198]:52929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6Y4Q-0004PM-DU for grub-devel@gnu.org; Sat, 10 Mar 2012 20:59:38 -0500 Received: from p4fc277c1.dip.t-dialin.net ([79.194.119.193] 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 1S6Y4O-0001ok-67; Sun, 11 Mar 2012 02:59:36 +0100 Received: from localhost (localhost [127.0.0.1]) by neptun.omega.ssw.de (Postfix) with ESMTP id 5B315E180A8; Sun, 11 Mar 2012 02:59:35 +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 M0UAjequoZqI; Sun, 11 Mar 2012 02:59:24 +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 20BE2E180A7; Sun, 11 Mar 2012 02:59:24 +0100 (CET) Message-ID: <4F5C06FD.7030209@anvo-it.de> Date: Sun, 11 Mar 2012 02:59:25 +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: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= Subject: Re: [BUG] GRUBs option parsing needs fixing References: <4F541349.7070704@anvo-it.de> <4F541723.6030105@gmail.com> <4F54A094.1000000@anvo-it.de> <4F54B78B.9010707@gmail.com> <4F54DF19.7000804@anvo-it.de> <4F58B03E.2050908@anvo-it.de> <4F58BEE8.3050006@gmail.com> <4F58C2E7.6080000@gmail.com> <4F58CA35.2060506@anvo-it.de> <4F58CDAD.3010300@gmail.com> <4F58D436.7040709@anvo-it.de> <4F5BB06A.504@gmail.com> <4F5BECE8.7060007@anvo-it.de> <4F5BF963.3000307@gmail.com> In-Reply-To: <4F5BF963.3000307@gmail.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; andreas.vogel@anvo-it.de; 1331431178; 759db131; X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.237.132.198 Cc: The development of GNU GRUB 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 01:59:43 -0000 Am 11.03.2012 02:01, schrieb Vladimir '=CF=86-coder/phcoder' Serbinenko: >> It hurts that you think that I don't follow basic rules of communicati= on >> and cooperation. > That's the expression I've got. My position shifted somewhat but yours > remains unchanged. You look stubborn from this angle. Then I'm sorry that I was not able to make it clear what I really wanted. First of all I wanted to get feedback about my ideas and about the possibilities for changes. > Yes. And allowing "-s root" to continue is more important than to allow= > -s with no argument. Don't get your point here. "-s" with no argument is already allowed. This is actually causing the "unexpected behavior" I'm talking about. > Actually another possibility is to keep this or this + 2 other > occurencies to this behaviour while making all future uses to the GNU > standards. I think we are on the same road. I understand now that it's impossible to change the argument parsing for existing options taking optional arguments. I was just missing this clear statement from your side (btw, right now I wonder myself why i didn't ask you this directly). I just didn't expect that you would even think about to agree having 3 options to behave the "old" way while allowing a "new" GRUB conformant way which will be used for new options taking optional arguments. This is a compromise which I think we really should go for. > We can rename ARG_OPTIONAL to ARG_OLD_OPTIONAL, make ARG_OLD_OPTIONAL t= o > behave as to ignore X in --set X as possible argument. I don't understand that. The "old" behavior, e.g. for "search -s|--set", is that if there is no argument "-s" or "--set" needs to be followed by another option or by "--". In other words: any argument which is not an option that follows -s or --set will be taken as the argument for -s or --set. That's the current situation.