Re: linecut development

[Brian Dessent]

Steven Schubiger wrote:

> I'm currently struggling how to make pipe support work correctly, because
> one needs to know beforehand how many lines of input are available (to
> turn relative range line positions into their absolute counterparts),
> which implies reading through the entire STDIN stream. Once this is done,
> I see no way to re-read the same stream again.
> 
> These are the solutions (that come to mind):
> 
>  a) allocate memory for each line and buffer accordingly
>  b) disallow inverted (relative to EOF) line positions
>  c) a sophisticated algorithm
>  d) ...
> 
> I haven't decided yet how to proceed and would like to collect some opinions.

GNU policy is that you can't have limits such as requiring the whole
input to fit in memory, so there's really no choice but to copy stdin to
a temporary file while you count lines.  As an optimization I suppose
you could spool the input into a memory buffer and only switch to
filesystem-backed storage once the size exceeds some threshold.

Not being able to support EOF-relative ranges seems like it would be a
major loss, and isn't the reason for writing this (as opposed to just
using e.g. sed) to be able to have a robust and featureful
implementation?  So if you ask me, there's no way to avoid having to do
this dirtywork.  I think this is part of the more general pattern that
lots of people suggest adding their own pet utilities to coreutils but
very few end up making it in, because the project sets quite a high
standard: no size/space limitations, full texinfo and --help/man
documentation, testcases, implementing features not found in the
existing unix toolset, etc.

Brian