home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / shell / 3735 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  3.4 KB
  1. Xref: sparky comp.unix.shell:3735 comp.unix.questions:10611
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!news.u.washington.edu!carson.u.washington.edu!donn
  3. From: donn@carson.u.washington.edu (Donn Cave)
  4. Newsgroups: comp.unix.shell,comp.unix.questions
  5. Subject: Re: Shell Scripts vs. C programs
  6. Keywords: shell script, C
  7. Message-ID: <1992Sep1.173604.15563@u.washington.edu>
  8. Date: 1 Sep 92 17:36:04 GMT
  9. Article-I.D.: u.1992Sep1.173604.15563
  10. References: <1992Aug31.211738.1909@tjhsst.vak12ed.edu> <119@steiny.com> <1992Sep1.044434.7193@news.acns.nwu.edu> <121@steiny.com>
  11. Sender: news@u.washington.edu (USENET News System)
  12. Organization: University of Washington
  13. Lines: 55
  14.  
  15. root@steiny.com (Admin) writes:
  16.  
  17. |navarra@casbah.acns.nwu.edu (John Navarra) writes:
  18.  
  19. |>In article <119@steiny.com> steiny@steiny.com (Don Steiny) writes:
  20. |>|nurban@tjhsst writes:
  21. |>|
  22. |>|
  23. |>|>I've heard that if at all possible, code a program as a shell script
  24. |>|>rather than coding it in C.  Can someone explain the rationale behind
  25. |>|>this philosophy?
  26. |>|
  27. |>|    BZZZ - shell scripts are non-portable
  28. |>|
  29. |>    Huh? Why are shell scripts non-portable? Unless you are using
  30. |>a non-standard shell, shell scripts are HIGHLY portable! 
  31.  
  32. |     The shell may be, but the utilities that the shell calls in order
  33. | to operate are not, thus, shell scripts are non-portable.
  34.  
  35. Actually, the shell may be about as bad as the utilities, if by utilities
  36. you mean things like sed and awk.  These will be slightly different, but
  37. the discrepancies between System V and BSD shells can be quite a pain,
  38. especially when you have to clean up after someone who didn't know about
  39. them.  C is very portable, by comparison.
  40.  
  41. |     If you accidently misspell a variable name, then the shell simply
  42. | takes it as a declaration.     In the 14 years I have been working 
  43. | professionally with UNIX I have witnessed numerous attempts to write
  44. | substantial applications in the shell and they have all failed.
  45.  
  46. I have wondered if it would be possible to develop a reasonably usable shell
  47. language that would have "software engineering" features for writing large
  48. systems.  For me, that would mean some level of typing, structured types,
  49. functional scoping, and some way to deal with code in separate modules,
  50. but I'm sure there's more to it if one were to consult some standard texts
  51. on this issue.  Would be nice to be able to create somewhat complex data
  52. types, e.g., trees, and store "pointers" to functions, but not necessarily
  53. the way C does it, maybe more like Lisp.  It would of course need to be
  54. able to run fairly efficient code.  Seriously, it would also want to have
  55. a little style, rather than being a grab-bag amalgam of every known
  56. programming language, which can impair readability.  (Tom, I'm not hostile
  57. to perl, so don't be bashful about saying perl has all of these things and
  58. more, but jeez it looks messy.)  My rather simplistic attitude is that good
  59. code can be fiddled with in one place, without unanticipatable side effects
  60. in other places.
  61.  
  62. If there's any advantage to such a thing, over C, it would be the sort of
  63. padded environment that allows programs to be written fairly quickly without
  64. worrying about dereferencing null pointers and things like that.  Ideally,
  65. it would also be possible to convert straight to C without much re-design,
  66. so it could be used for prototyping.
  67.  
  68.     Donn Cave, University Computing Services, University of Washington
  69.     donn@cac.washington.edu
  70.