Date: Tue, 5 Sep 2006 17:56:16 -0400 From: Garance A Drosehn <gad@FreeBSD.org> To: Sam Leffler <sam@errno.com> Cc: freebsd-current@FreeBSD.org Subject: Re: Adding a '-D date' option to `cat' Message-ID: <p0623093ac1235679f73f@[128.113.24.47]> In-Reply-To: <44FD994C.70104@errno.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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?p0623093ac1235679f73f>