Re: Attempt #3, adding a new command 'sfilter'

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_at_rpi.edu
Senior Systems Programmer               or   gad_at_FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA