Jim Meyering <[EMAIL PROTECTED]> wrote: > Your range_lines function reads only one buffer's worth of data.
Uhm, yes. I noticed it later on. > While I did mention head, above, a subsequent message pointed > to tail as a better source of relevant code: > > >> However, another possibility is to extract the relevant parts of > >> tail into a library and to use them from both programs. > >> But it's too early to worry about this. > > Before coding further, I strongly urge you to nail down the > specification -- publicly. Put it this way: write enough > details that someone reading your description in a man page > would not be disappointed. > > I recommend giving a small, precise example to illustrate each use case. > E.g., seq 100 | linecut --number --range ... would print this: > ... Follows shortly. > Another reason to specify up front: I think you wanted to be able to > specify a negative number, -N, as a range endpoint, representing the Nth > line from the end of the file. The implementation required to support > that is very different from what's required for the other types of ranges. > See tail's elide_* functions. I see. > I don't want to dissuade you from writing the tool, but rather to > encourage you to use another language: please consider writing it > first in Perl, Python, or Ruby. Even if that first cut isn't > terribly efficient, it will give you an easy way to experiment > with features and algorithms without being distracted by the, um, ... > features of C. Who knows... once you've written it in a scripting > language, you may not think it's worth rewriting in C. The feature-set is quite frozen for now and I already have a working implementation in C (albeit a bit "slow" due to massive memory allocation). _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
