home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / question / 15019 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  4.7 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!gatech!usenet.ins.cwru.edu!odin!chet
  2. From: chet@odin.ins.cwru.edu (Chet Ramey)
  3. Newsgroups: comp.unix.questions
  4. Subject: Re: The Revenge of CSH
  5. Message-ID: <1hpso1INNp6q@usenet.INS.CWRU.Edu>
  6. Date: 29 Dec 92 16:01:04 GMT
  7. References: <Bzz748.GDK@csn.org>
  8. Organization: Case Western Reserve University, Cleveland OH (USA)
  9. Lines: 116
  10. NNTP-Posting-Host: odin.ins.cwru.edu
  11.  
  12. In article <Bzz748.GDK@csn.org> bazyar@teal.csn.org (Jawaid Bazyar) writes:
  13.  
  14. >  I am continually shocked and dismayed to see people not have
  15. >command line editing, arrow-key history, job control, or many
  16. >of the other things that csh (tcsh) provides and /bin/sh does not.
  17.  
  18. As others have stated, these are all interactive features, not the
  19. script features about which Tom is complaining.
  20.  
  21. >  Possibilities that could be added to csh, if anyone cared to.
  22.  
  23. ...and once they were, until they were standard and ubiquitous, they
  24. would be useless.  Ditto for `read', `fixing' redirections, `fixing'
  25. piping to and from csh builtins, the equivalent to $!, `fixing' the
  26. lexical analyzer, and other things mentioned.
  27.  
  28. [...]
  29. >  Hmm.  Too bad that's unreadable! :)
  30.  
  31. ``The easy things should be easy; the hard things should be possible.''
  32. At least this stuff is possible in sh.  The csh model is too confining.
  33. I think this is the crux of Tom's argument.
  34.  
  35. >  "on some systems" means that there's a bug in csh on some systems,
  36. >not that csh is devil-spawn.
  37.  
  38. `On some systems' means, in this case, every job-control capable Unix
  39. system with csh, since few vendors have fixed these things.  They are
  40. part of what you have to consider when dealing with csh.
  41.  
  42. >  ^^^^  He devotes a whole section to implementation errors.  These
  43. >are _bugs_, i.e. they could be fixed or avoided in a new implementation
  44. >(like GSH).
  45.  
  46. ...and until the `new' implementation is standard and ubiquitous, it's
  47. useless when considering `portable' csh scripts.  Same thing with sh
  48. and shell functions, since BSD and Ultrix shells don't support them
  49. yet. (Well, the BSD sh as of 4.3-net2 does, but it has its own set of
  50. problems).  Larry Wall, who wrote more twisted sh code than anyone
  51. (before perl, that is :-), says he's never written a shell function for
  52. just this reason.
  53.  
  54. >  Too bad the Bourne shell doesn't support real BSD job control.
  55.  
  56. This is a result of, for the most part, the fact that AT&T kernels did
  57. not support job control, and there was therefore no reason to add it to
  58. sh.  The sh shipped with V.4 supports Posix job control, now that the
  59. proper kernel support is there.  The new BSD sh supports job control.
  60. (Hey, bash supports job control :-).
  61.  
  62. The csh doesn't give you job control in scripts, anyway.  We're talking
  63. about shell programming here.
  64.  
  65. >> You can't quote things reasonably in the csh:
  66. > 
  67. >>     set foo = "Bill asked, \"How's tricks?\""
  68. > 
  69. >> doesn't work.  This makes it really hard to construct strings with
  70. >> mixed quotes in them.  In the Bourne shell, this works just fine. 
  71. >> In fact, so does this:
  72. >> 
  73. >>      cd /mnt; /usr/ucb/finger -m -s `ls \`u\``
  74. >> 
  75. >> Dollar signs cannot be escaped in double quotes in the csh.  Ug.
  76. >> 
  77. >>     set foo = "this is a \$dollar quoted and this is $HOME not quoted" 
  78. >>     dollar: Undefined variable.
  79. >
  80. >  Another bug.
  81.  
  82. Which?  The `dollar signs cannot be escaped in double quotes' problem, or
  83. the hoops one must jump through to quote things reasonably?  It seems to me
  84. that the entire csh quoting model is flawed because it is not sufficiently
  85. flexible.  Perhaps you consider this an implementation problem. 
  86.  
  87. >> Say what?  You don't have these problems in the Bourne shell, where it's
  88. >> just fine to write things like this:
  89. >>     echo     'This is 
  90. >>          some text that contains
  91. >>          several newlines.'
  92. > 
  93. >  So what?
  94.  
  95. You don't consider this useful?  Or do you consider it trivial?
  96.  
  97. >> It's really nice to be able to say
  98. >>     
  99. >>     ${PAGER-more}
  100. >> or
  101. >>     FOO=${BAR:-${BAZ}}
  102. >> 
  103. >> to be able to run the user's PAGER if set, and more otherwise.
  104. >> You can't do this in the csh.  It takes more verbiage.
  105. >
  106. >  Excuse me?  "You can't do this" and "It takes more verbiage" means
  107. >IT CAN BE DONE.  
  108.  
  109. The sh syntax is more compact and powerful.  It takes a number of csh
  110. if statements to perform the same task.  You cannot do it in a single
  111. statement the way sh can.  I believe that this was Tom's point.
  112.  
  113. >   You're not cool enough to quote Doug Gwyn.  Really; it seems that
  114. >'csh sucks' in your opinion because it's not /bin/sh.  Care to try 
  115. >again?
  116.  
  117. Oh, I don't know.  Tom's a pretty cool guy.  I prefer to quote Chris
  118. Torek, myself:
  119.  
  120. ``The C shell is an object lesson in how not to write programs.''
  121.  
  122. Chet
  123. -- 
  124. ``The use of history as therapy means the corruption of history as history.''
  125.     -- Arthur Schlesinger
  126.  
  127. Chet Ramey, Case Western Reserve University    Internet: chet@po.CWRU.Edu
  128.