I'm using cut (GNU coreutils) 8.24.

The command: echo "TEST=test" | cut -d"=" -f2- outputs Ttest. I don't think this is the intended behavior.

Am I using it wrong or is there something wrong with my cut?

  • 1
    With GNU coreutils 8.21 I get the expected behavior (just test). – Paulo Almeida Jul 30 '15 at 23:21
  • impossible...works fine for me on centos 7, freebsd 10, debian 8 and solaris11...impossible – gwillie Jul 30 '15 at 23:29
  • 1
    What happens if you strace the write() calls from the cut process? echo "TEST=test" | strace -e write cut -d"=" -f2- – Digital Trauma Jul 31 '15 at 0:37
  • 1
    Or even just ltrace. – Parthian Shot Jul 31 '15 at 1:01
  • 1
    works correctly with Fedora and upstream coreutils 8.24 here – Pádraig Brady Jul 31 '15 at 9:44

The reproduction issues come down to the provider of libc. Namely, it seems like its a bug in uclibc; see: https://bugs.busybox.net/show_bug.cgi?id=4099

Under certain circumstances, cut prints the first character of field 1 and all of field 2 when told to print field 2 -- so for instance:

printf "4123\t2\t3\t4\t5\n" | cut -f 2

prints out 42; not just 2. I did run strace on that cut, and it did show that cut is printing the whole line.

The bug seems related to how it wants to treat lines without delimiters; so a work around for now is using the '-s' flag; like so:

printf "4123\t2\t3\t4\t5\n" | cut -f 2 -s

which prints '2', as expected.

I imagine most people running into this are using buildroot; and I'd recommend modifying uclibc's configuration as per that link. Mainly this just means:

make uclibc-menuconfig
Select y for 'String and Stdio Support --> Provide a macro version of [getc|putc]'

note that since this is changing the libc implementation; it is probably prudent to also rebuild basically everything.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.