GNU bug report logs - #8070
cut command

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8070 in the body.
You can then email your comments to 8070 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: George Gallen <ggallen <at> wyanokegroup.com>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: cut command
Date: Thu, 17 Feb 2011 16:19:53 -0600

[Message part 1 (text/plain, inline)]

I'm not sure whether this is a bug or not.

On Redhat Enterprise Linux, the cut command will accept the following " cut -c0-5 " (Cut ver 5.97)
On Fedora it will not accept the 0, it must be " cut -c1-5 " (cut ver 8.5)

Although both are functionally the same, they seem to only return 5 characters
The script it was written in worked without problems from Redhat 7.2 to present RHEL
I only noticed the problem with fedora 13 and 14.

I was able to copy the cut command from RHEL to Fedora 14 and it works fine. What am losing
  between these two versions?

Was there a divergence somewhere along the way where cut stopped tolerating the
   the 0 base index?

Thanks


George Gallen
Senior Programmer/Analyst
Accounting/Data Division, EDI Administrator
ggallen <at> wyanokegroup.com
ph:856.848.9005 Ext 220
The Wyanoke Group
http://www.wyanokegroup.com

[Message part 2 (text/html, inline)]

Message #10 received at 8070-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: George Gallen <ggallen <at> wyanokegroup.com>
Cc: 8070-done <at> debbugs.gnu.org
Subject: Re: bug#8070: cut command
Date: Thu, 17 Feb 2011 23:44:52 +0100

George Gallen wrote:
> I'm not sure whether this is a bug or not.
>
> On Redhat Enterprise Linux, the cut command will accept the following " cut -c0-5 " (Cut ver 5.97)
> On Fedora it will not accept the 0, it must be " cut -c1-5 " (cut ver 8.5)
>
> Although both are functionally the same, they seem to only return 5 characters
> The script it was written in worked without problems from Redhat 7.2 to present RHEL
> I only noticed the problem with fedora 13 and 14.
>
> I was able to copy the cut command from RHEL to Fedora 14 and it works fine. What am losing
>   between these two versions?
>
> Was there a divergence somewhere along the way where cut stopped tolerating the
>    the 0 base index?

Right.  That change was due to a bug fix.
Here's part of coreutils' NEWS file:

* Noteworthy changes in release 6.9.91 (2007-12-15) [beta]

  cut now diagnoses a range starting with zero (e.g., -f 0-2) as invalid;
  before, it would treat it as if it started with 1 (-f 1-2).

  "cut -f 2-0" now fails; before, it was equivalent to "cut -f 2-"

Message #13 received at 8070 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: George Gallen <ggallen <at> wyanokegroup.com>
Cc: 8070 <at> debbugs.gnu.org
Subject: Re: bug#8070: cut command
Date: Thu, 17 Feb 2011 15:46:07 -0700

[Message part 1 (text/plain, inline)]

On 02/17/2011 03:19 PM, George Gallen wrote:
> I'm not sure whether this is a bug or not.
> 
> On Redhat Enterprise Linux, the cut command will accept the following " cut -c0-5 " (Cut ver 5.97)
> On Fedora it will not accept the 0, it must be " cut -c1-5 " (cut ver 8.5)

Thanks for the report.

POSIX states this:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html

"The application shall ensure that the option-argument list (see options
-b, -c, and -f below) is a <comma>-separated list or <blank>-separated
list of positive numbers and ranges. Ranges can be in three forms. The
first is two positive numbers separated by a <hyphen> ( low- high),
which represents all fields from the first number to the second number.
The second is a positive number preceded by a <hyphen> (- high), which
represents all fields from field number 1 to that number. The third is a
positive number followed by a <hyphen> ( low-), which represents that
number to the last field, inclusive."

0 is not a positive integer, it lends itself to confusion (is the first
character 0-based or 1-based?), and coreutils had not documented it as
an explicit extension, therefore this functionality was removed as a bug
fix in 6.9.90:

http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=a6a447fc

And NEWS backs this up:

  cut now diagnoses a range starting with zero (e.g., -f 0-2) as invalid;
  before, it would treat it as if it started with 1 (-f 1-2).

> I was able to copy the cut command from RHEL to Fedora 14 and it works fine. What am losing
>   between these two versions?

Your script was not POSIX compliant to begin with - it was pure luck
that it worked for you in older installations.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.