From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 21 17:57:36 2013 Received: (at submit) by debbugs.gnu.org; 21 Aug 2013 21:57:36 +0000 Received: from localhost ([127.0.0.1]:45916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VCGPH-0007Zt-Tc for submit@debbugs.gnu.org; Wed, 21 Aug 2013 17:57:36 -0400 Received: from eggs.gnu.org ([208.118.235.92]:58774) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VCGPF-0007Zl-LE for submit@debbugs.gnu.org; Wed, 21 Aug 2013 17:57:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCGP6-0002wv-Og for submit@debbugs.gnu.org; Wed, 21 Aug 2013 17:57:33 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-99.2 required=5.0 tests=BAYES_50,USER_IN_WHITELIST autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:43798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCGP6-0002wr-Mi for submit@debbugs.gnu.org; Wed, 21 Aug 2013 17:57:24 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCGP0-0006AQ-H3 for bug-coreutils@gnu.org; Wed, 21 Aug 2013 17:57:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCGOu-0002vD-HR for bug-coreutils@gnu.org; Wed, 21 Aug 2013 17:57:18 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:55722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCGOt-0002um-Sz for bug-coreutils@gnu.org; Wed, 21 Aug 2013 17:57:12 -0400 Received: from [192.168.4.12] (Athenae [192.168.4.12]) by Ishtar.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id r7LLv4Nd012459 for ; Wed, 21 Aug 2013 14:57:07 -0700 Message-ID: <521537B1.703@tlinx.org> Date: Wed, 21 Aug 2013 14:57:05 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: bug-coreutils@gnu.org Subject: sort complains about incompatible options (that aren't) AND when it shouldn't Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.4 (---) If I tell sort to do a general numeric sort and interpret human suffixes, such as sort -gh ... sort fails similarly, if I ask it to sort by numeric size and respect human suffixes: sort -nh .... sort claims: sort: options `-dn' are incompatible similarly, numeric and general numeric are claimed to be incompatible -- how is that? Regardless of compatibility or not, sort doesn't use even use _1_ of the options that were specified. If it always used the latest option specified as other utils, it would still behave in a deterministic manner, and give correct output in the majority of cases (if not, then state the "question")... I don't know which utils have been dumbed down to fail on, any, ambiguous input (if it is ambiguous, which I argue, it is not -- as there is a prescribed order for evaluation), but the emphasis on computer programs not being resilient. Rigidly making people wrong and refusing to work unless they ask you in the exact right language/syntax is a step backwards for computer programs. The idea on computers is to make life easier -- and enforcing the user to create odd workarounds when the program could have gotten it right, feels like user-abuse. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 21 20:07:57 2013 Received: (at 15158) by debbugs.gnu.org; 22 Aug 2013 00:07:57 +0000 Received: from localhost ([127.0.0.1]:46064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VCIRP-0002Hv-FP for submit@debbugs.gnu.org; Wed, 21 Aug 2013 20:07:56 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:36968) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VCIRL-0002Hg-8g; Wed, 21 Aug 2013 20:07:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 8039E39E810A; Wed, 21 Aug 2013 17:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojNEvYdnlj17; Wed, 21 Aug 2013 17:07:49 -0700 (PDT) Received: from [192.168.1.9] (pool-71-108-49-126.lsanca.fios.verizon.net [71.108.49.126]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 96FE839E8008; Wed, 21 Aug 2013 17:07:49 -0700 (PDT) Message-ID: <52155655.9020001@cs.ucla.edu> Date: Wed, 21 Aug 2013 17:07:49 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Linda Walsh Subject: Re: bug#15158: sort complains about incompatible options (that aren't) AND when it shouldn't References: <521537B1.703@tlinx.org> In-Reply-To: <521537B1.703@tlinx.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: 15158 Cc: 15158@debbugs.gnu.org, 15157@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) The -g and -h options of 'sort' are indeed incompatible; they result in different outputs. More generally, these bug reports reargue the 'grep' bug reported here: http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00017.html and replied to here: http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00018.html Generally speaking, the GNU utilities follow the POSIX utility syntax guidelines, in particular Guideline 11: The order of different options relative to one another should not matter, unless the options are documented as mutually-exclusive and such an option is documented to override any incompatible options preceding it. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02 It sounds like you're disputing the main part of this guideline and are advocating always taking the second (exceptional) part. It's not clear to me that this makes sense, and there are good arguments for sticking with the more-cautious approach. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 21 21:42:46 2013 Received: (at 15158) by debbugs.gnu.org; 22 Aug 2013 01:42:46 +0000 Received: from localhost ([127.0.0.1]:46179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VCJvB-0004fq-OZ for submit@debbugs.gnu.org; Wed, 21 Aug 2013 21:42:46 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:39661) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VCJv7-0004fc-IR; Wed, 21 Aug 2013 21:42:43 -0400 Received: from [192.168.4.12] (Athenae [192.168.4.12]) by Ishtar.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id r7M1gOPr056601; Wed, 21 Aug 2013 18:42:26 -0700 Message-ID: <52156C80.6050507@tlinx.org> Date: Wed, 21 Aug 2013 18:42:24 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: Paul Eggert Subject: Re: bug#15158: sort complains about incompatible options (that aren't) AND when it shouldn't References: <521537B1.703@tlinx.org> <52155655.9020001@cs.ucla.edu> In-Reply-To: <52155655.9020001@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 15158 Cc: 15158@debbugs.gnu.org, 15157@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) Paul Eggert wrote: > The -g and -h options of 'sort' are indeed incompatible; they > result in different outputs. > > More generally, these bug reports reargue the 'grep' bug reported here: > http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00017.html --- Not really. There was nothing about the similarity and overlap of sort options and how integer is still in the class of general numbers, which includes 'e' as an abbreviation for a power prefix, just like KMG are power prefixes as well. You can't claim that 3.2e+3, where e indicates some power of 10 follows, and is used as a scaling factor for 3.2 is that different from 3.2k, where k is a scaling factor, and, indicates that 3.2 is scaled by a factor of 10**3. They are both general numeric cases... I don't think I had anything to say, at all, about the overlap of such in grep, which is inconsistent with itself: grep -d read -d skip --color=auto --color=always foo (no error)... GREP_OPTIONS="-d skip --color=auto -P" grep -E "this|that" grep: conflicting matchers specified ??? I didn't specify them on the command line -- OR now: egrep "this|that" egrep: egrep can only use the egrep pattern syntax But I didn't specify any other syntax... oh.. it reads the cmdline options of 'grep', but it can't function like grep? That sounds a bit ill-designed. ------- Please don't try to take over and confused bugs on other utils, just to put forth your view that utilities should default to broken unless the user invokes them perfectly. That's a bad User Interface design -- computers are supposed to be there to help us -- not to enable those who enjoy making others wrong to do so on a wide scale. > > and replied to here: > > http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00018.html > > Generally speaking, the GNU utilities follow the POSIX utility > syntax guidelines, in particular Guideline 11: > > The order of different options relative to one another > should not matter, unless the options are documented as > mutually-exclusive and such an option is documented to > override any incompatible options preceding it. > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02 > > It sounds like you're disputing the main part of this guideline > and are advocating always taking the second (exceptional) part. --- The 2nd part has been the norm. While you are claiming that the exceptional design should be the norm. Let me know how specifying your options out of order on gnu tar works out... There are many contexts where one option enables or disables others. The idea that options should be order independent is as absurd as the idea that the lines in a "C" program should also be order independent. This is a perfect example of the ivory tower thinking that is dominating POSIX now. While they used to be more practical and describe what was, now they've jump to the forefront to dictate bad design and dumbed-down interfaces. Have you ever thought about the fact that they are funded by Corporations who might have an interest in seeing Linux's open nature be killed off -- and/or it's usage reduced? > It's not clear to me that this makes sense, and there are > good arguments for sticking with the more-cautious approach. ---- So you have said, but name some that would be true for most people and make more sense than the previous, deterministic approach... As it is, I could point to sources by "them" and talk about what "they" said and "everyone knows"... to make my point, but I'll rely on the common sense that most people have in knowing that having programs that are resilient in the face of odd user input and have it do something useful and predictable is far better than having fragile programs that break on all but perfect input. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 21 23:12:23 2013 Received: (at 15158) by debbugs.gnu.org; 22 Aug 2013 03:12:23 +0000 Received: from localhost ([127.0.0.1]:46317 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VCLJu-0006v4-Rr for submit@debbugs.gnu.org; Wed, 21 Aug 2013 23:12:23 -0400 Received: from mail2.vodafone.ie ([213.233.128.44]:23266) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VCLJt-0006ur-2p; Wed, 21 Aug 2013 23:12:22 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBANmAFVJtThDw/2dsb2JhbAANTYcmuV6CfIEzgxgBAQEEIw8BRhALDQEKAgIFFAILAgIJAwIBAgFFBg0BBwEBFapWdIpcgSmPLgeCaIEsA5NKQYomjGuBPA Received: from unknown (HELO [192.168.1.79]) ([109.78.16.240]) by mail2.vodafone.ie with ESMTP; 22 Aug 2013 04:12:19 +0100 Message-ID: <52158192.1040107@draigBrady.com> Date: Thu, 22 Aug 2013 04:12:18 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Linda Walsh Subject: Re: bug#15158: sort complains about incompatible options (that aren't) AND when it shouldn't References: <521537B1.703@tlinx.org> In-Reply-To: <521537B1.703@tlinx.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15158 Cc: 15158@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) tag 15158 notabug close 15158 stop On 08/21/2013 10:57 PM, Linda Walsh wrote: > > If I tell sort to do a general numeric sort and interpret > human suffixes, such as > sort -gh ... > > sort fails similarly, if I ask it to sort by numeric size and > respect human suffixes: > sort -nh .... > > sort claims: > sort: options `-dn' are incompatible > > similarly, numeric and general numeric are claimed to be > incompatible -- how is that? > > Regardless of compatibility or not, sort doesn't > use even use _1_ of the options that were specified. > If it always used the latest option specified as other > utils, it would still behave in a deterministic manner, > and give correct output in the majority of cases (if not, > then state the "question")... > > I don't know which utils have been dumbed down to fail > on, any, ambiguous input (if it is ambiguous, which I > argue, it is not -- as there is a prescribed order for > evaluation), but the emphasis on computer programs > not being resilient. > > Rigidly making people wrong and refusing to work unless > they ask you in the exact right language/syntax > is a step backwards for computer programs. The idea > on computers is to make life easier -- and enforcing > the user to create odd workarounds when the program > could have gotten it right, feels like user-abuse. So for these comparison options, it's not obvious what's going on in the implementation. One might think that if -dn was specified, that something like "dictionary" was used and then "numeric" done to break ties. Similary with -gh, one might think that -h was an adjustment to -g rather than being a _separate_ comparison method entirely. The errors are imparting this info to the user. Given the complexity of the option combinations for sort(1) in particular, it's important to do so. The edge case of a default sort invocation using for example -d, which is then overridden with -n through config, is not usual, and thus should not proceed, for the reason above. Now you have a point about non mutually exclusive args, which I'll respond to in the related bugs you opened. thanks, Pádraig. From unknown Sat Jun 21 10:43:27 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 19 Sep 2013 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator