Xref: utzoo comp.unix.wizards:9331 comp.unix.questions:7575 Path: utzoo!attcan!uunet!steinmetz!vdsvax!barnett From: barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) Newsgroups: comp.unix.wizards,comp.unix.questions Subject: Tool -flag considered harmful (was: grep replacement) Summary: don't take away my flags! Message-ID: <4615@vdsvax.steinmetz.ge.com> Date: 13 Jun 88 14:20:30 GMT References: <7962@alice.UUCP> Reply-To: barnett@steinmetz.ge.com (Bruce G. Barnett) Organization: General Electric CRD, Schenectady, NY Lines: 65 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@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 uunet!steinmetz!barnett