achar@atari.UUCP (Alan Char) (11/15/88)
In article <672@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: |Now, how _do_ you fix "rm *"? Suppose you restrict rm to delete exactly |one file. Watch: | foreach F (* .o) | rm $F | end |OOPS! Major bug in foreach! Better fix that. | [ other examples ] | |Moral: you can't change _one_ thing. Actually, you can change the shell. (Nowadays, that's more like three to five things.) For example, I would REALLY appreciate in csh a variable set expandcheck=5 So that if some shell expansion expanded to more than 5 things, it would prompt for confirmation: % rm * .o *: matches 400 files, are you sure? Comments on this idea? --Alan
matt@oddjob.uchicago.edu (Matt Crawford) (11/16/88)
In article <1232@atari.UUCP>, achar@atari (Alan Char) writes:
) For example, I would REALLY appreciate in csh a variable
) set expandcheck=5
) So that if some shell expansion expanded to more than 5 things, it would
) prompt for confirmation. Comments on this idea?
This sounds much, MUCH better than changing any other system program in
any way.
Mattok@quintus.uucp (Richard A. O'Keefe) (11/16/88)
In article <1232@atari.UUCP> achar@atari.UUCP (Alan Char) writes: >In article <672@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >|Moral: you can't change _one_ thing. >Actually, you can change the shell. (Nowadays, that's more like three to >five things.) For example, I would REALLY appreciate in csh a variable > set expandcheck=5 >Comments on this idea? --Alan Well, there _is_ such a feature already, except that the limit is rather high, and you can't change it (:-). BSDish systems impose a limit of 10,240 bytes of argv[]; this seems to include the pointers, so you can't pass more than about 2000 files to any command (hence xargs(1)). The trouble is that I can't think of a reasonable number for the limit: I do "egrep foo $dirs/*.c" (rummaging around in dozens of files) often enough that I'd find it a nuisance to have to clear a small limit. If you are doing something non-destructive to the files, you usually don't want a limit, it's only if you're over-writing or destroying the files that you have a problem. And expandcheck _still_ wouldn't stop find . ! -user $LOGNAME -exec rm {} \; {remove all files not owned by me in the current subtree} -- forget the "!" and you lose big. The standard trick for csh is alias rm "/bin/rm -i"
weemba@garnet.berkeley.edu (Obnoxious Math Grad Student) (11/16/88)
In article <794@tank.uchicago.edu>, matt@oddjob (Matt Crawford) writes: >In article <1232@atari.UUCP>, achar@atari (Alan Char) writes: >) For example, I would REALLY appreciate in csh a variable >) set expandcheck=5 >) So that if some shell expansion expanded to more than 5 things, it would >) prompt for confirmation. Comments on this idea? >This sounds much, MUCH better than changing any other system program in >any way. And while whosoever is at it, how about a histnoclobber variable? The only time I've regretted having noclobber unset was the time that I had an unintended invocation of a clobbering command via history. Any other goodies like this for the merely mildly clumsy/paranoid? ucbvax!garnet!weemba Matthew P Wiener/Brahms Gang/Berkeley CA 94720
john@basser.oz (John Mackin) (11/16/88)
In article <1232@atari.UUCP> achar@atari.UUCP (Alan Char) writes: > Actually, you can change the shell. (Nowadays, that's more like three to > five things.) For example, I would REALLY appreciate in csh a variable > > set expandcheck=5 > > So that if some shell expansion expanded to more than 5 things, it would > prompt for confirmation: > > % rm * .o > *: matches 400 files, are you sure? > > Comments on this idea? --Alan My basic comment is `Oh, no!!!' The point about any hack that is supposed to make mistakes in command lines, say rm command lines, less dangerous is that it's just fine as long as the people who are going to use it are never, at any time in the future, going to use a different UNIX system on which the hack doesn't exist. When they do, they will get into big trouble, because they won't be used to being careful with `dangerous' commands, like rm; they'll expect the system to babysit them, and it won't, just like it never should have in the first place. I know systems where rm is interactive by default. I've personally seen plenty of users on such systems whose habitual way of cleaning up a directory was `rm *'. How much trouble will they be in when they go somewhere else that runs a _real_ rm command? Hacks like this are a _terrible_ idea. Please do not implement such things. John Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia john@basser.oz.AU (john%basser.oz.AU@UUNET.UU.NET) {uunet,mcvax,ukc,nttlab}!munnari!basser.oz!john
pst@canary.cdi.com (Paul Traina) (11/17/88)
From article <1232@atari.UUCP>, by achar@atari.UUCP (Alan Char):
< Actually, you can change the shell. (Nowadays, that's more like three to
< five things.) For example, I would REALLY appreciate in csh a variable
<
< set expandcheck=5
<
< So that if some shell expansion expanded to more than 5 things, it would
< prompt for confirmation:
<
< % rm * .o
< *: matches 400 files, are you sure?
<
< Comments on this idea? --Alan
I'll assume (from the gist of the protection) that this is to stop
stupidity, rather than a deliberate attack. After all, a worm would
either know what to do at this point, or more likely, have used unlink(2).
My question is, if we have the shell fix it, how can we get the shell
to understand flags passed to the executable? To give an example, if I
do 'rm * .o' I probably wouldn't mind seeing the match message come up.
However, 'rm -f * .o' means do it, yes I mean it, don't ask stupid questions.
I would use it in a shell script no doubt. Now of course, it's pretty unlikely
that's what I meant. Perhaps better consistency checking in rm itself would
be the answer.
For instance, have rm (if -f is not used) check each path parameter passed to
it. If one doesn't match at existing file at all, ask that the command be
confirmed. Well, like any solution that's been discussed so far, this has
problems too. I guess the best solution would be a modification of the human
involved so s/he always types what s/he means to type. hmmm.
Comments on these ideas?
------
Paul Traina To believe that what is true for
{uunet|pyramid}!comdesign!pst you in your private heart is true
pst@cdi.com for all men, that is genius.achar@atari.UUCP (Alan Char) (11/17/88)
In article <684@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: |In article <1232@atari.UUCP> achar@atari.UUCP (Alan Char) writes: ||I would REALLY appreciate in csh a variable || set expandcheck=5 | |The trouble is that I can't think of a reasonable number for the limit: |I do "egrep foo $dirs/*.c" (rummaging around in dozens of files) often |enough that I'd find it a nuisance to have to clear a small limit. If |you are doing something non-destructive to the files, you usually don't |want a limit, it's only if you're over-writing or destroying the files |that you have a problem. Usually if I'm doing "egrep foo $dirs/*.c", I expect the command to take a substantial (at least noticable) amount of time, so I don't think I'd find it much of a nuisance to confirm my intentions. It just depends on what your tolerance is for that kind of thing, I guess. |And expandcheck _still_ wouldn't stop | | find . ! -user $LOGNAME -exec rm {} \; | |{remove all files not owned by me in the current subtree} -- forget the |"!" and you lose big. Personally, I would blame this on the syntax of find. This has nothing to do with shell expansion generating something you didn't intend. It has to do with an arcane syntax being prone to typographical catastrophes. |The standard trick for csh is | alias rm "/bin/rm -i" Yes, but getting confirmed when you want to remove only one file? Every time? That really IS a nuisance. % rm core rm: remove core? --Alan Char
charlie@mica.stat.washington.edu (Charlie Geyer) (11/17/88)
Creeping featurism considered harmful. Leave it alone. This is all very easy. If you don't like rm(1) put alias foo rm -i in your .cshrc or put a shell script foo in ~/bin rm -i $* and use foo to remove files.
guy@auspex.UUCP (Guy Harris) (11/18/88)
>BSDish systems impose a limit of 10,240 bytes of argv[];
Of course, SunOS 4.0 imposes a limit of
#define NCARGS 0x100000
so it won't help on a 4.0 system....achar@atari.UUCP (Alan Char) (11/18/88)
|In article <564@comdesign.CDI.COM> pst@canary.cdi.com (Paul Traina) writes: ||From article <1232@atari.UUCP>, by achar@atari.UUCP (Alan Char): || I would REALLY appreciate in csh a variable || || set expandcheck=5 || || So that if some shell expansion expanded to more than 5 things, it would || prompt for confirmation. | |My question is, if we have the shell fix it, how can we get the shell |to understand flags passed to the executable? To give an example, if I |do 'rm * .o' I probably wouldn't mind seeing the match message come up. | |However, 'rm -f * .o' means do it, yes I mean it, don't ask stupid questions. |I would use it in a shell script no doubt. Now of course, it's pretty unlikely |that's what I meant. Perhaps better consistency checking in rm itself would |be the answer. As is the case now, I think the shell should not have to know about special flags passed to the executable, so your script will still get caught. Of course, after you've debugged your script, you can put "unset expandcheck" at the top. |For instance, have rm (if -f is not used) check each path parameter passed to |it. If one doesn't match at existing file at all, ask that the command be |confirmed. Well, like any solution that's been discussed so far, this has |problems too. I guess the best solution would be a modification of the human |involved so s/he always types what s/he means to type. hmmm. Well, it's not always rm that needs to be checked. How about "mv * .o <remote dir>"? This was the original objection in the article by Richard O'Keefe: You can't change just one thing. --Alan
biep@cs.vu.nl (J A Biep Durieux) (11/18/88)
At the very least, 'rm * .o' should refuse to do anything when the file '.o' doesn't exist. -- Biep. (biep@cs.vu.nl via mcvax) Is the difference between a difference of degree and a differ- ence of sorts a difference of degree or a difference of sorts?
bzs@encore.com (Barry Shein) (11/19/88)
At first I was skeptical but the more I think about the expandcheck idea the more I like it, it can be implemented in some reasonable way. There's even precedent, like noclobber, so I don't see any look and feel problem with it (ie. some things like this are a stench in the nose of god, this isn't.) A very similar proposal would be more like the CMU Csh (and I believe the Korn shell) which echo back history substitutions and wait for confirmation <NL>, I could imagine doing (OPTIONALLY) the same for wildcard matches past a certain threshold... The only possible objection to any of this that pops to mind is transparency between shell scripts and interactive sessions but that's easy, it should always start out as false/zero/infinity and if set will do its thing (heck, if it confirmed to /dev/tty it could be useful in scripts.) -Barry Shein, ||Encore||
bickel@nprdc.arpa (Steven Bickel) (11/19/88)
# aliasing rm to this simple shell script should solve all rm problems
# providing you have some extra disk space and the rm_purge alias is executed
# regularly ie. in a .login file. It will currently purge all files from
# the removal directory after 21 days.
# remove script
num=0;
for i in $@
do
if test -r $i
then
chmod 777 $i;
rm_dir="/usr/tmp/rmtmp/$i";
echo "moved" $i $rm_dir ;
mv $i $rm_dir;
num=num+1;
fi
done
alias rm_purge "find /usr/tmp/rmtmp/ -name '*' -print -atime +21 -exec rm -r '{}' \;"
Steve Bickel bickel@nprdc.arpa
Systems Engineering Assoc. (619) 553-9306
Naval Personel R & D Center.
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (11/19/88)
Good grief you guys. Leave poor /bin/rm alone. Set your new users up with an alias to some form of vanish or other. It's a trivial program to write--there's one as an example with the perl distribution. Then just expire your .deleted directories after a few days. Then it doesn't matter if they type rm * .o because they can turn around and unvanish anything they like. Haven't we learned anything from all these whiz-bang graphics interfaces with trashcans? Larry Wall lwall@jpl-devvax.jpl.nasa.gov
ok@quintus.uucp (Richard A. O'Keefe) (11/19/88)
In article <1670@ski.cs.vu.nl> biep@cs.vu.nl (J A Biep Durieux) writes: >At the very least, 'rm * .o' should refuse to do anything when the file '.o' >doesn't exist. I have posted a "del" command to comp.sources.unix which does this.
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (11/20/88)
This dicussion surfaces at least once every 6 months. Gene
Spafford out to summarize and put into the 100 questions
document:
In a job a long time ago in a place far, far away .... Four of
us got bit by the rm * problem within two days. I lost a whole
day's worth of power coding and had to reconstuct an entire
project from memory [see Knuth on the merits of this] when I
typed rm *.c instead of rm *.o.
So, I decided there must be a better way. Since we also had a
set of other similar commands [del and delete for the PDP-10
lovers] we built a trap door into the shell. If the command was
exactly {rm|del|delete} and the glob function returned a true
[expanded a * ? or [ ...] construct] we echoed out to the
terminal the expanded form of the command and a request to
confirm.
e.g the command
rm *.c
whould result in
glob: rm foo.c bar.c barf.c fubar.c unix.c
confirm?
The query would only be echoed if the stdin was a terminal.
Also, it worked ONLY with simple command names, full path names
or alias expansions weren't checked.
We also got bit later by the following:
rm -rf ..
So we had to put a check into rm for that kind of combination.
Yes, we did get a few people who would hit y<CR> by habit. But
only until they did it one too many times. After that they
learned.
--
=Dennis L. Mumaugh
Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.comdrears@ardec.arpa (Dennis G. Rears (FSAC)) (11/20/88)
J A Biep Durieux writes: >At the very least, 'rm * .o' should refuse to do anything when the file '.o' >doesn't exist. "rm" doesn't see the *. The shell does all the expansion. All rm sees is the options and a list of file names. If you don't like the actions of rm, either change it by making the interactive option the default or write you own. rm does what you tell it do nothing more nothing less. Gee, I wish my boss was like that :-). Dennis
ncgus@ndsuvax.UUCP (jim gustafson) (11/20/88)
>In article <672@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >|Now, how _do_ you fix "rm *"? Suppose you restrict rm to delete exactly >|one file. Watch: >| foreach F (* .o) >| rm $F >| end >|OOPS! Major bug in foreach! Better fix that. >| [ other examples ] >| >|Moral: you can't change _one_ thing. Maybe I missed something, but doesn't everybody have 'rm' re-defined as an alias or $HOME/bin/rm? Something like: for fnam in $* do mv -f $fnam $HOME/.trash done In Korn, I use alias rrm=/bin/rm in my .kshrc so I can do the dirty work. (the trick is to always use 'rm' ;-). -- Jim Gustafson UUCP: uunet!ndsuvax!ncgus North Dakota State University Bitnet: ncgus@ndsuvax Fargo, North Dakota 58105 Internet: ncgus@plains.nodak.edu
ok@quintus.uucp (Richard A. O'Keefe) (11/21/88)
In article <1812@ndsuvax.UUCP> ncgus@ndsuvax.UUCP (jim gustafson) writes: >Maybe I missed something, but doesn't everybody have 'rm' re-defined as >an alias or $HOME/bin/rm? I do hope not. It is a bad idea to define aliases for the standard commands (and if you are a system administrator, giving new users profiles with such redefinitions in them is _extremely_ bad manners). For example, I very much like the "-F" option in ls, but it would be incredibly stupid to "alias ls 'ls -F'". Instead I "alias lf 'ls -AF'" and use "lf". Just so, if you don't like what rm does, _leave_it_alone_ and define yourself an alias, script, C program, or whatever, called "del", "delete", "delf", or whatever takes your fancy, and use that. Apart from the obvious problem of changing something so that it no longer does what the manual says it does, there are other reasons for not relying on aliases for standard commands. For example, we have several different systems on our net here, running several varieties of UNIX. Some of them have the C shell, some don't. Some of them I have my own accounts on, some of them I share a "porting" account. If I rely on an alias for rm to protect me, the next time I log into a new box I will be _sunk_.
boyd@necisa.necisa.oz (Boyd Roberts) (11/21/88)
In article <564@comdesign.CDI.COM> pst@canary.cdi.com (Paul Traina) writes: > >However, 'rm -f * .o' means do it, yes I mean it, don't ask stupid questions. > Incorrect. When I type "rm * .o" it means do it, yes I mean it, don't ask stupid questions. Admittedly, I'd just type "rm *". How many more safety net arguments to we have to suffer? There's no way: set don't-do-an-incredibly-stupid-thing = 5 will ever be an appropriate solution to this (non) existant problem. Do something stupid, pay the price. Easy! The next thing you'll want is VAXen like console processors where you can go: >>> SET NO AXE THROUGH CPU And a titanium cage closes around your processor. Boyd Roberts NEC Information Systems Australia boyd@necisa.necisa.oz ``When the going gets wierd, the weird turn pro...'' D
venters@argos.uucp (Jeff Venters) (11/21/88)
A simple solution for csh users:
The following alias will prevent wildcard expansions. The actual wildcard
characters will be passed to the script. Add the following alias to your
~/.cshrc:
alias rm ~/bin/del \!\*:q
Next, add the following shell script to your personal "bin" directory (or
wherever you like). Obviously, the script could be made intellegent enough
to recognize "-f" but it would be slower (csh is very inefficient). You
could write a C-program to do this slightly faster (you would still have
to fork a shell to glob the input arguments).
---- CUT HERE -------- CUT HERE -------- CUT HERE -------- CUT HERE ----
#! /bin/csh -f
set nonomatch file=$0 # no wildcard matches allowed/get argv[0]
set exp_names=($argv) # expand wildcards (if any)
#
# if the number words after globbing is not equal to the orignal,
# ask for conformation.
if ($#argv == $#exp_names) then
/bin/rm $exp_names:q
exit $status # exit script here (faster)
else
echo "$file:t: The following $#exp_names files will be deleted:"
# show them the damage they could do
/bin/ls -Fd $exp_names:q
echo -n "Are you sure you want to do this (Y or N)? "
if ($< =~ [Yy]) then
exec /bin/rm $exp_names:q
else
echo ""
echo "$file:t: aborted - no files deleted"
exit (1)
endif
endif
---- CUT HERE -------- CUT HERE -------- CUT HERE -------- CUT HERE ----
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jeff Venters, Convex Computer Corporation, Richardson, Texas
Internet: venters@convex.COM | UUCP: {uiucuxc,sun,rice}!convex!venters
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=gwc@root.co.uk (Geoff Clare) (11/21/88)
In article <1615@basser.oz> john@basser.oz (John Mackin) writes: }The point about any hack that is supposed to make mistakes in }command lines, say rm command lines, less dangerous is that it's }just fine as long as the people who are going to use it are never, }at any time in the future, going to use a different UNIX system on }which the hack doesn't exist. When they do, they will get into }big trouble, because they won't be used to being careful with }`dangerous' commands, like rm; they'll expect the system to }babysit them, and it won't, just like it never should have in }the first place. } }I know systems where rm is interactive by default. I've personally }seen plenty of users on such systems whose habitual way of cleaning }up a directory was `rm *'. How much trouble will they be in when }they go somewhere else that runs a _real_ rm command? } }Hacks like this are a _terrible_ idea. Please do not }implement such things. I wouldn't go so far as to say don't implement them at all. What I would say is CALL THEM SOMETHING ELSE. If you implement a safe 'rm', call it something else like 'del', and tell novice users not to use 'rm' because it is dangerous. (To make sure they don't use it you could put a dummy 'rm' in their path which echoes "rm is dangerous - use del instead". Then when they move to a different system and they get 'del: not found' they will know how to use 'rm' but will be careful with it. -- Geoff Clare UniSoft Limited, Saunderson House, Hayne Street, London EC1A 9HH gwc@root.co.uk ...!mcvax!ukc!root44!gwc +44-1-606-7799 FAX: +44-1-726-2750
trn@aplcomm.jhuapl.edu (Tony Nardo) (11/22/88)
In article <1067@entropy.ms.washington.edu> charlie@mica.stat.washington.edu (Charlie Geyer) writes: >This is all very easy. If you don't like rm(1) put > > alias foo rm -i > >in your .cshrc... A half-measure. If you *really* don't like rm(1), put alias rm "rm -i" in your .cshrc file. That way, if you want to use rm without the -i switch, you have to do a little extra work (/bin/rm). By the same token, alias cp "cp -i" can protect you from yourself with file copying. ============================================================================== ARPA, BITNET: trn@aplcomm.jhuapl.edu UUCP: {backbone!}mimsy!aplcomm!trn ==============================================================================
gandalf@csli.STANFORD.EDU (Juergen Wagner) (11/22/88)
In article <717@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <1812@ndsuvax.UUCP> ncgus@ndsuvax.UUCP (jim gustafson) writes: >>Maybe I missed something, but doesn't everybody have 'rm' re-defined as >>an alias or $HOME/bin/rm? > >I do hope not. It is a bad idea to define aliases for the standard >commands (and if you are a system administrator, giving new users >profiles with such redefinitions in them is _extremely_ bad manners). Redefining "rm" as "rm -i", "mv" as "mv -i", and "cd" et al. to the prompt- changing versions is *VERY* common practice, I think. System administrators do not put these into the .cshrc to surprise people, they are there to help beginners to start in a safe environment (at least safer than without these definitions), without having to worry about mistakenly typing "rm foo/ *". Expert users may change that as soon as they are logged in for the first time. (Before I work on a system, I check the .cshrc, .login, etc. to see what's in there.) >For example, I very much like the "-F" option in ls, but it would be >incredibly stupid to "alias ls 'ls -F'". Instead I "alias lf 'ls -AF'" >and use "lf". Just so, if you don't like what rm does, _leave_it_alone_ >and define yourself an alias, script, C program, or whatever, called >"del", "delete", "delf", or whatever takes your fancy, and use that. Bad example. "ls" is a command you can execute umpteen plus one times without destroying anything. "rm" and "mv" *CAN* destroy files. I agree that aliasing "ls" to "ls -F" or similar stuff would be stupid. Aliasing "rm" is less stupid because it protects the user against him/herself. Personally, I tend to give longer names to destructive command than to the non-destructive versions. "rm" prompts me for confirmation, "delete" doesn't. If an expert user doesn't like that aliasing as soon as he/she logs in for the first time... >Apart from the obvious problem of changing something so that it no longer >does what the manual says it does, The point is, if UNIX gives a novice user a command to erase important files with five keystrokes and no confirmation, this command should be made safe, so it will at least prompt for confirmation. By the kind of aliasing we are discussing here, the safety of commands is increased, never decreased. Therefore, the manual accurately describes what "rm" does, modulo that little safety feature. People who know little about UNIX are likely to know basic commands such as "rm", "mv", "cp", "ls", ... and they know what they do. They do not know how to alias commands, edit the .cshrc. Everything is magic in the beginning, so they try to stick to the commands they think they know. Well, and then it just happens that files are accidentially deleted. > there are other reasons for not relying >on aliases for standard commands. For example, we have several different >systems on our net here, running several varieties of UNIX. Some of them >have the C shell, some don't. Some of them I have my own accounts on, >some of them I share a "porting" account. If I rely on an alias for rm >to protect me, the next time I log into a new box I will be _sunk_. I guess, you wouldn't consider yourself a novice user of UNIX. If you like the unaliased "rm", that's fine. Unexperienced users do appreciate the extra protection. As for non-csh shells, how about "rm () { /bin/rm -i $* }" as an 'alias' for "rm". As a consultant, I am also working under other peoples accounts. If I am just fixing something, I simply do not rely on "rm" being aliased. If I have to work longer under some account, I define the aliases necessary, or just load my setup into a new shell. To summarize: Some people like the aliases, some don't. Those who like and appreciate them (like novice users and many expert users) should have them, those who don't like them, who are considering them harmful, bad style, or whatever, shouldn't have them. I don't seen any reason why anybody should insist on any solution being better than the other - it depends! However, it is desirable to protect new users against the unwanted effects of some silent and destructive commands, so I would put the respective aliases into new users .*rc file. Those who don't like them (etc.) can remove the aliases easily, and will have completely different .cshrc/.login files than the system default, anyway. This is my personal opinion. -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
kirkaas@oahu.cs.ucla.edu (paul kirkaas) (11/22/88)
In article <6518@csli.STANFORD.EDU> wagner@arisia.xerox.com (Juergen Wagner) writes: >In article <717@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>In article <1812@ndsuvax.UUCP> ncgus@ndsuvax.UUCP (jim gustafson) writes: --- (deleted) --- >>For example, I very much like the "-F" option in ls, but it would be >>incredibly stupid to "alias ls 'ls -F'". Instead I "alias lf 'ls -AF'" --- (deleted) --- > ... I agree that aliasing >"ls" to "ls -F" or similar stuff would be stupid... I may well be incredibly stupid. I suspect, however, there is far more convincing evidence for that proposition than the fact that I alias ls to ls -F. I guess I'm a little disturbed at how easily we call others stupid for using harmless practices which differ from our own. If I ever run into problems because of my alias, I'll change it. So far I've survived. Paul Kirkaas kirkaas@cs.ucla.edu
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/23/88)
In article <1232@atari.UUCP> achar@atari.UUCP (Alan Char) writes: >In article <672@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >|Now, how _do_ you fix "rm *"? ... > if some shell expansion expanded to more than 5 things, it would >prompt for confirmation: What I did, a decade ago, was to have a list of _commands_ which the shell, after calling glob, would always prompt for after printing out the entire expanded command line. The list included "rm" and "rmdir". No prompting if "glob" was not called. Perhaps I should go resurrect that code. Joe Yao jsdy@hadron.COM (not yet domainised) hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM} arinc,att,avatar,blkcat,cos,decuac,dtix,\ ecogong,empire,gong,grebyn,inco,insight, \!hadron!jsdy kcwc,lepton,netex,netxcom,phw5,rlgvax, / seismo,sms,smsdpg,sundc,uunet /
fischer@iesd.uucp (Lars P. Fischer) (11/23/88)
In article <564@comdesign.CDI.COM> pst@canary.cdi.com (Paul Traina) writes: >From article <1232@atari.UUCP>, by achar@atari.UUCP (Alan Char): >< Actually, you can change the shell. (Nowadays, that's more like three to >< five things.) For example, I would REALLY appreciate in csh a variable >< >< set expandcheck=5 >< >However, 'rm -f * .o' means do it, yes I mean it, don't ask stupid questions. #!/bin/csh unset expandcheck rm -f * .o -- Lars Fischer, fischer@iesd.dk, {...}!mcvax!diku!iesd!fischer We must remove the TV-induced stupor that lies like a fog across the land. - T. H. Nelson
ok@quintus.uucp (Richard A. O'Keefe) (11/23/88)
In article <6518@csli.STANFORD.EDU> wagner@arisia.xerox.com (Juergen Wagner) writes: >In article <717@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>I do hope not. It is a bad idea to define aliases for the standard >>commands (and if you are a system administrator, giving new users >>profiles with such redefinitions in them is _extremely_ bad manners). > >Redefining "rm" as "rm -i", "mv" as "mv -i", and "cd" et al. to the prompt- >changing versions is *VERY* common practice, I think. System administrators >do not put these into the .cshrc to surprise people, they are there to help >beginners to start in a safe environment (at least safer than without these >definitions), without having to worry about mistakenly typing "rm foo/ *". A very common practice may never-the-less be a bad idea. It is no service to beginnners to give them an alias WHICH DOES NOT MATCH THE DOCUMENTATION. By all means, provide a "del" or "delete" command which is safe, and a "move" or "rename" command which is safe, but if you want to protect beginners from the dangerous commands, give them aliases which flat-out refuse to do anything at all: alias rm 'echo "Use \"delete\" to delete files; rm is dangerous."' System administrators may not _intend_ to surprise people with their redefinitions, but that is one of the effects they do in fact produce. The other effect is that the commands available to the beginner no longer match the documentation; how anyone can perceive that as good is beyond me. >>For example, I very much like the "-F" option in ls, but it would be >>incredibly stupid to "alias ls 'ls -F'". Instead I "alias lf 'ls -AF'" >>and use "lf". Just so, if you don't like what rm does, _leave_it_alone_ >>and define yourself an alias, script, C program, or whatever, called >>"del", "delete", "delf", or whatever takes your fancy, and use that. > >Bad example. No, it is _not_ a bad example. If I "alias ls 'ls -F'", I am likely to use it in a script which _relies_ on that behaviour. Then I give it to someone else and it doesn't work. THIS KIND OF THING **HAPPENS**. But if I use "lf" in my script, then the other user is going to be told that there isn't any such command. >As for non-csh shells, how about "rm () { /bin/rm -i $* }" as an 'alias' for >"rm". Well, that's nice for you, but many of the machines that I use do not support Bourne shell functions. I get syntax error: `(' unexpected when I try that. (We have Suns running 3.x and 4.x, which support shell functions, but also Suns running 2.x, which don't, and several other machines running 4.2BSD. What is *really* confusing is the machines which offer two "universes", where shell functions work in one universe but not the other. My .profile has to work under _all_ of these.) >As a consultant, I am also working under other peoples accounts. If I am just >fixing something, I simply do not rely on "rm" being aliased. No, that's not the problem. The problem is that you can't rely on it NOT being aliased. If you are using someone else's account, you haven't ANY IDEA *AT ALL* what rm does until you have checked for aliases and shell functions. Especially with the "rm" aliases which copy files someone else, if you issue an "rm" command to delete a file that you have just created, you cannot rely on that not destroying a file that the real user was hoping to keep. I for one am sick of having to type \rm. >However, it is desirable to protect new users against the unwanted effects of >some silent and destructive commands, so I would put the respective aliases >into new users .*rc file. I repeat: it is ok to alias a standard command so that it refuses to do anything at all, and makes it plain that it has not worked. But it is a bad idea to make a command _do_ something, but not _exactly_ what is described in the manual. I tell you what, someone who writes C code can do a lot of silent and destructive stuff. Let's protect users against this by making sure they can't use the C compiler. (And we must keep them away from perl, or the poor little simpletons will get into real trouble. And we had better disable ">", so let's set noglob and noclobber in everyone's .cshrc.) If you want a shell which tries to protect people from themselves, is verbose, and is widely liked, there are at least two implementations of DEC's DCL command language for UNIX. Or you could do what Sun are starting to do in SunOS 4.0, and give people mouse-oriented tools for deleting files &c. Giving people an easy way of deleting files by clicking on an icon makes thing safer for them without taking anything at all away. Emacs "DIRED" mode is the same kind of safety-through-convenience approach.
ok@quintus.uucp (Richard A. O'Keefe) (11/23/88)
In article <18164@shemp.CS.UCLA.EDU> kirkaas@cs.ucla.edu (paul kirkaas) writes: >I guess I'm a little disturbed at how easily we call others stupid >for using harmless practices which differ from our own. I didn't call _you_ stupid. I called your "harmless practice" stupid. If you are careful to confine your aliases to the C-shell, and always write your scripts in Bourn shell, and take care never to write shell functions that redefine standard commands, you're pretty safe. Of course new users would be well advised to stay away from you when they need help, because what they see on your screen won't match what they get, but that's no loss to you (I never said _you_ were stupid). Aliasing standard commands is like #define if while in C.
ok@quintus.uucp (Richard A. O'Keefe) (11/23/88)
In article <812@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: [about rm *] >What I did, a decade ago, was to have a list of _commands_ which the >shell, after calling glob, would always prompt for after printing out >the entire expanded command line. The list included "rm" and "rmdir". >No prompting if "glob" was not called. Nice one, but how does this handle user commands with similar properties? (For example, "a.rm".) One answer, of course, would be to have a GLOBASK=rm:rmdir shell variable, so that one could put GLOBASK=a.rm:$GLOBASK in ones .profile. (Did I just make a constructive suggestion? Oops.)
gandalf@csli.STANFORD.EDU (Juergen Wagner) (11/24/88)
In article <723@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >... >A very common practice may never-the-less be a bad idea. I agree 100%. >... >want to protect beginners from the dangerous commands, give them aliases >which flat-out refuse to do anything at all: > alias rm 'echo "Use \"delete\" to delete files; rm is dangerous."' That's a good idea, too. But it aliases "rm", so it no longer doesn what the manual says, ...and beware of shell scripts using this kind of rm. >... >The other effect is that the commands available to the beginner no longer >match the documentation; how anyone can perceive that as good is beyond me. Hmmm... I think, it's the other way round. Documentation should match the tools! >... >No, it is _not_ a bad example. If I "alias ls 'ls -F'", I am likely to >use it in a script which _relies_ on that behaviour. Then I give it to >someone else and it doesn't work. THIS KIND OF THING **HAPPENS**. >... People writing shell scripts must not rely on such thinks. If I am writing a safe shell script, I am either disallowing .cshrc to be read, or giving pull paths of the commands, or unalias'ing the commands before using them. People writing shell scripts should do that for the very reason to be compatible because some users may have weird aliases which are breaking code. >... > If you are using someone else's account, you haven't >ANY IDEA *AT ALL* what rm does until you have checked for aliases and >shell functions. Right! Before I am executing destructive operations, I am checking that. >... > I tell you what, someone who writes C code can >do a lot of silent and destructive stuff. Let's protect users against >this by making sure they can't use the C compiler. (And we must keep >them away from perl, or the poor little simpletons will get into real >trouble. And we had better disable ">", so let's set noglob and noclobber >in everyone's .cshrc.) "set noclobber" is a good idea but it will only work in csh, right? As for the guys writing C code to silently erase a user's files, I wouldn't say they are beginners, would you? Someone writing such code should know what he/she is doing. No operating system can be fool-proof without being trivial. >If you want a shell which tries to protect people from themselves, is >verbose, and is widely liked, there are at least two implementations >of DEC's DCL command language for UNIX. Widely liked? Humph! VMS isn't foolproof, either (although it would like to be). >Or you could do what Sun are starting to do in SunOS 4.0, and give people >mouse-oriented tools for deleting files &c. Giving people an easy way of >deleting files by clicking on an icon makes thing safer for them without >taking anything at all away. Emacs "DIRED" mode is the same kind of >safety-through-convenience approach. Coming closer! That's my idea of a user-friendly interface. An "undo" operation should be an essential part of the user interface... but that will remain utopical for most UNIX systems for the time being, I am afraid. (why not use a LISP machine :-) ). --- -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
charlie@mica.stat.washington.edu (Charlie Geyer) (11/24/88)
In article <2508@aplcomm.jhuapl.edu> trn@aplcomm.jhuapl.edu (Tony Nardo) writes: >In article <1067@entropy.ms.washington.edu> charlie@mica.stat.washington.edu >(Charlie Geyer) writes: >>This is all very easy. If you don't like rm(1) put >> >> alias foo rm -i >> >>in your .cshrc... > >A half-measure. If you *really* don't like rm(1), put > > alias rm "rm -i" > >in your .cshrc file. That way, if you want to use rm without the -i switch, >you have to do a little extra work (/bin/rm). By the same token, > > alias cp "cp -i" > >can protect you from yourself with file copying. Ah yes. Well actually I do have alias rm rm -i alias cp cp -i alias mv mv -i set noclobber in all of my .cshrc files. I just didn't want to *recommend* such a practice knowing I'd get flamed for it. Only once or twice have I forgotten with a new account that I haven't set these aliases *yet*. It is a bit of a pain embedding /bin/rm and /bin/mv in c-shell scripts I write. Can anyone tell me if this is nonportable? Don't tell me that if I would just write Bourne shell scripts that I wouldn't have to worry about the stupid alias. I know that. Also don't tell me the c-shell is nonportable.
alex@megadata.oz (Alex Danilo) (11/24/88)
In article <1067@entropy.ms.washington.edu>, charlie@mica.stat.washington.edu (Charlie Geyer) writes: > Creeping featurism considered harmful. Leave it alone. > This is all very easy. If you don't like rm(1) put > alias foo rm -i > in your .cshrc or put a shell script foo in ~/bin > rm -i $* > and use foo to remove files. > This solution (& lots of others proposed) are just bodges that novice users would learn about after the fateful 'rm * .o':-) They are also useless for people who choose to use 'sh' instead of 'csh'. A possibly better solution could be to destroy the utility 'rm' and make it a built-in command in 'sh', 'csh' & 'ksh' just as 'cd' is built-in. Whenever file(s) are removed using wildcards, the shell could simply relink the file(s) to another unique & (almost) invisible name (i.e. prefixed by '.') & maintain a linked list of original file names with associated hidden name. The next command executed by the user may be either an 'unrm' or another valid command. If 'unrm' was executed the files may simply be relinked & restored, no harm done. Any other command (valid command that is, not a typo) following the 'rm' can trigger the shell to unlink all the hidden file names & achieve the same result as an intentional 'rm'. Perhaps the number of commands that may be executed before an 'unrm' could be another environment variable. This system is idiot-proof & saves those late night typing mistake nightmares. The main drawback is the file space being used until the purge is actually done. Any shell source hackers think this will slow it too much? E PLURIBUS UNIX - alex@megadata.oz D D
maart@cs.vu.nl (Maarten Litmaath) (11/24/88)
In article <812@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes:
\What I did, a decade ago, was to have a list of _commands_ which the
\shell, after calling glob, would always prompt for after printing out
\the entire expanded command line. The list included "rm" and "rmdir".
It's quite unnecessary to include "rmdir".
--
fcntl(fd, F_SETFL, FNDELAY): |Maarten Litmaath @ VU Amsterdam:
let's go weepin' in the corner! |maart@cs.vu.nl, mcvax!botter!maartgreywolf@unisoft.UUCP (The Grey Wolf) (11/26/88)
In article <6550@csli.STANFORD.EDU> wagner@arisia.xerox.comP (Juergen Wagner) writes: >In article <723@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>... >>A very common practice may never-the-less be a bad idea. > >I agree 100%. > >>... >>want to protect beginners from the dangerous commands, give them aliases >>which flat-out refuse to do anything at all: >> alias rm 'echo "Use \"delete\" to delete files; rm is dangerous."' > > >>... >>No, it is _not_ a bad example. If I "alias ls 'ls -F'", I am likely to >>use it in a script which _relies_ on that behaviour. Then I give it to >>someone else and it doesn't work. THIS KIND OF THING **HAPPENS**. >>... > For one thing, csh aliases (which seems to be the format of the aliases you are describing) are NOT EXPORTED to shell scripts OF ANY SORT. 'ls' evaluates to whichever 'ls' is found first in your $PATH. If you're going to write a csh script, you're better off prefacing it with the line #! /bin/csh -f The reason I did that was because it saves on my startup time (it won't read .cshrc). All one *really* needs from one's environs to use a script is going to be things like $PATH, $TERM, $HOME, possiblye $USER, and maybe $LOGNAME if you're running under System V... Now, if you're writing ksh scripts or scripts under a shell which will support functions, and the user decides to export that function to their environment (which can be done, I understand), the script will have to re-define things like "ls" and "rm" to be what they should be, i.e., /bin/ls and /bin/rm (respectively :-). With respect to bad practice of re-defining what you want your commands to do, it's purely a matter of opinion and subject to debate. If I can, I redefine 'ls' to be '/bin/ls -A'. If I can't, then ls is obviously one of the braindamaged type that can't tell a file from a tty, and redefine it to be '/bin/ls -aC'. I'm just used to seeing things a certain way, and if they come out different, that's my problem. (ALWAYS type in /bin/rm from someone else's account! point taken: you never know WHAT they're gonna have set up...I run my own version of rm which follows the (evidently age-old) process of moving things to a .trash file...) /* VCC: "Hey, Wo[ol]f!" | WC: Roan Anderson UUCP: sun!unisoft!greywolf | First-name-pronounced: "RO-an" CORP: UniSoft Corporation | ATT: +1 415 420 6410 168 TFTD: "A malfunctioning machine is a sure sign of a flashing red light." */ -- ...TheysaidDoyouseethebiggreenglowinthedarkhouseuponthehill?andIsaidYesIseethebiggreenglowinthedarkhouseuponthehillTheresabigdarkforestbetweenmeandthebiggreenglowinthedarkhouseuponthehillandalittleoldladyonaHoovervacuumcleanersayingIllgetyoumyprettyandyourlittledogTototoo I don't even *HAVE* a dog Toto...
ok@quintus.uucp (Richard A. O'Keefe) (11/26/88)
In article <1077@entropy.ms.washington.edu> charlie@mica.stat.washington.edu (Charlie Geyer). writes: >It is a bit of a pain embedding /bin/rm and /bin/mv in c-shell >scripts I write. Can anyone tell me if this is nonportable? (1) If you want to avoid aliases, but don't mind picking things up out of the $path, you should know that quoting any part of a command will suppress alias lookup. Thus it suffices to write \rm, \mv, and so on. 'rm', "mv" will do as well. Better still is to use the "-f" option if you have it. (2) The SVID in section FILSYS(BA_ENV) says what the base of the directory tree should look like: / .../bin .../dev .../ect .../tmp .../usr ....../usr/bin ....../usr/tmp The ENVVAR(BA_ENV) section suggests PATH=/bin/usr/bin (sic!). If the SVID says where rm &co live, I can't find it, but assuming that cat, cp, ln, ls, mkdir, mv, rm, rmdir are in /bin should be ok. (It is _not_ portable to assume that "wc" is in /bin.)
ok@quintus.uucp (Richard A. O'Keefe) (11/27/88)
In article <1457@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >In article <6550@csli.STANFORD.EDU> wagner@arisia.xerox.comP (Juergen Wagner) writes: >>In article <723@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>>No, it is _not_ a bad example. If I "alias ls 'ls -F'", I am likely to >>>use it in a script which _relies_ on that behaviour. Then I give it to >>>someone else and it doesn't work. THIS KIND OF THING **HAPPENS**. >For one thing, csh aliases (which seems to be the format of the aliases >you are describing) are NOT EXPORTED to shell scripts OF ANY SORT. 'ls' >evaluates to whichever 'ls' is found first in your $PATH. I don't quite understand what "The Grey Wolf" means here. Unless you take steps to prevent it, the C shell *does* source .cshrc when it reads a script (that is, after all, what .cshrc is FOR), and that is where most people put aliases like that. (If you put your "rm", "ls", and suchlike aliases in .login, you're safe.) You can tell which aliases will affect C-shell scripts by doing % csh -c alias >If you're going to write a csh script, >you're better off prefacing it with the line >#!/bin/csh -f Indeed you are. You're even better off not writing Csh scripts. >With respect to bad practice of re-defining what you want your commands >to do, it's purely a matter of opinion and subject to debate. Well, everything is subject to debate. But "purely a matter of opinion" is an attitude of despair. We _can_ approach questions like this objectively. We simply have to measure which approach is less likely to lead to error. All it would take to determine whether (a) redefining rm to be something LIKE rm but different, or (b) adding a new command and deleting rm, or (c) adding a new command and leaving rm alone, or (d) doing nothing would be better is an experiment which would take a couple of months, a few dozen people, and money. Pending such a study (anyone want to fund me to do it?) we can analyse the matter logically. Of the four approaches, (a), (c), and (d) all permit disastrous mistakes.
achar@atari.UUCP (Alan Char) (11/29/88)
In article <727@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: |In article <812@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: |[about rm *] ||What I did, a decade ago, was to have a list of _commands_ which the ||shell, after calling glob, would always prompt for after printing out ||the entire expanded command line. The list included "rm" and "rmdir". ||No prompting if "glob" was not called. | |Nice one, but how does this handle user commands with similar properties? |(For example, "a.rm".) |One answer, of course, would be to have a | GLOBASK=rm:rmdir |shell variable, so that one could put | GLOBASK=a.rm:$GLOBASK |in ones .profile. (Did I just make a constructive suggestion? Oops.) GLOBASK is not that different from expandcheck. In fact, setting GLOBASK=<all commands> is exactly the same as setting expandcheck=1 modulo the prompt text. You mean there isn't some value I can use for GLOBASK to ask for all commands? Oh. --Alan Char
jr@ncrsecp.Copenhagen.NCR.dk (Jakob Riis) (11/29/88)
In article <711@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <1670@ski.cs.vu.nl> biep@cs.vu.nl (J A Biep Durieux) writes: >>At the very least, 'rm * .o' should refuse to do anything when the file '.o' >>doesn't exist. > >I have posted a "del" command to comp.sources.unix which does this. EXACTLY !! Make new commands, don't mess around with the old ones. I agree that users need to be protected: Give them safer commands, Menu shells or PullDown help screens, nurse them good, but don't take away the alertness to the real thing - Unix is fast and dangerous, real progreammers reread their "rm" statements twice !! Don't let users expect that "rm -r *" will help them trim their filesystem by asking them to confirm each file. Teach a user that, and watch his face running on another system one day !! B.T.W: Think of the portability - 100.000+ shell scripts that needs to be rewritten. We have enough trouble with differences between BSD and V, Csh, Bsh, Ksh etc. as it is. (Just my 2 cents opinion) Jakob Riis ___________________________________ NCR Systems Engineering Copenhagen | | | " If Batman is so damned clever, | jr@ncrsecp.Copenhagen.NCR.com | why is he wearing his undershorts | or | outside his trousers ? " | ....mcvax!enea!dkuug!ncrsecp!jr | -Danish graffitti | |___________________________________|
ok@quintus.uucp (Richard A. O'Keefe) (11/30/88)
In article <1248@atari.UUCP> achar@atari.UUCP (Alan Char) writes: >In article <727@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >|One answer, of course, would be to have a >| GLOBASK=rm:rmdir >|shell variable, so that one could put >| GLOBASK=a.rm:$GLOBASK >|in ones .profile. (Did I just make a constructive suggestion? Oops.) > >GLOBASK is not that different from expandcheck. In fact, >setting GLOBASK=<all commands> is exactly the same as setting >expandcheck=1 modulo the prompt text. No it isn't, because it is not *possible* to set GLOBASK=<all commands>. That's an open set. (The set of commands accessible through my $PATH at the moment is 661, and that's after I pruned my $PATH.) It's also quite a different perspective; it's quite pointless to limit echo * | wc -w which expandcheck would do, whereas the GLOBASK approach explicitly identifies only the believed-dangerous commands. I am not seriously proposing GLOBASK; just pointing out that more focussed approaches than expandcheck are possible.
jc@minya.UUCP (John Chambers) (12/06/88)
> >Or you could do what Sun are starting to do in SunOS 4.0, and give people > >mouse-oriented tools for deleting files &c. Giving people an easy way of > >deleting files by clicking on an icon makes thing safer for them without > >taking anything at all away. Emacs "DIRED" mode is the same kind of > >safety-through-convenience approach. > > Coming closer! That's my idea of a user-friendly interface. An "undo" > operation should be an essential part of the user interface... but that > will remain utopical for most UNIX systems for the time being, I am afraid. > (why not use a LISP machine :-) ). > Oh, I don't know about that; I recall 'way back when I first stumbled across Unix, after having worked on N other commercial systems. When I found that the rm command just did what I told it and didn't complain, my reaction was "Wow, this is really a nice, friendly system!" But in the years since then, Unix has gotten less and less friendly to me, because people think I'm too stupid to think before hitting <RETURN>, and they add "features" such as checks to rm. So now I find myself doing things like: rm aud/* ^C rm -f aud/* while thinking many unprintable thoughts about the @#$^% idiots who would do such a thing and cause me to waste my time with such silliness. The real solution is: People who can't handle commands like rm shouldn't have /bin in their search path. Even better, vendors should supply them with tools like mice and menus, and not bother holding the hands of those users that like simple, direct, powerful tools. Unix has a perfectly good mechanism for providing different users with different interfaces. Why not use it? [No, I've never typed "rm * .o", or at least I've never hit <RETURN> after such a typo. My right little finger tends to delay automatically when it knows I've typed a possibly dangerous command, to give my brain time to think about it.] -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/11/88)
In article <145@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >The real solution is: People who can't handle commands like rm shouldn't >have /bin in their search path. Even better, vendors should supply them >with tools like mice and menus, and not bother holding the hands of those >users that like simple, direct, powerful tools. Exactly right! There are different classes of "users"; what is "friendly" for one may be downright hostile for another. The UNIX shell user interface was designed by good programmers for use by good programmers. Although others can use it, they should be aware that it requires more thought and study than a Macintosh-like interface. Let's not ruin the programmer interface in a (necessarily futile) attempt to make it "nice" for people who need their hands held. Along these lines, does anybody know what on earth has possessed the IEEE 1003.2 working group? They seem to be redesigning the standard utilities, in almost every case making them worse instead of better. They even had to debate whether "ar" should be usable with non-object module files! (The latest minutes show that the -r option has been removed from "ar"; I sure hope that's not true!) Somehow I missed getting into the ballotting group for 1003.2, but I sure hope that there are enough proponents of clean design to keep the current mess from becoming a standard that will adversely affect the systems we have to use in the future. I still think that the minimal subset of program/script-useful utilities and subset options I extracted from the SVID early in 1003.2's history would be much better for standardization than a large, messy set of features.