Steven Schubiger <[EMAIL PROTECTED]> wrote: >>From a conversation with Jim: > > On Fri, Aug 24, 2007 at 02:27:34PM +0200, Jim Meyering wrote: >> If you end up adding a program to coreutils, >> it may make more sense to add a tiny bit of code to "head", >> to make it work the way you want, and then to arrange for that code >> to be enabled in a different incarnation of the same .c file. >> For an example of this approach, look at the vdir, ls, dir triple >> of programs. See src/ls-ls.c, ls-vdir.c, ls-dir.c, and ls.c, and >> the trivial rules in Makefile.am. > > Attached is a first (not complete) "approach" open to peer review.
Your range_lines function reads only one buffer's worth of data. 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: ... 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 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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils