2018-04-30 16:49:34 +0100, Geoff Clare:
[...]
> 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.
True, but "cat" spec says it reads stdin, not that it reads
stdin *from the start of the file*. The line-number addresses
for "sed" are expressed in terms of "input lines" not "nth line
of *files*".
[...]
> > 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.
[...]
Thanks. Though it would certainly help to have a clarification
in XCU 1.4 under STDIN, I don't think the problem is that bad.
I'd say the problem is mostly with utilities that explicitely
reference offsets within files/input.
There's also a problem with dd whose "seek" description is wrong
(it says the offset should be relative to the start of the file,
while when there's no of=file, the offset should be relative to
the current position on stdout).
Now it's true that there are a lot of cases where utility
descriptions reference "input files" instead of just "input"
which can be misleading/ambiguous when dealing with stdin.
For instance, in:
{ head -n 1 > /dev/null # skip header
join/comm - file2
} < file1
file1 may not be sorted as the header would likely break the
sorting, but it's not a problem as we removed it. It's OK
because we skip it before feeding to join. What matters is that
the input join sees is sorted even in the input file is not
sorted itself.
Still, I don't think anyone would infer from the current text
that the behaviour is unspecified because the input files are
not sorted.
--
Stephane
