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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
