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.