Re: linecut development

[Steven Schubiger]

Brian Dessent <address@hidden> wrote:

> 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.

A good solution (which I left out of consideration).

> 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 concur.

> 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.

This is perfectly fine.

Attached is the current state of the source.

linecut.c
Description: Text Data