[prev in list] [next in list] [prev in thread] [next in thread]
List: coreutils-bug
Subject: bug#7455: cut - lack of --merge-delimiters option
From: Jim Meyering <jim () meyering ! net>
Date: 2010-11-24 7:16:35
Message-ID: 87y68jcht8.fsf () meyering ! net
[Download RAW message or body]
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}'
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic