home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 4 / DATAFILE_PDCD4.iso / unix / riscbsd / 1_1_contri / usd / 01_begin / u4 < prev    next >
Encoding:
Text File  |  1986-06-03  |  7.0 KB  |  294 lines

  1. .\"    @(#)u4    6.1 (Berkeley) 6/2/86
  2. .\"
  3. .SH
  4. IV.  PROGRAMMING
  5. .PP
  6. There will be no attempt made to teach any of
  7. the programming languages available
  8. but a few words of advice are in order.
  9. One of the reasons why the
  10. .UC UNIX
  11. system is a productive programming environment
  12. is that there is already a rich set of tools available,
  13. and facilities like pipes, I/O redirection,
  14. and the capabilities of the shell
  15. often make it possible to do a job
  16. by pasting together programs that already exist
  17. instead of writing from scratch.
  18. .SH
  19. The Shell
  20. .PP
  21. The pipe mechanism lets you fabricate quite complicated operations
  22. out of spare parts that already exist.
  23. For example,
  24. the first draft of the
  25. .UL  spell 
  26. program was (roughly)
  27. .P1
  28. .ta .6i 1.2i
  29. cat ...    \f2collect the files\f3
  30. | tr ...    \f2put each word on a new line\f3
  31. | tr ...    \f2delete punctuation, etc.\f3
  32. | sort    \f2into dictionary order\f3
  33. | uniq    \f2discard duplicates\f3
  34. | comm    \f2print words in text\f3
  35.     \f2  but not in dictionary\f3
  36. .P2
  37. More pieces have been added subsequently,
  38. but this goes a long way
  39. for such a small effort.
  40. .PP
  41. The editor can be made to do things that would normally
  42. require special programs on other systems.
  43. For example, to list the first and last lines of each of a
  44. set of files, such as a book,
  45. you could laboriously type
  46. .P1
  47. ed
  48. e chap1.1
  49. 1p
  50. $p
  51. e chap1.2
  52. 1p
  53. $p
  54. .ft R
  55. etc.
  56. .P2
  57. But you can do the job much more easily.
  58. One way is to type
  59. .P1
  60. ls chap* >temp
  61. .P2
  62. to get the list of filenames into a file.
  63. Then edit this file to make the necessary
  64. series of editing commands
  65. (using the global commands of
  66. .UL ed ),
  67. and write it into
  68. .UL script .
  69. Now the command
  70. .P1
  71. ed <script
  72. .P2
  73. will produce
  74. the same output as the laborious hand typing.
  75. Alternately
  76. (and more easily),
  77. you can use the fact that the shell will perform loops,
  78. repeating a set of commands over and over again
  79. for a set of arguments:
  80. .P1
  81. for i in chap*
  82. do
  83.     ed $i <script
  84. done
  85. .P2
  86. This sets the shell variable
  87. .UL i
  88. to each file name in turn,
  89. then does the command.
  90. You can type this command at the terminal,
  91. or put it in a file for later execution.
  92. .SH
  93. Programming the Shell
  94. .PP
  95. An option often overlooked by newcomers
  96. is that the shell is itself a programming language,
  97. with variables,
  98. control flow
  99. .UL if-else , (
  100. .UL while ,
  101. .UL for ,
  102. .UL case ),
  103. subroutines,
  104. and interrupt handling.
  105. Since
  106. there are
  107. many building-block programs,
  108. you can sometimes avoid writing a new program
  109. merely by piecing together some of the building blocks
  110. with shell command files.
  111. .PP
  112. We will not go into any details here;
  113. examples and rules can be found in
  114. .ul
  115. An Introduction to the
  116. .ul
  117. .UC UNIX
  118. .IT Shell ,
  119. by S. R. Bourne.
  120. .SH
  121. Programming in C
  122. .PP
  123. If you are undertaking anything substantial,
  124. C is the only reasonable choice of programming language:
  125. everything in
  126. the
  127. .UC UNIX
  128. system
  129. is tuned to it.
  130. The
  131. system
  132. itself
  133. is written in C,
  134. as are most of the programs that run on it.
  135. It is also a easy language to use
  136. once you get started.
  137. C is introduced and fully described in
  138. .ul
  139. The C Programming Language
  140. by
  141. B. W. Kernighan and D. M. Ritchie
  142. (Prentice-Hall, 1978).
  143. Several sections of the manual
  144. describe the system interfaces, that is,
  145. how you do I/O
  146. and similar functions.
  147. Read
  148. .ul
  149. UNIX Programming
  150. for more complicated things.
  151. .PP
  152. Most input and output in C is best handled with the 
  153. standard I/O library,
  154. which provides a set of I/O functions
  155. that exist in compatible form on most machines
  156. that have C compilers.
  157. In general, it's wisest to confine the system interactions
  158. in a program to the facilities provided by this library.
  159. .PP
  160. C programs that don't depend too much on special features of 
  161. .UC UNIX
  162. (such as pipes)
  163. can be moved to other computers that have C compilers.
  164. The list of such machines grows daily;
  165. in addition to the original
  166. .UC PDP -11,
  167. it currently includes
  168. at least
  169. Honeywell 6000,
  170. IBM 370 and PC families,
  171. Interdata 8/32,
  172. Data General Nova and Eclipse,
  173. HP 2100,
  174. Harris /7,
  175. Motorola 68000 family (including machines like Sun Microsystems and
  176. Apple Macintosh),
  177. VAX 11 family,
  178. SEL 86,
  179. and
  180. Zilog Z80.
  181. Calls to the standard I/O library will work on all of these machines.
  182. .PP
  183. There are a number of supporting programs that go with C.
  184. .UL lint
  185. checks C programs for potential portability problems,
  186. and detects errors such as mismatched argument types
  187. and uninitialized variables.
  188. .PP
  189. For larger programs
  190. (anything whose source is on more than one file)
  191. .UL make
  192. allows you to specify the dependencies among the source files
  193. and the processing steps needed to make a new version;
  194. it then checks the times that the pieces were last changed
  195. and does the minimal amount of recompiling
  196. to create a consistent updated version.
  197. .PP
  198. The debugger
  199. .UL adb
  200. is useful for digging through the dead bodies
  201. of C programs,
  202. but is rather hard to learn to use effectively.
  203. The most effective debugging tool is still
  204. careful thought, coupled with judiciously placed
  205. print statements.\(dg
  206. .FS
  207. \(dg The "dbx" debugger, supplied starting with 4.2BSD, has extensive facilities
  208. for high-level debugging of C programs and is much easier to use than "adb".
  209. .FE
  210. .PP
  211. The C compiler provides a limited instrumentation service,
  212. so you can find out
  213. where programs spend their time and what parts are worth optimizing.
  214. Compile the routines with the
  215. .UL \-p
  216. option;
  217. after the test run, use
  218. .UL prof
  219. to print an execution profile.
  220. The command
  221. .UL time
  222. will give you the gross run-time statistics
  223. of a program, but they are not super accurate or reproducible.
  224. .SH
  225. Other Languages
  226. .PP
  227. If you 
  228. .ul
  229. have
  230. to use Fortran,
  231. there are two possibilities.
  232. You might consider
  233. Ratfor,
  234. which gives you the decent control structures
  235. and free-form input that characterize C,
  236. yet lets you write code that
  237. is still portable to other environments.
  238. Bear in mind that
  239. .UC UNIX
  240. Fortran
  241. tends to produce large and relatively slow-running
  242. programs.
  243. Furthermore, supporting software like
  244. .UL adb ,
  245. .UL prof ,
  246. etc., are all virtually useless with Fortran programs.
  247. There may also be a Fortran 77 compiler on your system.
  248. If so,
  249. this is a viable alternative to 
  250. Ratfor,
  251. and has the non-trivial advantage that it is compatible with C
  252. and related programs.
  253. (The Ratfor processor
  254. and C tools
  255. can be used with Fortran 77 too.)
  256. .PP
  257. If your application requires you to translate
  258. a language into a set of actions or another language,
  259. you are in effect building a compiler,
  260. though probably a small one.
  261. In that case,
  262. you should be using
  263. the
  264. .UL yacc
  265. compiler-compiler, 
  266. which helps you develop a compiler quickly.
  267. The
  268. .UL lex
  269. lexical analyzer generator does the same job
  270. for the simpler languages that can be expressed as regular expressions.
  271. It can be used by itself,
  272. or as a front end to recognize inputs for a
  273. .UL yacc -based
  274. program.
  275. Both
  276. .UL yacc
  277. and
  278. .UL lex
  279. require some sophistication to use,
  280. but the initial effort of learning them
  281. can be repaid many times over in programs
  282. that are easy to change later on.
  283. .PP
  284. Most
  285. .UC UNIX
  286. systems also make available other languages,
  287. such as
  288. Algol 68, APL, Basic, Lisp, Pascal, and Snobol.
  289. Whether these are useful depends largely on the local environment:
  290. if someone cares about the language and has worked on it,
  291. it may be in good shape.
  292. If not, the odds are strong that it
  293. will be more trouble than it's worth.
  294.