[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17145: head fails with implicit stdin on darwin
From: |
Paul Eggert |
Subject: |
bug#17145: head fails with implicit stdin on darwin |
Date: |
Mon, 31 Mar 2014 12:43:48 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 |
On 03/31/2014 05:32 AM, Pádraig Brady wrote:
It seems we might be using non portable code here.
Yes.
In dd we have:
I haven't looked at dd carefully, but I assume it's OK. It's a low-level
program intended for people who want to exercise system calls pretty
much directly. If someone wants to lseek on a device, dd should
probably do just that.
is there a way we can robustly determine if we have a seekable device
or not?
Not as far as I know. In fact, I expect much of the coreutils code uses
the word "seekable" to mean "lseek returns a nonnegative value", which
isn't the same thing that POSIX means. Quite possibly we should clean up
coreutils' terminology here.
head -n -1 /dev/zero I.E. we currently treat such devices as empty,
and return immediately with success status, whereas treating as a
stream of NULs, would result in memory exhaustion while buffering
waiting for a complete line. That is probably the more consistent
operation at least.
Yes, that sounds right.
So the attached uses this more conservative test for the --lines=-N case.
Inoticed other instances of the problem, and in general the whole lseek
business needs a cleanup; the code's too complicated. Attached is a
proposed cleanup+fix patch.
0001-head-port-to-Darwin-and-use-simpler-seeks.patch
Description: Text Data