Re: Adding a 'D - Date' option to 'cat'

On Thu, Sep 07, 2006 at 01:00  Garance A Drosehn said 'Who you talkin' to? 
You talkin' to Garance A Drosehn?  I didn't do nuttin'.  I said:

> At 11:09 PM -0400 9/6/06, Bill Vermillion wrote:
> >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_at_freebsd.org uttered this
> >load of codswallop:

> Heh.   :-)

My automated attrib program - written by a friend - as we both go
so tired of the same old attrib lines.  Works in mutt.


> > > 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.
> 
> Well, I do agree with that.  The situation which bugs me is when
> you have lots of programs, all of which are exactly the same as
> `cat' program, but with ten extra lines added to it.  I'm not
> saying that you add every option which might possibly be "needed".
> I'm saying add the options which naturally fit into the algorithm
> that `cat' already uses.  Something like `awk' has many useful
> features, but those features cannot be implemented by adding ten
> lines of code to the already-existing cook() subroutine in `cat'.

For programs that are almost the same with almost the same
functionality why not give them multiple names via hard-links
and then just check 'arg 0' for the name by which it has been
called and then execute the correct functions.

This is done, for example, in the compress type programs - as
opposed to the MS approach with two virtually identical programs
with their own name. That's why I gave us MS after working with
DOS 2l0 and moved to Unix. I'm a pikcy person :-)

> Taken to an extreme, the unix philosophy would create thousands of
> programs, each of which calls one and only one libc routine.  And
> then "people can mix and match them as they see fit".  Ie, every
> single user can become full-blown programmers.  Each one can spend
> their time writing buggy programs, because they won't take the
> time to consider all the error situations, etc.  They won't even
> know what they should be watching out for.

How true.  But that's how I made/make money.  Going in and fixing
things that someone who had zero clues tried to do.  Sometimes
they've mucked things up so badly it takes a lot of timea and they
spend lots of 'bux' to get it fixed.  But then again I have a
server mentality even though my main home machine has been a
Unix based system since 1985 - and for several years I was running
a Usenet node - and three local machines incuding mine - were
feeding over 50 leaf nodes - all by modem.

> I'll also agree that this didn't really belong as a new option to
> `cat', since if this was added to `cat' then there would be ten
> other options immediately proposed for `cat'.  And if I were asked
> about those options, I would be a hypocrite to say "I don't like
> that idea", when those options would probably be just as defendable
> as mine was.  And yet I'm sure I would have said that at some
> point.  So, the correct answer was to add some new command.

Yup.  Once you make a change, someone else want's another change,
and it gets out of hand.  I think that's part of MS'es problem.

> But some time ago I added the `pgrep' and `pkill' commands to
> FreeBSD, which were *copied* from other systems (they weren't even
> my idea), and I got so much flak about that at the time that I
> swore I'd never add another command to FreeBSD.  So, when this
> came up I looked for some other command to stick the option into.
> Given the code in `cat', which already had 99% of what I needed,
> that seemed like the most plausible choice.

Thanks for the pointer to pgrep and pkill.  I just made them and
will try them out.  Only problem was the make file wanted to
goto /man/man  not /usr/share/man/man.  I quick edit fixed that.

I don't see why people would complain about porting something from
another system into FreeBSD.  It seems to be done often.


Bill
-- 
Bill Vermillion - bv _at_ wjv . com