From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1S6XAG-0007nk-03 for mharc-grub-devel@gnu.org; Sat, 10 Mar 2012 20:01:36 -0500 Received: from eggs.gnu.org ([208.118.235.92]:42552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6XAC-0007ld-7i for grub-devel@gnu.org; Sat, 10 Mar 2012 20:01:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6XAA-0004CE-0u for grub-devel@gnu.org; Sat, 10 Mar 2012 20:01:31 -0500 Received: from mail-wi0-f171.google.com ([209.85.212.171]:59209) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6XA9-0004C0-L4 for grub-devel@gnu.org; Sat, 10 Mar 2012 20:01:29 -0500 Received: by wibhj13 with SMTP id hj13so1666832wib.12 for ; Sat, 10 Mar 2012 17:01:27 -0800 (PST) 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:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=/0RbDhriDu+KngX4sfGdoSoeYpQoLXh+L1G5f9sL4JU=; b=NFFJVU9Jnm9rT/PY9gqn6aBtaHV8LYofc7oN+mI1UZ5Yezcm9yjob4RnmVKQqR7fTb 28GYNTkxfSchjzB+BOM9wavS2NtGni7LB5P4XUQWESWnzy1Qc0hp8UYUzDfyHKCi01JT SPazKuI2B994qkpXUFm49RvJ9KigbiUC7vc3GH7Ko1hpZ8TaOj6oPP7bAoeOAlln/4uT PC/SBXkfJKUaQuIcYAnWXiulQEj2gVEO5VKQxg0VTBTOXNc1QopMmGR6d5EdUwhr3sXU 1DVkj7lPAoAG2cuwtiPNnYKRekEY2g/b5pT/2NL29fxut2Oeavu6G96y0aOBQy6pnDbJ 33Lw== Received: by 10.180.85.35 with SMTP id e3mr16084674wiz.6.1331427687129; Sat, 10 Mar 2012 17:01:27 -0800 (PST) Received: from fedora.x201.phnet (207-116.62-81.cust.bluewin.ch. [81.62.116.207]) by mx.google.com with ESMTPS id 9sm34285694wid.2.2012.03.10.17.01.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Mar 2012 17:01:26 -0800 (PST) Message-ID: <4F5BF963.3000307@gmail.com> Date: Sun, 11 Mar 2012 02:01:23 +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: Andreas Vogel 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> In-Reply-To: <4F5BECE8.7060007@anvo-it.de> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig500322483EB89FA2609EB605" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.171 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:01:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig500322483EB89FA2609EB605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11.03.2012 01:08, Andreas Vogel wrote: > Am 10.03.2012 20:50, schrieb Vladimir '=CF=86-coder/phcoder' Serbinenko= : >>> What else can i do other than >>> to beg for pardon? >> If I have something against you, it's your unwillingness to compromise= =2E >> With others it's easy to find compromise but with your approach "all o= r >> nothing" it makes the whole thing much more stressful for both of us >> without changing the final outcome. That's about basic rules of >> communication and cooperation, > Sad to hear this, sad that you think about me like this and sad that > you're becoming personal. I just tried to discuss about where I see > problems. Yes, I see why you consider the parsing to be a problem. I believe that we can reach a logical compromise about possible actions. But we have to both have open mind about the solution. Actually you remind me of several people including myself, how I was when I started. > It hurts that you think that I don't follow basic rules of communicatio= n > and cooperation. That's the expression I've got. My position shifted somewhat but yours remains unchanged. You look stubborn from this angle. >>> C'mon, I'm talking about the GNU conventions/recommendations regardin= g >>> argument parsing. I'm not talking about the GNU operating system, I >>> thought I made it clear by even giving the link to that document. >>> Without being able to parse '-xfoo' you will not be able to handle >>> optional arguments in a consistent way. Because of this I disagree: >>> "-xfoo" is necessary. You are right, "search -su UUID" demonstrates >>> perfectly the weakness of the actual argument parsing. It's just bugg= y. >> What is buggy and what isn't depends on what is considered correct. Th= e >> syntax "-s root" is widely used and is expected by many people. In fac= t >> many people would consider it a bug if we don'r > Regarding what i read from you until now, you always insisted on being > compatible with GNUs ideas. And you are perfectly right doing so. I > consider GNUs recommendation regarding argument handling to be correct > and very well designed. But in this case in addition to recommendation there is the reality and reality of backward compatibility with last several years is important. > Imho it would be wise to follow them. > Of course you are right with "-s root", even I was using it that way > until now. The only problem is that the "-s" flag allows the argument t= o > be optional. Without that we wouldn't have any problem. Yes. And allowing "-s root" to continue is more important than to allow -s with no argument. Actually another possibility is to keep this or this + 2 other occurencies to this behaviour while making all future uses to the GNU standards. We can rename ARG_OPTIONAL to ARG_OLD_OPTIONAL, make ARG_OLD_OPTIONAL to behave as to ignore X in --set X as possible argument. >>> If nothing will be changed for short options, at least you need to >>> mention in the manual that "search -s -u UUID" is OK but "search -u -= s >>> UUID" is NOT OK. And you need to mention that "search -su UUID" is OK= >>> but "search -us UUID" is NOT OK. I'm just mentioning the problems. If= >>> you or whoever decide that it's impossible to fix this (e.g. because >>> of backward compatibility), that's another issue. Don't let's mix >>> arguments for how smth should be and what the consequences will be.=20 >> We're not in Platon's world of ideas. It's irrelevant how it should be= =2E >> At the end of the day there are only actions and consequences. > In the text above I'm showing concrete examples why the argument > handling in GRUB is inconsistent and therefore buggy. I cannot remember= > that you even confirmed that it's inconsistent. > I wonder why you don't discuss the example I am giving. Am I right with= > what i wrote? It's a real question and I hoped that i would get some > constructive feedback. I do not see the examples you provided as inconsistent. They might be unexpected but they are consistent. > Maybe we are different in the way we're trying to solve issues: I'm > trying to analyse a problem, see what is wrong and how it should be. > Then I'm thinking about what can be done and what is acceptable and wha= t > are the consequences. Finally it's time for acting. So for me it's > really strange that for you it's irrelevant how it should be. This is just a way of thinking. The result is action followed by consequences and this is what counts. > I just hoped that I could help by identifying and investigating a > problem which I found out when working with GRUB. Yes, it is helpful and I'm grateful for it. But there is a limit as to what can be improved without causing worse nightmare. Old bug is better than two new ones. > I wanted to show the > current situation, the problem with it and what would need to be change= d > in my opinion. I'm really sorry to be told now that I failed and that m= y > discussion is not welcomed. Discussion is welcomed. Just your messages seem to repeat the same things over and over and this isn't productive. Be concise and just write the new elements, not the whole story again every time. > This was not my intention and, believe it or > not, I just wanted to help. > > Andreas > > --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig500322483EB89FA2609EB605 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/ iF4EAREKAAYFAk9b+WMACgkQNak7dOguQgkY+QD/a+elyUMbnfjTwCQ/SoL/KuOC 5nu3oxD8lNRGapggCTcA/jV8cEUAZBUyqH6mfVGsdfX4heJ5QeR2Q5nqcO1Tkw1y =6Y0e -----END PGP SIGNATURE----- --------------enig500322483EB89FA2609EB605--