GNU bug report logs - #7455
cut: support whitespace delimiters (like sort,join)

Previous Next

To reply to this bug, email your comments to 7455 AT debbugs.gnu.org.

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

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

From: Leo Lopes <lleeoo <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Re: cut - lack of --merge-delimiters option
Date: Sun, 21 Nov 2010 12:06:35 +1100

Hi Folks,

Sorry to revive a 2-year old thread, but the rest of the thread is easy to find.

Exec summary: a user wanted a merge delimiters options, and the
discussion kind of digressed to "there is a more clever way to do it",
and "why should this be in cut"?

The responses in the thread as to why this feature isn't yet in cut
are reasonable for the issues raised there. However, the most
important (IMHO) use case wasn't considered:

The --merge-delimiters (or -m) feature should be part of cut because
people have come to expect that behavior from a column selector. Every
major application has this option. The fact that cut doesn't have the
feature is not a sign of good design, but rather historical accident.
When people don't find the feature, search for it, then find the
response "how come you don't know how to use awk and don't know this
special feature of ls?" it violates the principle of least surprise
among other things.

Cheers,
Leo.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Leo Lopes <lleeoo <at> gmail.com>
Cc: 7455 <at> debbugs.gnu.org
Subject: Re: bug#7455: cut - lack of --merge-delimiters option
Date: Mon, 22 Nov 2010 01:38:15 +0000

On 21/11/10 01:06, Leo Lopes wrote:
> Hi Folks,
> 
> Sorry to revive a 2-year old thread, but the rest of the thread is easy to find.
> 
> Exec summary: a user wanted a merge delimiters options, and the
> discussion kind of digressed to "there is a more clever way to do it",
> and "why should this be in cut"?
> 
> The responses in the thread as to why this feature isn't yet in cut
> are reasonable for the issues raised there. However, the most
> important (IMHO) use case wasn't considered:
> 
> The --merge-delimiters (or -m) feature should be part of cut because
> people have come to expect that behavior from a column selector. Every
> major application has this option. The fact that cut doesn't have the
> feature is not a sign of good design, but rather historical accident.
> When people don't find the feature, search for it, then find the
> response "how come you don't know how to use awk and don't know this
> special feature of ls?" it violates the principle of least surprise
> among other things.

This pops up every so often:
http://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg00165.html

That thread, considered using:  cut -d '[:blank:]'
but this was deemed sufficient: tr -s '[:blank:]' ' ' | cut -d ' '

I.E. it's marginal. However considering also that it's
awkward currently to parse /proc/partitions for e.g.
because it has leading blanks.
So perhaps if we did support the above, it could
have the extra functionality of ignoring leading blanks?

cheers,
Pádraig.

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

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 7455 <at> debbugs.gnu.org, Leo Lopes <lleeoo <at> gmail.com>
Subject: Re: bug#7455: cut - lack of --merge-delimiters option
Date: Mon, 22 Nov 2010 07:28:34 +0100

Pádraig Brady wrote:
> On 21/11/10 01:06, Leo Lopes wrote:
>> Hi Folks,
>>
>> Sorry to revive a 2-year old thread, but the rest of the thread is easy to find.
>>
>> Exec summary: a user wanted a merge delimiters options, and the
>> discussion kind of digressed to "there is a more clever way to do it",
>> and "why should this be in cut"?
>>
>> The responses in the thread as to why this feature isn't yet in cut
>> are reasonable for the issues raised there. However, the most
>> important (IMHO) use case wasn't considered:
>>
>> The --merge-delimiters (or -m) feature should be part of cut because
>> people have come to expect that behavior from a column selector. Every
>> major application has this option. The fact that cut doesn't have the
>> feature is not a sign of good design, but rather historical accident.
>> When people don't find the feature, search for it, then find the
>> response "how come you don't know how to use awk and don't know this
>> special feature of ls?" it violates the principle of least surprise
>> among other things.
>
> This pops up every so often:
> http://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg00165.html
>
> That thread, considered using:  cut -d '[:blank:]'
> but this was deemed sufficient: tr -s '[:blank:]' ' ' | cut -d ' '
>
> I.E. it's marginal. However considering also that it's
> awkward currently to parse /proc/partitions for e.g.
> because it has leading blanks.
> So perhaps if we did support the above, it could
> have the extra functionality of ignoring leading blanks?

I agree that this is marginal.
However, seeing one example of how easy it is with awk

    awk '{print $3,$4}' /proc/partitions

makes me wonder if it's just a question of documentation
and/or general education.  cut is a very specialized tool.
If it doesn't do the job, using a more general-purpose one
is easy, once you see how.  Do you think that adding a few
examples in "info cut" (including uses of awk) would suffice?

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

From: Leo Lopes <lleeoo <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 7455 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>
Subject: Re: bug#7455: cut - lack of --merge-delimiters option
Date: Tue, 23 Nov 2010 23:57:23 +1100

Thanks for replying.

>
> makes me wonder if it's just a question of documentation
> and/or general education.  cut is a very specialized tool.
> If it doesn't do the job, using a more general-purpose one
> is easy, once you see how.  Do you think that adding a few
> examples in "info cut" (including uses of awk) would suffice?
>

I think adding the awk or tr examples in the manpage/info page would
be helpful. However, I personally don't think it would suffice. I
think it would still violate the principle of least surprise.

Cheers,
Leo.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Leo Lopes <lleeoo <at> gmail.com>
Cc: 7455 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>
Subject: Re: bug#7455: cut - lack of --merge-delimiters option
Date: Tue, 23 Nov 2010 14:37:41 +0000

On 23/11/10 12:57, Leo Lopes wrote:
> Thanks for replying.
> 
>>
>> makes me wonder if it's just a question of documentation
>> and/or general education.  cut is a very specialized tool.
>> If it doesn't do the job, using a more general-purpose one
>> is easy, once you see how.  Do you think that adding a few
>> examples in "info cut" (including uses of awk) would suffice?
>>
> 
> I think adding the awk or tr examples in the manpage/info page would
> be helpful. However, I personally don't think it would suffice. I
> think it would still violate the principle of least surprise.

Well it's still marginal in my mind.

The argument for supporting `cut -d '[:blank:]'` is that
`sort` and `join` for e.g. support this notion of a field by default,
so it's a very common requirement which we might want to
support directly, rather than relying on `awk`.

We should at least document something like this in: info cut invocation

Also consider using `awk` which supports more sophisticated field
processing.  `awk` by default will use (and discard) blank characters
to separate fields.  Leading and trailing blanks on a line are ignored.

Examples:

  print the 2nd field:         awk '{print $2}'
  print the 2nd to last field: awk '{print $NF-1}'

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Leo Lopes <lleeoo <at> gmail.com>
Cc: 7455 <at> debbugs.gnu.org
Subject: Re: bug#7455: cut - lack of --merge-delimiters option
Date: Tue, 23 Nov 2010 15:05:03 +0000

On 23/11/10 14:37, Pádraig Brady wrote:
> On 23/11/10 12:57, Leo Lopes wrote:
>> Thanks for replying.
>>
>>>
>>> makes me wonder if it's just a question of documentation
>>> and/or general education.  cut is a very specialized tool.
>>> If it doesn't do the job, using a more general-purpose one
>>> is easy, once you see how.  Do you think that adding a few
>>> examples in "info cut" (including uses of awk) would suffice?
>>>
>>
>> I think adding the awk or tr examples in the manpage/info page would
>> be helpful. However, I personally don't think it would suffice. I
>> think it would still violate the principle of least surprise.
> 
> Well it's still marginal in my mind.
> 
> The argument for supporting `cut -d '[:blank:]'` is that
> `sort` and `join` for e.g. support this notion of a field by default,
> so it's a very common requirement which we might want to
> support directly, rather than relying on `awk`.
> 
> We should at least document something like this in: info cut invocation
> 
> Also consider using `awk` which supports more sophisticated field
> processing.  `awk` by default will use (and discard) blank characters
> to separate fields.  Leading and trailing blanks on a line are ignored.
> 
> Examples:
> 
>   print the 2nd field:         awk '{print $2}'
>   print the 2nd to last field: awk '{print $NF-1}'

And another common question is about reordering fields

    reorder the 1st two fields:  awk '{print $2,$1}'

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

From: Leo Lopes <lleeoo <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 7455 <at> debbugs.gnu.org
Subject: Re: bug#7455: cut - lack of --merge-delimiters option
Date: Wed, 24 Nov 2010 12:15:56 +1100

I think we are coming back to the same issue, and it is one of culture
and design choice, not of requirements and design needs. So it is
definitely marginal.

In essence, the argument is this: we don't need cut at all. Everything
cut can do, awk can do and other tools can also do. However, if we
will have a tool called cut that cuts columns, it should do at least
the basics that users expect. Among those expectations is merging
delimiters. When those expectations are not met customers are
dissatisfied.

Of course, you guys write and manage the tools, and this is a
management issue if there ever was one. So whatever decision you make
is the one people should be happy to live with. I am just putting my
2c in to the record.

Cheers,
Leo.

2010/11/24 Pádraig Brady <P <at> draigbrady.com>:
> On 23/11/10 14:37, Pádraig Brady wrote:
>> On 23/11/10 12:57, Leo Lopes wrote:
>>> Thanks for replying.
>>>
>>>>
>>>> makes me wonder if it's just a question of documentation
>>>> and/or general education.  cut is a very specialized tool.
>>>> If it doesn't do the job, using a more general-purpose one
>>>> is easy, once you see how.  Do you think that adding a few
>>>> examples in "info cut" (including uses of awk) would suffice?
>>>>
>>>
>>> I think adding the awk or tr examples in the manpage/info page would
>>> be helpful. However, I personally don't think it would suffice. I
>>> think it would still violate the principle of least surprise.
>>
>> Well it's still marginal in my mind.
>>
>> The argument for supporting `cut -d '[:blank:]'` is that
>> `sort` and `join` for e.g. support this notion of a field by default,
>> so it's a very common requirement which we might want to
>> support directly, rather than relying on `awk`.
>>
>> We should at least document something like this in: info cut invocation
>>
>> Also consider using `awk` which supports more sophisticated field
>> processing.  `awk` by default will use (and discard) blank characters
>> to separate fields.  Leading and trailing blanks on a line are ignored.
>>
>> Examples:
>>
>>   print the 2nd field:         awk '{print $2}'
>>   print the 2nd to last field: awk '{print $NF-1}'
>
> And another common question is about reordering fields
>
>    reorder the 1st two fields:  awk '{print $2,$1}'
>
>

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

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 7455 <at> debbugs.gnu.org, Leo Lopes <lleeoo <at> gmail.com>
Subject: Re: bug#7455: cut - lack of --merge-delimiters option
Date: Wed, 24 Nov 2010 08:16:35 +0100

Pádraig Brady wrote:
> On 23/11/10 12:57, Leo Lopes wrote:
>> Thanks for replying.
>>>
>>> makes me wonder if it's just a question of documentation
>>> and/or general education.  cut is a very specialized tool.
>>> If it doesn't do the job, using a more general-purpose one
>>> is easy, once you see how.  Do you think that adding a few
>>> examples in "info cut" (including uses of awk) would suffice?
>>>
>>
>> I think adding the awk or tr examples in the manpage/info page would
>> be helpful. However, I personally don't think it would suffice. I
>> think it would still violate the principle of least surprise.
>
> Well it's still marginal in my mind.
>
> The argument for supporting `cut -d '[:blank:]'` is that
> `sort` and `join` for e.g. support this notion of a field by default,
> so it's a very common requirement which we might want to
> support directly, rather than relying on `awk`.

That is a compelling argument.  For me, it has tipped the balance,
so now I'm slightly in favor of some sort of functional change.

> We should at least document something like this in: info cut invocation
>
> Also consider using `awk` which supports more sophisticated field
> processing.  `awk` by default will use (and discard) blank characters
> to separate fields.  Leading and trailing blanks on a line are ignored.
>
> Examples:
>
>   print the 2nd field:         awk '{print $2}'
>   print the 2nd to last field: awk '{print $NF-1}'

Previous Next

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