![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to u4 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / usd / 01.begin|
Return to u4 CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / usd / 01.begin |
1.1 root 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.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.