Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucsdhub!hp-sdd!hplabs!hpfcso!hpldola!hp-lsd!tbc
From: tbc@hp-lsd.COS.HP.COM (Tim Chambers)
Newsgroups: comp.sys.hp
Subject: Re: cp gives poor error message (so what else is new?)
Message-ID: <8250017@hp-lsd.COS.HP.COM>
Date: 1 Dec 89 20:12:57 GMT
References: <210038@speclab.bgp-usgs.gov>
Organization: HP Logic Systems Division - ColoSpgs, CO
Lines: 15

In our lab, a wise software project manager recently made a proclamation
something to the effect:  "The specification is frozen.  All requests for
changes to this project's library of functions are hereby forever denied.
Defects will be repaired when the behavior of the functions deviates from the
published specification.  If it isn't part of the specification, the behavior
will not change under *any* circumstances.  Worthy enhancements will be
accommodated by created new, unique functions."  I was taught the same policy
in college.  I agree with it.

Others have pointed out the unexpected pitfalls with '"improving" the UN*X out
of UN*X.' IMHO, old commands should be left alone and new ones should take
over.  I hope we aren't doomed to always have a name with historical baggage,
like awk and nawk or less replacing more(1).  sh(1) vs.  ksh(1) is an
excellent example -- all my scripts now start with #!/bin/ksh.  Much cleaner
than "improving" the Bourne shell.