home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / shell / 3744 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  4.3 KB
  1. Xref: sparky comp.unix.shell:3744 comp.unix.questions:10622
  2. Newsgroups: comp.unix.shell,comp.unix.questions
  3. Path: sparky!uunet!sun-barr!ames!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!casbah.acns.nwu.edu!navarra
  4. From: navarra@casbah.acns.nwu.edu (John Navarra)
  5. Subject: Re: Shell Scripts vs. C programs
  6. Message-ID: <1992Sep1.211515.24741@news.acns.nwu.edu>
  7. Keywords: shell script, C
  8. Sender: usenet@news.acns.nwu.edu (Usenet on news.acns)
  9. Organization: Northwestern University, Evanston Illinois.
  10. References: <119@steiny.com> <1992Sep1.044434.7193@news.acns.nwu.edu> <121@steiny.com>
  11. Date: Tue, 1 Sep 1992 21:15:15 GMT
  12. Lines: 75
  13.  
  14. In article <121@steiny.com> root@steiny.com (Admin) writes:
  15. >    The shell may be, but the utilities that the shell calls in order
  16. >to operate are not, thus, shell scripts are non-portable.   Believe me,
  17. >I had to write a distribution package for software that runs on many machines.
  18. >I eventually had to re-write it in C because the shell was so non-portable.
  19. >Many other posters to this thread have also had this experience.   The
  20. >only reason that you think that is because you have not had much experience
  21. >trying to port shell scripts.
  22.  
  23.     Admittedly, I have not had much experience porting complex shell
  24. scripts across many different architectures. I somewhat agree
  25. with you in that I wouldn't write really large shell, complex shell scripts
  26. which would need to be ported to many different architectures -- not
  27. because I would fear the shell is SO non-portable but that the script 
  28. most likely would run pretty slow. 
  29.  
  30. >
  31. >>>and they have many other problems.
  32. >>    And translating your C code using compiler X to OS Y is any
  33. >>easier? Perhaps you are thinking of Csh? Then, yeah, you suck. 
  34. >
  35. >    Are you saying that the shell runs in more environments than 
  36. >C compilers?
  37.  
  38.     No, I am saying that if you take into account various C compilers
  39. and various OS's which your C program may have to ported to, you,
  40. especially as a new user, would have MUCHO difficulty accounting for all
  41. this. However, if you write the same code in a shell script, you can
  42. be reasonably sure the code will work across many architectures. The
  43. person who asked this question asked it from a new user standpoint. I 
  44. certainly would not suggest to a new user that he NEVER write large
  45. shell scripts out of fear of non-portability. 
  46.  
  47. >>    Even for long programs, shell scripts can be better. Yes, they
  48. >>will run slower but if you can saves days, weeks, or months writing
  49. >>the shell script, which is better then? 
  50. >
  51. >    Why would that be, if you did not know C?    Why not use perl?  It
  52. >is supported on more machines than the shell, it has error checking, it
  53. >is portable, and it so much better than the shell it boggles the mind.
  54.  
  55. You don't need to convince me that perl is a great alternative. However,
  56. it simply is not used by as many people who use shell scripts and
  57. C programs. I find the for simple to moderate tasks, programming in 
  58. the shell is a bit easier than programming in perl. And, if I want to
  59. let someone use my script, I can be sure it will be of use to them since
  60. it is written in sh. I cannot be gauranteed that person has perl (or
  61. wants perl). I also find that programming the shell is MUCH easier than
  62. programming in C (even with the better error checking in C). If I am
  63. not ultimately concerned about execution time, the few seconds I save
  64. with C is not worth the hassle of spending two, three, four times
  65. the time to write it. 
  66.  
  67. >    And has the exact same semantics for all of the commands. In other 
  68. >words, you are not trying to port a shell script from AT&T to BSD.   
  69.  
  70.     Hopefully, as things progress, this difference will be reconciled
  71. and a POSIX standard will prevail. Then, I don't think you will have to
  72. worry much about that. 
  73.  
  74. >    Besides, if you really know C it is as fast to write many things 
  75. >as the shell.   For text processing, use perl.   The shell stinks as 
  76. >a programming language for anything but short interactive programs.
  77. >
  78.     I think that I basically argee with you , but you are much harder
  79. on the shell as a programming language than I.
  80.  
  81. -tms
  82.  
  83.  
  84. -- 
  85. You can get further with a kind word | You can get further with a kind word
  86. and a gun than a kind word alone.    | and a phaser than a kind word and a gun.
  87.           --al capone                |           -- John Navarra
  88. =======From the Lab of the MaD ScIenTIst....navarra@casbah.acns.nwu.edu========
  89.