bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] linecut addition


From: Jim Meyering
Subject: Re: [RFC] linecut addition
Date: Sat, 15 Sep 2007 09:53:36 +0200

Steven Schubiger <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]