On 11/16/2012 11:23 PM, Jim Meyering wrote: > Bernhard Voelker wrote: > >> Hi Marcel, >> >> On 11/16/2012 07:35 AM, Marcel Böhme wrote: >>> Hi, >>> The command "echo 12345 | cut -b 0-" prints an empty line while it >>> should fail with "fields and positions are numbered from 1" according >>> to this specification "cut: diagnose a range starting with 0 (-f 0-2) >>> as invalid". >>> Can you confirm this is an incomplete bugfix made on 2007-05-22? >> >> I'd say yes. >> Here's a proposed fix. > ...
> Thank you! > That change looks fine, at first glance, > but please amend the log to mention the bug number URL. > Also, technically this is a bug, so please mention the > fix in NEWS. Thanks for the review. I amended with updated NEWS and also improved the test to include both the field option -f and the position options -b and -c, plus mentioned the bug URL in the commit message. Have a nice day, Berny >From 10fc244ac8e4f24eb330eae110fadc0b7d78cf8d Mon Sep 17 00:00:00 2001 From: Bernhard Voelker <m...@bernhard-voelker.de> Date: Sun, 18 Nov 2012 22:20:16 +0100 Subject: [PATCH] cut: do not accept the invalid range 0- MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The command "echo 12345 | cut -b 0-" prints an empty line while it should fail with "fields and positions are numbered from 1". * src/cut.c (set_fields): Add a diagnostic for the invalid open range which starts with Zero, i.e., the range 0-. * tests/misc/cut.pl: Add tests to ensure the range 0- fails for fields (-f) and for positions (-b, -c). * NEWS: Mention the fix. Reported by Marcel Böhme in <http://bugs.gnu.org/12903>. --- NEWS | 4 ++++ src/cut.c | 3 +++ tests/misc/cut.pl | 5 +++++ 3 files changed, 12 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index db6a207..e4a284c 100644 --- a/NEWS +++ b/NEWS @@ -10,6 +10,10 @@ GNU coreutils NEWS -*- outline -*- ** Bug fixes + cut no longer accepts the invalid range 0-, which made it print empty lines. + Instead, cut now fails and emits an appropriate diagnostic. + [This bug was present in "the beginning".] + pr -n no longer crashes when passed values >= 32. Also line numbers are consistently padded with spaces, rather than with zeros for certain widths. [bug introduced in TEXTUTILS-1_22i] diff --git a/src/cut.c b/src/cut.c index 87380ac..2a57148 100644 --- a/src/cut.c +++ b/src/cut.c @@ -369,6 +369,9 @@ set_fields (const char *fieldstr) dash_found = true; fieldstr++; + if (lhs_specified && !value) + FATAL_ERROR (_("fields and positions are numbered from 1")); + initial = (lhs_specified ? value : 1); value = 0; } diff --git a/tests/misc/cut.pl b/tests/misc/cut.pl index 0ce051a..cd56555 100755 --- a/tests/misc/cut.pl +++ b/tests/misc/cut.pl @@ -46,6 +46,11 @@ my @Tests = # It was treated just like "-2". ['zero-2', '-f0-2', {ERR=>$from_1}, {EXIT => 1} ], + # Up to coreutils-8.20, specifying a range of 0- was not an error. + ['zero-3b', '-b0-', {ERR=>$from_1}, {EXIT => 1} ], + ['zero-3c', '-c0-', {ERR=>$from_1}, {EXIT => 1} ], + ['zero-3f', '-f0-', {ERR=>$from_1}, {EXIT => 1} ], + ['1', '-d:', '-f1,3-', {IN=>"a:b:c\n"}, {OUT=>"a:c\n"}], ['2', '-d:', '-f1,3-', {IN=>"a:b:c\n"}, {OUT=>"a:c\n"}], ['3', qw(-d: -f2-), {IN=>"a:b:c\n"}, {OUT=>"b:c\n"}], -- 1.7.7
