home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / shell / 3107 < prev    next >
Encoding:
Text File  |  1992-07-23  |  2.8 KB  |  78 lines
  1. Newsgroups: comp.unix.shell
  2. Path: sparky!uunet!ftpbox!motsrd!white!sapphire.rtsg.mot.com!beryl17!yeates
  3. From: yeates@rtsg.mot.com (Tony J Yeates)
  4. Subject: Re: tcsh in the future - what should it be like?
  5. Message-ID: <yeates.711915328@beryl17>
  6. Keywords: tcsh
  7. Sender: news@rtsg.mot.com
  8. Nntp-Posting-Host: beryl17
  9. Organization: Motorola Inc., Cellular Infrastructure Group
  10. References: <yeates.711122638@beryl17> <1992Jul14.224856.7768@news.eng.convex.com>
  11. Distribution: comp.unix.shell
  12. Date: Thu, 23 Jul 1992 18:15:28 GMT
  13. Lines: 63
  14.  
  15. Tom Christiansen <tchrist@convex.COM> writes:
  16.  
  17. >From the keyboard of yeates@rtsg.mot.com (Tony J Yeates):
  18. >:    $(command)    -  `command` (speed)
  19.  
  20. >Not so much speed, I think, as to clean up the quoting rules and 
  21. >make nesting possible.
  22.  
  23. I hesitate before putting that in.  The Korn book does talk
  24. only about the simplified quoting, but a ksh "guru" friend,
  25. who is apparently in regular contact with Mr. Korn told
  26. me that there was a speed advantage  (or may be it was
  27. just $(< )?.  Simplified quoting is one of the  main reasons
  28. that I prefer to write scripts in ksh (despite being a tcsh user).
  29.  
  30.  
  31. >:    $(variablename##pattern)
  32. >:    $(variablename#pattern)    - cut specified short/long pattern off of start/end of variable
  33. >:    $(variable%%pattern)                        (versatile, fast)
  34. >:    $(variable%pattern)
  35.  
  36. >What's wrong with $var:s/foo/bar/, except that it doesn't deal with regexps?
  37.  
  38. Regular expressions (actually, are these  true regular expressions, 
  39. the normal UNIX regexp rules are not strictly used it seems?)
  40. is the main use of the pattern matching stuff, in my experience.
  41. (Other related csh stuff include the head, tail, etc. operators
  42. that work on paths).
  43.  
  44. >    set bar = $foo:s/d$//:q
  45.  
  46. Hadn't seen that before.
  47.  
  48. >Also: currently :s only works with history, not straight variables.
  49.  
  50.  
  51. >:    print    - built in replacement for echo (speed, more versatile, more intuitive name?)
  52.  
  53. >And to grok \escapes, which have no business in echo.
  54.  
  55. Sorry, don't understand your banter old bean.
  56.  
  57. >:More commonality with ksh would be an improvement I think (e.g. use the same symbols
  58. >:shown above, rather than creating new ones, just for the sake of it).
  59. >:
  60. >:2) Leave the command line editing alone - its better thank ksh
  61.  
  62. >Well, last I checked (not 6.0+) the vi mode in ksh was better than tcsh.
  63.  
  64. Although I'm a vi user, I always use the emacs-editing mode to
  65. tcsh - its simple, intuitive and quick.  I don't like ksh's
  66. vi mode either.
  67.  
  68. >Frankly, I think it's hopeless trying to salvage the csh for programming
  69. >use.  I do still prefer tcsh's interactivity to ksh's, however.
  70.  
  71. I'm not trying to revive csh for scripting, but as it is still used
  72. - I'd like to see it "fully functional" and as compatible/similar
  73. to ksh as possible.  I fully concur with your last statement - tcsh
  74. is, when configured "correctly", is hard to beat as an interactive shell.
  75. I'm very please with it.
  76. >--tom
  77.  
  78.