Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 30 Apr 2018:
>
> 2018-04-30 15:50:10 +0100, Geoff Clare:
> > Stephane Chazelas 
> > <stephane.chazelas-re5jqeeqqe8avxtiumw...@public.gmane.org> wrote, on 30 
> > Apr 2018:
> > > 
> > > The head/tail specifications refer to line/byte offsets as
> > > offsets within *files* as opposed to *input*.
> > > 
> > > Does it mean that:
> > > 
> > > { head -n 1; head -n 1; } < file
> > > { tail -n 1; tail -n 1; } < file
> > > 
> > > are required to print the first/last line of "file" twice
> > > (assuming "file" is seekable and is not modified between the two
> > > head/tail invocations)?
> > > 
> > > In the case of "head", I can't find any implementation that
> > > does, they all return the first line of their *input* as opposed
> > > to the first line of whatever file may be open on stdin.
> > 
> > The intended behaviour of the head example is that the first head
> > writes the first line of "file" and the second head writes the second
> > line of "file".  See XCU 1.4 under INPUT FILES.
> 
> Thanks, but that text covers where the utility shall *leave*
> stdin's position *after* it has processed its input, but not
> whether it may change  it before reading the input.

Yes, but it clearly shows that this offset is intended to be honoured
by the next utility to read from stdin, when it says:

    tail -n +2 file
    (sed -n 1q; cat) < file
    [...]
    The second command is equivalent to the first only when the file is
    seekable.

> [...]
> > > However, in the case of "tail", for seekable stdin, traditional
> > > implementations used to seek to the end of the file open on
> > > stdin and look backward for the last line from there even if the
> > > initial position of stdin was past the start of that last line
> > > (it could even be past the end of the file).
> > 
> > The intention is certainly that when reading from standard input,
> > tail should not write anything that is before the initial offset of
> > standard input.
> [...]
> 
> Thanks.
> 
> But would you agree that it's not what the text currently says?
> Should we create a ticket for that?

Yes, it needs a ticket.  It may well affect a lot of utilities, so
perhaps adding something in XCU 1.4 under STDIN would be the best
solution.

-- 
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Reply via email to