Re: cut no longer works with newline as delimiter

[Pádraig Brady]

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.
> 
>   http://bugs.debian.org/718898
> 
> 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:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=51ce0bf8
to address: http://bugs.gnu.org/13498

Now there are some edge cases where -d $'\n' might be useful
which I documented through tests in:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;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
a
b

> 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.

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

thanks,
Pádraig.