Date: Tue, 5 Sep 2006 18:32:43 -0400 From: Garance A Drosehn <gad@FreeBSD.org> To: Doug Barton <dougb@FreeBSD.org>, Julian Elischer <julian@elischer.org> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-current@FreeBSD.org, Garance A Drosehn <gad@FreeBSD.org> Subject: Re: Adding a '-D date' option to `cat' Message-ID: <p0623093cc123a5807cf9@[128.113.24.47]> In-Reply-To: <44FDF36A.3010608@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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?p0623093cc123a5807cf9>