bug#33281: head does not consume input after '-c' is satisfied

2018-12-22 Thread Assaf Gordon
tags 33281 wontfix severity 33281 wishlist close 33281 stop Hello, On 2018-11-06 12:52 p.m., Paul Eggert wrote: On 11/5/18 1:17 PM, Philip Rowlands wrote: To achieve consistency in the other direction, head could ignore the optimization to reduce the number of bytes read, and always read 8192

bug#33281: head does not consume input after '-c' is satisfied

2018-11-06 Thread Paul Eggert
On 11/5/18 1:17 PM, Philip Rowlands wrote: To achieve consistency in the other direction, head could ignore the optimization to reduce the number of bytes read, and always read 8192 bytes, knowing that some would be discarded. Let's not do that. It's less efficient and less useful than what

bug#33281: head does not consume input after '-c' is satisfied

2018-11-05 Thread Bernhard Voelker
On 11/5/18 10:17 PM, Philip Rowlands wrote: > On Mon, 5 Nov 2018, at 20:30, Luiz Angelo Daros de Luca wrote: >> >> Once head read enough bytes to satisfy -c option, it stops reading input >> and quit. >> This is different from what -n does and it is also different from both >> FreeBSD and busybox

bug#33281: head does not consume input after '-c' is satisfied

2018-11-05 Thread Philip Rowlands
On Mon, 5 Nov 2018, at 20:30, Luiz Angelo Daros de Luca wrote: > > Once head read enough bytes to satisfy -c option, it stops reading input > and quit. > This is different from what -n does and it is also different from both > FreeBSD and busybox head implementation. > > With GNU Coreutils head:

bug#33281: head does not consume input after '-c' is satisfied

2018-11-05 Thread Luiz Angelo Daros de Luca
Hello, Once head read enough bytes to satisfy -c option, it stops reading input and quit. This is different from what -n does and it is also different from both FreeBSD and busybox head implementation. With GNU Coreutils head: $ echo -e "123\n456\n789" | { head -n 1; while read a; do echo