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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
