On Thu, Jun 7, 2012 at 11:15 PM, Eric Blake <ebl...@redhat.com> wrote: > [please don't top-post on technical lists] > > On 06/07/2012 08:37 AM, Anoop Sharma wrote: >> The thought behind the proposed change was that lseek should reflect >> the amount of data that head has actually been able to print. > > But that's not generically possible to know. > >> >> For example, how do we want head to behave in a situation like the >> following where files more than a particular size are not allowed >> (with bash shell on a machine with block size of 1024 bytes)? This >> situation can be handled by applying this patch. I agree this example >> is custom designed to illustrate my point but what do we gain by not >> making the check?: >> >> ulimit -f 1; trap '' SIGXFSZ >> (stdbuf -o0 head -n -1025 >someOutFile; cat) <someIpFile >> >> What should cat print now? > > Bogus question. That's a bug in your shell scripting - if you are > worried about partial processing errors, then you must check all > intermediate steps: > > ulimit -f 1; trap '' SIGXFSZ > (stdbuf -o0 head -n -1025 >someOutFile && cat) <someIpFile > > That is, you should have used && rather than ;, so that cat prints > nothing on error. > > -- > Eric Blake ebl...@redhat.com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >
Thank you. I understand your perspective now.
