Re: [BUG] GRUBs option parsing needs fixing

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

On 08.03.2012 16:45, Andreas Vogel wrote:
>> Don't Reply or Reply-All to start a new thread. It messes up with
>> threading.
> Didn't i write that it was by accident??
No you didn't. You explicitly said that you used Reply-All to start a
new thread.
>  What else can i do other than
> to beg for pardon?
If I have something against you, it's your unwillingness to compromise.
With others it's easy to find compromise but with your approach "all or
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,
> C'mon, I'm talking about the GNU conventions/recommendations regarding
> 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 buggy.
What is buggy and what isn't depends on what is considered correct. The
syntax "-s root" is widely used and is expected by many people. In fact
many people would consider it a bug if we don'r
> 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. 
We're not in Platon's world of ideas. It's irrelevant how it should be.
At the end of the day there are only actions and consequences.

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