Date: Thu, 7 Sep 2006 15:21:49 -0400 From: Garance A Drosehn <gad@FreeBSD.org> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: freebsd-current@FreeBSD.org Subject: Re: Attempt #3, adding a new command 'sfilter' Message-ID: <p0623094cc125f6ef94cd@[128.113.24.47]> In-Reply-To: <44FFF466.2090700@infracaninophile.co.uk> References: <200608281545.k7SFjn6l063922@lurza.secnetix.de> <p06230928c11e2298ca97@[128.113.24.47]> <200609020956.54008.Lucas.James@ldjcs.com.au> <20060902031247.GE749@turion.vk2pj.dyndns.org> <20060904192006.GA3292@turion.vk2pj.dyndns.org> <p06230937c122c6983e00@[128.113.24.47]> <44FD994C.70104@errno.com> <44FDEE7C.9060104@FreeBSD.org> <44FDF245.9000302@elischer.org> <44FDF36A.3010608@FreeBSD.org> <p06230942c124de77d7de@[128.113.24.47]> <p06230943c124ed56543e@[128.113.24.47]> <44FFF466.2090700@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:28 AM +0100 9/7/06, Matthew Seaman wrote:
>Garance A Drosehn wrote:
>
>> Actually, I have another useful option in mind that could be added
>> with very little effort. So let me say that I do intend to install
>> this as a new /usr/bin/sfilter command, assuming that does not
>> generate too many objections. I expect this will work out better
>> than adding new options to `date' or to `cat'.
>
>Do you intend sfilter to subsume the functionality of nl(1)?
>Seems like a natural match...
One thing that I need to do, if I do this, is to write up a clear
set of guidelines to describe what filters would fit the spirit and
intent of this simple-filter command. In this case, I would say
that `nl' would not fit my idea for `sfilter', because it:
applies a configurable line numbering filter operation
and when I look at the man page, it provides quite a few options to
do that configuration. I do not expect `sfilter' to implement highly
configurable options. While I admit that the -D option includes a
lot of flexibility, all of that is already implemented and well-tested
in the strftime() subroutine. The flexibility in -D is not being
implemented by new code in `sfilter'.
The `nl' command also:
treats the text it reads in terms of logical pages.
which is not how `sfilter' is going to operate.
Apologies if this comes across like a lecture. Questions like this
one are good questions, and in my own mind I am trying to figure out
exactly what is and is not appropriate for a new command. So I am
trying to come up with some strict set of rules for it, and make
sure that what I "want" to do does not conflict with those rules.
And that is a challenge, as one goals is that the final executable
should not be much larger than the original `cat' command. 50% larger
would be fine. 100% larger would be a maybe. 200% larger, and IMO
the command is going haywire. Despite my earlier comments about an
"all-singing, all dancing" filter command, I really don't want this
to turn into the "kitcken-sink filter command". I want it to provide
a few simple filters, all of which can be implemented within a single
read/write loop in a single program. I may find out that I need to
scale my ideas back to a `dfilter' command with just the date/time
options, and then dream up some other command for other kinds of
simple filters.
--
Garance Alistair Drosehn = drosehn@rpi.edu
Senior Systems Programmer or gad@FreeBSD.org
Rensselaer Polytechnic Institute; Troy, NY; USA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0623094cc125f6ef94cd>