Re: Adding a 'D - Date' option to 'cat'
- From: Bill Vermillion <bv@xxxxxxx>
- Date: Thu, 7 Sep 2006 21:57:31 -0400
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@xxxxxxxxxxx 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 @ wjv . com
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: Adding a 'D - Date' option to 'cat'
- From: Don L. Belcher
- Re: Adding a 'D - Date' option to 'cat'
- References:
- Re: Adding a 'D - Date' option to 'cat'
- From: Bill Vermillion
- Re: Adding a 'D - Date' option to 'cat'
- Prev by Date: Re: Attempt #3, adding a new command 'sfilter'
- Next by Date: Page fault in uipc_usrreq.c:997
- Previous by thread: Re: Adding a 'D - Date' option to 'cat'
- Next by thread: Re: Adding a 'D - Date' option to 'cat'
- Index(es):
Relevant Pages
|
