bug#7455: cut - lack of --merge-delimiters option

[Jim Meyering]

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?