Subject: Re: Recursive grep
To: Tom I Helbekkmo <tih@Hamartun.Priv.NO>
From: Chief Anarchic Officer <greywolf@defender.VAS.viewlogic.com>
List: current-users
Date: 01/26/1996 13:52:34
#define AUTHOR "tih@Hamartun.Priv.NO (Tom I Helbekkmo)"

/*
 * Once we start stuffing useful little bits of functionality into
 * various individual tools, instead of generalizing the concepts as has
 * always been part of the "essence of UNIX", we invite problems with
 * internal incompatibility.  When lots of applications support "-R"
 * flags, and a couple of them have some fancy additional options, there
 * will be pressure to implement those in each of the other ones -- and
 * soon, every tool on the system will have 'find' built into it!  :-)

Well, a '-R' option is not unreasonable for programs which expect to
mangle or obtain information from inodes, i.e. ls, chmod, chown, chgrp
(which is really a special-cased chown but remains for hysterical
raisins), or something which expects to do trivial retrieval or deletion
of filenames.

There are exceptions to this:  ln and mv come to mind.  A -R option
in these cases would be redundant.

'diff -r' is stretching it a bit, history or no, but the -R option
is probably there for performance reasons.  (I never use it.)

'cp -r' is almost an aberration.  If it's going to do a recursive
copy, the least it can do is attempt to recreate symlinks (I haven't seen
a man page for cp in about five years, and the last time I ran 'cp -r',
it followed symlinks and filled my filesystem but quick, so I never
use that one anymore, either).

A general (complex) rule for code improvement, IMHO, would appear to be:

	Break at the first place you answer YES.

	a.	Is the functionality something which can be performed
		by a currently existing utility?

	b.	Would it be more robust to use the additional code to
		just write a new utility through which you could pipe
		the original command?

	c.	Would the addition of the new code break the existing
		code?

	d.	Does the addition of the new code provide output/require
		input which is not compatible with that which the old
		code provides/requires?

	e.	Does the code make any assumptions about what the user
		might want?

	f.	Is the performance improvement insignificant?

	Go for it.

Undoubtedly I've missed a few.  Feel free to fill in.

 * > There is nothing more repulsive to me than an environment in which
 * > everything is dumbed down to the point that getting details and
 * > finding more information is like pulling teeth.
 * 
 * Been forced to use Microsoft Windows NT lately, have you?  ;-)

Had to learn how to tweak and administrate (administer?) it.  It's
a piece of cake, but there are some major annoyances.

But that's another ((worm_t *)()) can->worm(1, can_t, worm_t);

[seebs -- do you still have the one of those that I originally sent?]

 * 
 * -tih
 * -- 
 * Tom Ivar Helbekkmo
 * tih@Hamartun.Priv.NO

I notice a lot of Finns showing up here -- do you folks get snowed in
a lot, or do you just not like the cold? :-)

 * 
 */

#undef AUTHOR	/* "tih@Hamartun.Priv.NO (Tom I Helbekkmo)" */




				--*greywolf;
--
America is quite possibly the only country to go from barbarism to
decadence without the requisite intervening period of civilisation.