home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / shell / 3734 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  3.1 KB
  1. Xref: sparky comp.unix.shell:3734 comp.unix.questions:10610
  2. Path: sparky!uunet!infoserv!steiny!root
  3. From: root@steiny.com (Admin)
  4. Newsgroups: comp.unix.shell,comp.unix.questions
  5. Subject: Re: Shell Scripts vs. C programs
  6. Keywords: shell script, C
  7. Message-ID: <121@steiny.com>
  8. Date: 1 Sep 92 15:21:43 GMT
  9. References: <1992Aug31.211738.1909@tjhsst.vak12ed.edu> <119@steiny.com> <1992Sep1.044434.7193@news.acns.nwu.edu>
  10. Organization: Don Steiny Software
  11. Lines: 65
  12.  
  13. navarra@casbah.acns.nwu.edu (John Navarra) writes:
  14.  
  15. >In article <119@steiny.com> steiny@steiny.com (Don Steiny) writes:
  16. >>nurban@tjhsst writes:
  17. >>
  18. >>
  19. >>>I've heard that if at all possible, code a program as a shell script
  20. >>>rather than coding it in C.  Can someone explain the rationale behind
  21. >>>this philosophy?
  22. >>
  23. >>    BZZZ - shell scripts are non-portable
  24. >>
  25. >    Huh? Why are shell scripts non-portable? Unless you are using
  26. >a non-standard shell, shell scripts are HIGHLY portable! 
  27.  
  28.     The shell may be, but the utilities that the shell calls in order
  29. to operate are not, thus, shell scripts are non-portable.   Believe me,
  30. I had to write a distribution package for software that runs on many machines.
  31. I eventually had to re-write it in C because the shell was so non-portable.
  32. Many other posters to this thread have also had this experience.   The
  33. only reason that you think that is because you have not had much experience
  34. trying to port shell scripts.
  35.  
  36. >> there is no error checking,
  37.  
  38. >    There isn't? What does this mean? You write error checking
  39. >into the shell program just like you write it into C program. 
  40.  
  41.     If you accidently misspell a variable name, then the shell simply
  42. takes it as a decleration.     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. >>and they have many other problems.
  47. >    And translating your C code using compiler X to OS Y is any
  48. >easier? Perhaps you are thinking of Csh? Then, yeah, you suck. 
  49.  
  50.     Are you saying that the shell runs in more environments than 
  51. C compilers?
  52.  
  53. >>For very short programs shell 
  54. >>might be better, but in general C is better for many reasons.
  55.  
  56. >    Even for long programs, shell scripts can be better. Yes, they
  57. >will run slower but if you can saves days, weeks, or months writing
  58. >the shell script, which is better then? 
  59.  
  60.     Why would that be, if you did not know C?    Why not use perl?  It
  61. is supported on more machines than the shell, it has error checking, it
  62. is portable, and it so much better than the shell it boggles the mind.
  63.  
  64.  
  65. > It generally takes much longer
  66. >to write the same code in C as it does in a shell, perl, or awk. And,
  67. >once you have that script written, it is generally trivial to port it
  68. >to another machine -- especially if that machine runs the SAME SHELL!
  69.  
  70.     And has the exact same semantics for all of the commands. In other 
  71. words, you are not trying to port a shell script from AT&T to BSD.   
  72.  
  73.     Besides, if you really know C it is as fast to write many things 
  74. as the shell.   For text processing, use perl.   The shell stinks as 
  75. a programming language for anything but short interactive programs.
  76.  
  77. -don
  78.