Description of problem: In calls like /sbin/busybox sed -n '1,$p' /some/textfile > output.txt busybox cuts the output to multiples of 1024 (including 0). It seems to be independent of the actual sed command given. Version-Release number of selected component (if applicable): busybox-1.6.1-2.fc8 (/sbin/busybox sed) bash-3.2-18.fc8 (calls busybox sed) How reproducible: Every time. Steps to Reproduce: 1. Find a long text file (e.g. /etc/passwd or /etc/abcde.conf) 2. /sbin/busybox sed -n '1,$p' long.txt > output.txt 3. ls -l long.txt output.txt 4. diff -u long.txt output.txt Actual results: output.txt is 0, 1024, 4096, 8192 bytes long, while long.txt is longer. Expected results: For text files, long.txt and output.txt should be equal with '1,$p'. Additional info: Workaround: /sbin/busybox sed -n '1,$p' long.txt | cat > output.txt
Fixed in busybox-1.7.2-2.fc9.
Not for all cases. I have locally built and installed busybox-1.7.2-2.fc9 from Fedora CVS - and ran into problems when trying the next sed expression. Test case being uploaded as attachments.
Created attachment 242501 [details] Test input
Created attachment 242511 [details] Run both GNU sed and busybox sed on in.txt
Created attachment 243411 [details] Add another forgotten output flush Together with your busybox-1.7.2-sed.patch, this at fixes all my current use cases. I'm not saying this is the general solution. I'd need to completely dive into that code for that degree of confidence. I guess upstream should take a look at it.
Thanks, this problem is fixed in busybox-1.7.2-3.fc9 but fflush in your patch was on the wrong place. Please if there is still any problem please reopen this bug. I contacted busybox upstream with this issue so I hope this problem will be fixed in some new upstream version too.