GNU logs - #6780, boring messages

Message sent to owner <at> debbugs.gnu.org, bug-coreutils@HIDDEN:

Subject: bug#6780: Problem with the cut command
Resent-From: Bill <bill3@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Mon, 02 Aug 2010 15:56:02 +0000
Resent-Message-ID: <handler.6780.B.128076451923779 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 6780 <at> debbugs.gnu.org
From: Bill <bill3@HIDDEN>
Content-Type: text/plain
Date: Mon, 02 Aug 2010 05:56:31 -0700
Message-Id: <1280753791.2833.135.camel@HIDDEN>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

Hello,

I'm not sure if this is a bug, a question or a feature request,
but there is a problem with the cut command, specifically with
it's delimiter option '-d'. 

In older times disk space was scarce and every byte was 
conserved. Fields in data files were delimited with a single
character such as ':'. This practise continues today. But 
sometimes it does not and fields in some files are separated
with multiple characters. Space is no longer precious.

Suppose I wish to import information about a disk partition
into my backup script. I want to assign the type of filesystem
to a variable. Compare the output of these two commands.

cat /etc/fstab |grep home | cut -d ' ' -f3
yields a blank output line

cat /etc/fstab |grep opt | awk -F " " '{print $3}'
yields the desired output - reiserfs.

The problem is that the cut command can't handle multiple 
instances of the same delimiter. It's designed to handle
a single character like ':', but can't cope with repeating
characters like '::' or a series of spaces as in /etc/fstab.

So my question is shouldn't the cut delimiter handle 
multiple instances of the same character internally or 
failing that, shouldn't there be some way of specifying a 
series of single delimiter characters such as -d':'+  ?

I hope this is useful feedback and look forward to your reply.

	Bill McGrath

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Bill <bill3@HIDDEN>
Subject: bug#6780: Acknowledgement (Problem with the cut command)
Message-ID: <handler.6780.B.128076451923779.ack <at> debbugs.gnu.org>
References: <1280753791.2833.135.camel@HIDDEN>
X-Gnu-PR-Message: ack 6780
X-Gnu-PR-Package: coreutils
Reply-To: 6780 <at> debbugs.gnu.org
Date: Mon, 02 Aug 2010 15:56:02 +0000

Thank you for filing a new bug report with GNU.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-coreutils@HIDDEN

If you wish to submit further information on this problem, please
send it to 6780 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
6780: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D6780
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to owner <at> debbugs.gnu.org, bug-coreutils@HIDDEN:

Subject: bug#6780: Problem with the cut command
Resent-From: Davide Brini <dave_br@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Mon, 02 Aug 2010 19:10:02 +0000
Resent-Message-ID: <handler.6780.B.12807761861571 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: bug-coreutils@HIDDEN
Date: Mon, 2 Aug 2010 19:56:43 +0100
From: Davide Brini <dave_br@HIDDEN>
Message-ID: <20100802195643.57236244@HIDDEN>
In-Reply-To: <1280753791.2833.135.camel@HIDDEN>
References: <1280753791.2833.135.camel@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

On Mon, 02 Aug 2010 05:56:31 -0700 Bill <bill3@HIDDEN> wrote:

> I'm not sure if this is a bug, a question or a feature request,
> but there is a problem with the cut command, specifically with
> it's delimiter option '-d'. 
> 
> In older times disk space was scarce and every byte was 
> conserved. Fields in data files were delimited with a single
> character such as ':'. This practise continues today. But 
> sometimes it does not and fields in some files are separated
> with multiple characters. Space is no longer precious.
> 
> Suppose I wish to import information about a disk partition
> into my backup script. I want to assign the type of filesystem
> to a variable. Compare the output of these two commands.
> 
> cat /etc/fstab |grep home | cut -d ' ' -f3
> yields a blank output line
> 
> cat /etc/fstab |grep opt | awk -F " " '{print $3}'
> yields the desired output - reiserfs.
> 
> The problem is that the cut command can't handle multiple 
> instances of the same delimiter. It's designed to handle
> a single character like ':', but can't cope with repeating
> characters like '::' or a series of spaces as in /etc/fstab.
> 
> So my question is shouldn't the cut delimiter handle 
> multiple instances of the same character internally or 
> failing that, shouldn't there be some way of specifying a 
> series of single delimiter characters such as -d':'+  ?

cut is required by POSIX to treat every separator character as delimiting a
field. 

"Output fields shall be separated by a single occurrence of the field
delimiter character."

However, what you suggest might be implemented as an extension, which the
user would have to enable explicitly (although I wouldn't bet that the
maintainers think this is a good idea, but I may be wrong).

On a side note, you mention awk which in your specific example of space as
separator happens to work fine. However, that is specifically special-cased
in awk; with any other single-character separator, awk works exactly like
cut:

echo 'a::b:c' | awk -F':' '{print "-"$1"--"$2"--"$3"--"$4"-"}'
-a----b--c-

note the empty second field. But of course in awk, unlike cut. you can say
-F ':+' and get the behavior you want.

-- 
D.

Message sent to owner <at> debbugs.gnu.org, bug-coreutils@HIDDEN:

Subject: bug#6780: Problem with the cut command
Resent-From: Bob Proulx <bob@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Mon, 02 Aug 2010 20:31:02 +0000
Resent-Message-ID: <handler.6780.B6780.12807810043752 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Bill <bill3@HIDDEN>
Cc: 6780 <at> debbugs.gnu.org
Date: Mon, 2 Aug 2010 14:30:24 -0600
From: Bob Proulx <bob@HIDDEN>
Message-ID: <20100802203023.GA10969@HIDDEN>
References: <1280753791.2833.135.camel@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1280753791.2833.135.camel@HIDDEN>
User-Agent: Mutt/1.5.18 (2008-05-17)
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

tags 6780 + wishlist
retitle 6780 Add cut multi-character/expression delimiters
thanks

Bill wrote:
> I'm not sure if this is a bug, a question or a feature request,
> but there is a problem with the cut command, specifically with
> it's delimiter option '-d'. 
> 
> In older times disk space was scarce and every byte was 
> conserved. Fields in data files were delimited with a single
> character such as ':'. This practise continues today. But 
> sometimes it does not and fields in some files are separated
> with multiple characters. Space is no longer precious.

Sure.  But I think none of that is relevant to changing stable program
interfaces and behavior.  That is a good point for creating a new
program that has no legacy however.  The world is wide open for adding
new programs.  Feel free to go for it there.

> Suppose I wish to import information about a disk partition
> into my backup script. I want to assign the type of filesystem
> to a variable. Compare the output of these two commands.
> 
> cat /etc/fstab |grep home | cut -d ' ' -f3
> yields a blank output line

It is data dependent.  The output depends upon what you have as input.
For some files it would be one way and for others a different way.
But that just points out that using cut is the wrong tool for the
task.  As you are well aware of by your note cut works with single
character delimiters.  But the fstab may have multiple whitespace.
This makes cut an inappropriate tool for the job.

> cat /etc/fstab |grep opt | awk -F " " '{print $3}'
> yields the desired output - reiserfs.

Awk is a much better tool for the task.  But the inefficiencies
present in that command line are many.  There are much better ways.
Try this instead.

  awk '/opt/{print$3}' /etc/fstab

However that doesn't account for comments that may also match.  To
avoid problems comments should be removed first.

  awk '/#/{gsub("#.*","")}/opt/{print$3}' /etc/fstab

And I am inclined to say that it is better to just match on a
particular field.

  awk '/#/{gsub("#.*","")}$2=="/opt"{print$3}' /etc/fstab

> The problem is that the cut command can't handle multiple 
> instances of the same delimiter. It's designed to handle
> a single character like ':', but can't cope with repeating
> characters like '::' or a series of spaces as in /etc/fstab.

All correct.  The cut command is not the appropriate tool for your
task.

> So my question is shouldn't the cut delimiter handle 
> multiple instances of the same character internally or 
> failing that, shouldn't there be some way of specifying a 
> series of single delimiter characters such as -d':'+  ?

In my opinion no, it should not.  It is feature creep and code bloat.
Cut is not just used on large servers and large desktops but also on
wristwatches and toaster ovens.  Should the increase in size be
multipled by every system in the known universe?  And even if this
feature were added to cut the program would still be insufficient to
the task since it has no capability to handle comments nor line
selection (although your combination with grep is fine with me, good
in fact though sed would be better since it enables checking return
status).  Furthermore the feature is already implemented and fully
supported by awk.  Using awk is a much better fit than using cut.  The
solution already exists in awk and therefore is not needed in cut.
The awk program is standardized and portable.  To me awk is the best
in class tool for this task.

Bob

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 2 Aug 2010 20:30:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 02 16:30:04 2010
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Og1e7-0000yU-HY
	for submit <at> debbugs.gnu.org; Mon, 02 Aug 2010 16:30:03 -0400
Received: from joseki.proulx.com ([216.17.153.58])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <bob@HIDDEN>)
	id 1Og1e4-0000y0-RL; Mon, 02 Aug 2010 16:30:01 -0400
Received: from dementia.proulx.com (dementia.proulx.com [192.168.230.115])
	by joseki.proulx.com (Postfix) with ESMTP id 160422130E;
	Mon,  2 Aug 2010 14:30:24 -0600 (MDT)
Received: by dementia.proulx.com (Postfix, from userid 1000)
	id 0B30A3CC39A; Mon,  2 Aug 2010 14:30:24 -0600 (MDT)
Date: Mon, 2 Aug 2010 14:30:24 -0600
From: Bob Proulx <bob@HIDDEN>
To: Bill <bill3@HIDDEN>
Subject: Re: bug#6780: Problem with the cut command
Message-ID: <20100802203023.GA10969@HIDDEN>
References: <1280753791.2833.135.camel@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1280753791.2833.135.camel@HIDDEN>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: control
Cc: 6780 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.4 (--)

tags 6780 + wishlist
retitle 6780 Add cut multi-character/expression delimiters
thanks

Bill wrote:
> I'm not sure if this is a bug, a question or a feature request,
> but there is a problem with the cut command, specifically with
> it's delimiter option '-d'. 
> 
> In older times disk space was scarce and every byte was 
> conserved. Fields in data files were delimited with a single
> character such as ':'. This practise continues today. But 
> sometimes it does not and fields in some files are separated
> with multiple characters. Space is no longer precious.

Sure.  But I think none of that is relevant to changing stable program
interfaces and behavior.  That is a good point for creating a new
program that has no legacy however.  The world is wide open for adding
new programs.  Feel free to go for it there.

> Suppose I wish to import information about a disk partition
> into my backup script. I want to assign the type of filesystem
> to a variable. Compare the output of these two commands.
> 
> cat /etc/fstab |grep home | cut -d ' ' -f3
> yields a blank output line

It is data dependent.  The output depends upon what you have as input.
For some files it would be one way and for others a different way.
But that just points out that using cut is the wrong tool for the
task.  As you are well aware of by your note cut works with single
character delimiters.  But the fstab may have multiple whitespace.
This makes cut an inappropriate tool for the job.

> cat /etc/fstab |grep opt | awk -F " " '{print $3}'
> yields the desired output - reiserfs.

Awk is a much better tool for the task.  But the inefficiencies
present in that command line are many.  There are much better ways.
Try this instead.

  awk '/opt/{print$3}' /etc/fstab

However that doesn't account for comments that may also match.  To
avoid problems comments should be removed first.

  awk '/#/{gsub("#.*","")}/opt/{print$3}' /etc/fstab

And I am inclined to say that it is better to just match on a
particular field.

  awk '/#/{gsub("#.*","")}$2=="/opt"{print$3}' /etc/fstab

> The problem is that the cut command can't handle multiple 
> instances of the same delimiter. It's designed to handle
> a single character like ':', but can't cope with repeating
> characters like '::' or a series of spaces as in /etc/fstab.

All correct.  The cut command is not the appropriate tool for your
task.

> So my question is shouldn't the cut delimiter handle 
> multiple instances of the same character internally or 
> failing that, shouldn't there be some way of specifying a 
> series of single delimiter characters such as -d':'+  ?

In my opinion no, it should not.  It is feature creep and code bloat.
Cut is not just used on large servers and large desktops but also on
wristwatches and toaster ovens.  Should the increase in size be
multipled by every system in the known universe?  And even if this
feature were added to cut the program would still be insufficient to
the task since it has no capability to handle comments nor line
selection (although your combination with grep is fine with me, good
in fact though sed would be better since it enables checking return
status).  Furthermore the feature is already implemented and fully
supported by awk.  Using awk is a much better fit than using cut.  The
solution already exists in awk and therefore is not needed in cut.
The awk program is standardized and portable.  To me awk is the best
in class tool for this task.

Bob

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 2 Aug 2010 20:41:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 02 16:41:57 2010
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Og1pd-00016O-G4
	for submit <at> debbugs.gnu.org; Mon, 02 Aug 2010 16:41:57 -0400
Received: from joseki.proulx.com ([216.17.153.58])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <bob@HIDDEN>) id 1Og1pc-00016I-DM
	for control <at> debbugs.gnu.org; Mon, 02 Aug 2010 16:41:57 -0400
Received: from dementia.proulx.com (dementia.proulx.com [192.168.230.115])
	by joseki.proulx.com (Postfix) with ESMTP id 40FA42130E
	for <control <at> debbugs.gnu.org>; Mon,  2 Aug 2010 14:42:20 -0600 (MDT)
Received: by dementia.proulx.com (Postfix, from userid 1000)
	id 38FD03CC39A; Mon,  2 Aug 2010 14:42:20 -0600 (MDT)
Date: Mon, 2 Aug 2010 14:42:20 -0600
From: Bob Proulx <bob@HIDDEN>
To: control <at> debbugs.gnu.org
Subject: severity to wishlist
Message-ID: <20100802204220.GA14867@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Spam-Score: -2.4 (--)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.4 (--)

severity 6780 wishlist
thanks

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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