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

From: Garance A Drosehn <gad_at_FreeBSD.org>
Date: Tue, 5 Sep 2006 18:32:43 -0400
At 3:00 PM -0700 9/5/06, Doug Barton wrote:
>Julian Elischer wrote:
>
>>  then there will be a bikeshed about adding a new tool
>
>... which can safely be ignored, even if it occurs, because creating new
>and potentially useful tools always creates less drama then mucking about
>with old (or really old) ones. I haven't heard anyone say, "No such
>functionality should exist in FreeBSD," but I have heard several people
>say "Don't bastardize the Unix model." I even like Sam's proposed name.

I think his suggestion is the wrong solution.  Is it *really* more
efficient to have ten commands, each of which will duplicate 99% of
the code in cat?  And then users are supposed to string all of those
commands together, as is often talked about as a "virtue", such as:

   somecommand | number | stamp | disptab | dispnonprint

Is that *really* more efficient?  Four commands, taking up 36K of
disk space, instead of one command in 9K?  Four processes doing the
exact same read/write loop, where 99% of the processing is in that
reading and writing?  And, oops, I put those in the wrong order,
because I wanted 'stamp' to put a tab between the timestamp and
the real data, and disptab is going to modify the tab that I do
not want it to modify.  Four commands that users have to know about,
four man pages to read.

I'd be willing to add one command that knew how to apply multiple
simple filters, and in fact I think that would be a better solution.
But I am certain that I'll get into another fight if I suggest that,
so instead I'm suggesting the option which I think is the least
disruption to the base system.  700 bytes, instead of a whole new
command.

>  > Date could have had this feature added in 20 lines of C.
>>  you'd rather create a whole new beaurocracy.
>
>What would be really useful here is if the people who want this could
>focus on the end result (having the tool you need to do the job) rather
>than the methodology of achieving that result. The door is open, walk
>through it.

That sounds so nice.

I did that with pgrep and pkill, and at the time I got all kinds of
flak for it.  Most of it private.  Sure, people use those commands
now that they are there, but at the time I was told "you can get the
same effect by piping `ps` through `grep`", and that I just didn't
understand the One True Unix Way, which apparently is to never add
anything to the base system.  You may think I'm kidding, but when I
did the commits for those to commands I did it with the thought "Well,
this may lose me my commit bit, but I'm irritated enough that I'm
going to try it anyway, and if I lose my commit bit then that will
be fine with me".  I had received that much flak.

-- 
Garance Alistair Drosehn     =               drosehn_at_rpi.edu
Senior Systems Programmer               or   gad_at_FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA
Received on Tue Sep 05 2006 - 20:32:51 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:00 UTC