Re: Adding a '-D date' option to `cat'

At 8:35 AM -0700 9/5/06, Sam Leffler wrote:
>
>If you want a program that acts as a filter and adds a timestamp
>to each line of input it receives create a new one.  I even have
>a name for this program: stamp.

I knew that if I suggested any new option for any command in the
base system, then some experienced developer who I do respect
would dump on the option for no other reason than the option was
not implemented in 1983.  You will object to that characterization,
but you know that if this had been added to cat in the early 1980's
(along with the dreaded -v), then no one would be demanding that we
remove it now.

I thought long and hard about this before I offered to commit these
changes.  Due to that, I have many thoughts on the topic.  What
follows is only some of them.  It is long, but I could write much
more.  I bought many buckets of paint before writing my previous
message.  I spent a lot of time thinking about it.  Please respect
that effort enough to give the following a fair read.

So, instead of adding 800 bytes to 'cat', we should create a new
command with a new name, and increase the size of the base system
by 9000 bytes?  And this is a good thing?  It seems to me that
pretty much every line of code that is in `cat' will be wanted
in the new command, and then we will add two subroutine calls to
it.  If there is a bug anywhere in `cat', or some new error
situation that we need to handle, then we'll have to remember
to duplicate any new changes in two separate commands?  And that
duplication is a good thing, where 99% of the two commands will
be exactly the same?

It is frustrating that almost every developer who objects to this
idea on grounds of "purity" and "efficiency", will then turn around
and offer some half-assed solution which is either totally wrong
(prefixing each line with the time the command started, instead of
the time that line was read), or has 100 times more overhead than a
well-written option would have.  "Users should write perl scripts",
as if loading in the entire perl interpreter is some paragon of
efficiency.  And what are the chances that all of those hastily-
written scripts are going to be more efficient than a program?  Or
that they are going to have any appropriate error processing?

I understand the concern that adding this will then bring forward a
dozen other nice-sounding options for `cat', and eventually we will
turn `cat' into an all-singing, all-dancing filter command.  Which
is to say, we will basically write a new awk.  I don't want *that*
to happen to `cat', and I do agree that here is a danger there, but
I still think this particular feature is very useful.

I did think about adding an alternate command, but decided I would
get too much flak for such a heresy.  I was thinking of `catfilter'
`filtercat', or `minfilter' so the command could grow into the all-
singing and all-dancing command for filtering.  But then we have to
explain all the filtering options added to cat some 25 years ago,
and which "don't belong" there.  So, my alternate suggestion was to
create a new command called 'mincat' or 'purecat', and have *that*
be nothing but a read-and-write loop, without any of the ugly
filtering options that get people so upset.  Imagine all the
milliseconds of CPU-time that would be saved by running `purecat'!

Any bets that I could get universal approval for adding either of
those commands?  Based on past experience, I doubt it.  Look at how
much flak I got for adding pgrep and pkill, and those were already-
working commands that I *copied* from another BSD, and which also
already existed on several non-BSD unixes.  Those two weren't even
brand new commands.  If I thought I could get a new command into
the base system, then I'd be willing to consider that route.  But I
know (and all of you know) that I'd just get another round of flak.
"Whatever you do, don't add any new features to the base system!!!".

But I don't intend to expend 100 times more effort to create some
port which I know that no one will ever use, because they won't even
know it exists.  There may already be a dozen ports which do this,
but I'm not going to read through 12,500 port descriptions to find
such a trivial tool.  I doubt anyone else does.  It would be less
work to write my own crappy script.  So there is no point in me
spending a lot of effort creating some port when it isn't going to
help anyone.  I want to write code so it is both useful and readily
available.  Not useful and unknown.  I can write code that remains
unknown at work.  I didn't need to join the FreeBSD project to write
code which remains unknown and unused.  If nobody is going to use my
code, then there is no reason for me to waste my time on it.

And given the features *already* in `cat', which even the purists
know they can not remove, this is a small addition and a very useful
feature.  I remain convinced that this is the most-helpful course of
action for our freebsd users, even if it isn't Pure1980sUnix(TM).

-- 
Garance Alistair Drosehn     =               drosehn_at_rpi.edu
Senior Systems Programmer               or   gad_at_FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA