Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Sep 2006 23:09:13 -0400
From:      Bill Vermillion <bv@wjv.com>
To:        freebsd-current@freebsd.org
Subject:   Re: Adding a 'D - Date' option to 'cat'
Message-ID:  <20060907030913.GN87762@wjv.com>
In-Reply-To: <20060906120042.9E9DB16A532@hub.freebsd.org>
References:  <20060906120042.9E9DB16A532@hub.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
While normally not able to pour water out of a boot with
instructions on the heel, on Wed, Sep 06, 2006 at 12:00 our dear
friend freebsd-current-request@freebsd.org uttered this load of
codswallop:


> Date: Tue, 5 Sep 2006 18:32:43 -0400
> From: Garance A Drosehn <gad@FreeBSD.org>
> Subject: Re: Adding a '-D date' option to `cat'

> 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?  ...

However if using your example of stringing programs together, if
you make a separate program then it can be used in a pipe so
you can apply it to any program you wish.

That's pretty much the basic Unix philosophy - a lot of small
programs that can be chained together to do almost anything you can
imagine, instead of putting all the POSSIBLE needed options into
each program that MAY or MAY NOT need it.

Adding the options to other programs [once something gets in motion
it's hard to stop] would cause more bloat than 4 commands that
could be used in any order or fashion for other uses.

That philosphy is what makes Unix so maleable as opposed to other
OSes wich bloat programs that should be simple and used as bullding
blocks to swiss-army-knife-options tools.

Bill
-- 
Bill Vermillion - bv @ wjv . com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060907030913.GN87762>