[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cut no longer works with newline as delimiter

From: Pádraig Brady
Subject: Re: cut no longer works with newline as delimiter
Date: Wed, 07 Aug 2013 01:20:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 08/06/2013 08:32 PM, Bob Proulx wrote:
> Volker Klasen opened a bug in the Debian bug tracker concerning a
> change in behavior in cut.  I have CC'd the bug on this message.  I
> have manually set an appropriate Reply-To header.
> There has been a lot of improvements made to cut.  But the issue is
> this one.  In the older 8.13 this was the behavior:
> $ printf "one\ntwo\n" | cut -d "
>> " -f2
> two
> In the newer 8.21 this is the new behavior:
> $ printf "one\ntwo\n" | cut -d "
>> " -f2
> one
> two
> Was this change intentional or accidental?

Intentional. The change in question, to treat each line independently was:;a=commitdiff;h=51ce0bf8
to address:

Now there are some edge cases where -d $'\n' might be useful
which I documented through tests in:;a=commitdiff;h=d302aed1

Also if the last line doesn't contain \n, then cut will output a \n.
So if lines weren't treated separately as was the case,
then cut would be outputting a trailing "delimiter" not present in the input.

Also the new behavior aligns with other platforms.
Both coreutils >= 8.21 and FreeBSD at least operate as follows:

$ printf '%s\n' a b | cut -d $'\n' -s -f1

> P.S. Of course using cut is a terrible way to select the second line.
> I would use "awk 'NR==2'".  But that is a separate issue.

 sed -n '2{p;q}'
 head -n2 | tail -n1
 tr '\n' '\0' | cut -f2 -d $'\0'


reply via email to

[Prev in Thread] Current Thread [Next in Thread]