rm etc.

[Doug Gwyn]

In article <730 at quintus.UUCP> ok at quintus.UUCP (Richard A. O'Keefe) writes:
>What is "completely misleading" about that question?

"Override protection" implies that the link was protected against removal,
which of course it wasn't.  (If it HAD been, "rm" would have to change
permissions on the directory before unlinking, which it doesn't.)

I suppose the reason no "rm: " prefix was used was because in interactive
use there isn't much question about where the prompt is coming from.
(In a complex situation I agree there could be, so I wouldn't quarrel
with adding "rm: " to the SVR2 prompt.)

The real problem with these low-level UNIX utilities is that a lot of
them attempt to "help", based on a simplistic model of their expected
usage, whereas they should just do what they're told.  "User
friendliness" depends on the user; I generally find all these "confirm"
prompts to get in the way.  That sort of noise should be reserved for
naive-user environments (Macintosh-style interfaces, for example), not
wired into the basic tools.  Of course I don't object to tools balking
at patently incorrect usage, e.g. "cp a a" where "a" is an ordinary
file.  But I would be annoyed if "cp /dev/tty32 /dev/tty32" balked or
asked me whether I really knew what I was doing.

On reading the Ninth Edition UNIX manual some time ago, I was pleased
to see that some of the worst quirks in the basic utilities had been
cleaned up.  For example, "cat" worked right without a -u option,
unlike the System V version.

UNIX is getting too fat these days.  It would have been nice if every
time an addition to the system had been proposed, first some other
feature would have to have been identified for deletion from the system.
That may have stalled some features until the right way to design them
had been figured out.  Now we're stuck with a hodge-podge of features
that are poorly integrated, and paying customers who realy on the
continued existence of those misfeatures.  Sigh.