Tool -flag considered harmful (was: grep replacement)

[Bruce G. Barnett]

I am disturbed by the growing trend by AT&T to remove as many flags as
possible from common utilities. I understand that too much baggage
can slow down a finely tuned utility used for time-consuming shell
scripts.

But when *I* have a problem I want to solve, I want to solve it as
fast as possible. 

If there is a 'variation' that I need that I don't know how to do, I
read the manual page of the program that is closest to the
functionality that I can think of. That is, if I want to look for a
particular pattern, I start with grep. If it does what I want, fine.
(Example: print the first match and exit).

But if grep doesn't do what I want, I have to hunt for a new command,
or write my own.

It is not obvious that a "stream editor" has the functionality of
grep. Even after reading the manual page, this is NOT OBVIOUS.
I also don't (always) have time to study the manual pages for hours,
trying to decipher the *real* intent of the tools.

If I want to use grep to test for a pattern, I shouldn't have to
remember that two years ago in *.wizards, article <7962 at alice.UUCP>
suggested that
	grep -1 pattern >/dev/null
was the same as
	grep -s pattern

I mean, how many extra lines would supporting both options cost?
Conversely, how many scripts will break with the new set of options?

If I want to create a patch, I use diff.

If diff loses the -c (context) option, I have to be familiar with
two commands instead of one. One being diff, one being context diff.
Why should I have to know about two different commands that do the
same thing - compare two files?

Flame me if you will, but when I use these tools in an interactive
session, I don't care if 'cat -v' is slow. Or 'diff -c'. Or grep -whatever.

I just want to find out the answers as quickly as possible.

The grep on my system is one of the fast versions. If it gets a flag
it doesn't understand, it calls up the original version for compatibility.
So it executed two programs instead of one. This is still faster 
(on my own wall clock) than
	1. Searching the whatis database to find the 'right' command
	2. Reading the manual page for the 'right' command
	3. Writing a simple shell script because the manual pages don't
	   have examples.
	4. Beating my head against the wall when I realize that the
	   new command doesn't do what I wanted EITHER.	

With the use of Shared libraries, tools should improve. The idea of
one library with the same regexp package shared by all of the
utilities should do wonders for consistant tools.

I am all for progress. Just remember, that there are tools used by the
system, and tools used by humans. Maybe I am a Neanderthal, because
I have this rock here that I do everything with......               :-)
-- 
	Bruce G. Barnett 	<barnett at ge-crd.ARPA> <barnett at steinmetz.UUCP>
				uunet!steinmetz!barnett