home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / misc / 4099 < prev    next >
Encoding:
Text File  |  1992-11-11  |  3.3 KB  |  64 lines
  1. Newsgroups: comp.unix.misc
  2. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!mudos!mju
  3. From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
  4. Subject: Re: The Problem with UNIX
  5. Message-ID: <BxJx49.MBo@mudos.ann-arbor.mi.us>
  6. Date: Wed, 11 Nov 1992 12:24:08 GMT
  7. References: <17310@mindlink.bc.ca>
  8. Organization: The Programmer's Pit Stop, Ann Arbor MI
  9. Lines: 53
  10.  
  11. In article <17310@mindlink.bc.ca> Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg) writes:
  12. >and programs, the touchiness of such things as "mv * x" versus "mv *x"
  13. >ought to give most people pause. And how many of you experienced Unix users,
  14. >as SOME point, have aliased rm to "/bin/rm -i" --- probably just after
  15. >deleting a week's worth of source code?
  16.  
  17. Hmm.  This example of "one misplaced space can destroy your command"
  18. keeps coming up over and over again, but I've never actually seen it
  19. happen.  Sure, if you put a space where it doesn't belong, Something
  20. Bad might happen.  Then again, if you type "rm $MAIL" instead of "frm
  21. $MAIL" (this one is even easier to do, since all you have to do is
  22. leave out a single character), you'll blow away your mailbox instead
  23. of getting a summarized listing of it.  So what?  If you click on
  24. "Delete" instead of "Open" you'll blow away your file, too.
  25.  
  26. I've never aliased "rm" to "rm -i", and despise people who do.  The
  27. few times I've accidentally blown away a file, it was never by
  28. accidentally rm'ing it; no, it was much more creative than that.  (One
  29. specific example: Once, as root, I typed "crontab news" instead of
  30. "crontab -l news" while in /var/spool/cron/crontabs.  Of course, the
  31. crontab command took this to mean "replace the current user's crontab
  32. file with the contents of the `news' file", and so I overwrote root's
  33. crontab with news's.  This is probably a better example for "know what
  34. you're doing when you're root" than for "the Unix CLI is obtuse".)
  35.  
  36. >a la VAX/VMS or CMS. And an environment that allows classes and
  37. >subclasses can provide the same interactive flex as the shell
  38. >(well, the Korn shell or better) while adding a layer of "do what I
  39. >want, since it's obvious" to such cases as "mail xyz <a.out".
  40.  
  41. Uh, right.  Please see the definition of {DWIM} in the Jargon file.
  42.  
  43. >(sockets bound to names, streams, devices). But even more common
  44. >is the "typed" nature of text files. We kludge around with file suffixes
  45. >as identification to other humans; and we kludge around even more
  46. >with magic numbers, /etc/magic and "file" to make guesses as to
  47. >what a file is good for. How about the "ls" command that checks
  48. >whether stdout is a device or a file, and behave differently
  49. >in either case? Give me a break!
  50.  
  51. Typed files also have problems.  I'm no Mac expert, but I fondly
  52. remember the problems I had trying to convince the Finder to run a
  53. file that I had just downloaded.  I still don't remember exactly how I
  54. fixed it, but I know it wasn't as easy or obvious as "chmod +x file".
  55. And do you really want to be told, "Sorry, you can't edit an
  56. executable" by your editor?  If I typed "emacs /bin/ls", I probably
  57. meant it...
  58.  
  59. -- 
  60. Marc Unangst, N8VRH         | "There are two ways to solve this problem:
  61. mju@mudos.ann-arbor.mi.us   | the hard way, and the easy way.  Let's start
  62.                             | with the hard way."
  63.                             |   - W. Scheider, from a Physics lecture
  64.