xref: /original-bsd/share/doc/psd/04.uprog/p2 (revision c3e32dec)
%sccs.include.proprietary.roff%

@(#)p2 8.1 (Berkeley) 06/08/93

BASICS Program Arguments

When a C program is run as a command, the arguments on the command line are made available to the function main as an argument count argc and an array argv of pointers to character strings that contain the arguments. By convention, argv[0] is the command name itself, so argc is always greater than 0.

The following program illustrates the mechanism: it simply echoes its arguments back to the terminal. (This is essentially the echo command.)

1 main(argc, argv) /* echo arguments */ int argc; char *argv[]; { int i; for (i = 1; i < argc; i++) printf("%s%c", argv[i], (i<argc-1) ? ' ' : '\en'); }

2 argv is a pointer to an array whose individual elements are pointers to arrays of characters; each is terminated by \e0 , so they can be treated as strings. The program starts by printing argv[1] and loops until it has printed them all.

The argument count and the arguments are parameters to main . If you want to keep them around so other routines can get at them, you must copy them to external variables. The ``Standard Input'' and ``Standard Output''

The simplest input mechanism is to read the ``standard input,'' which is generally the user's terminal. The function getchar returns the next input character each time it is called. A file may be substituted for the terminal by using the < convention: if prog uses getchar , then the command line

1 prog <file

2 causes prog to read file instead of the terminal. prog itself need know nothing about where its input is coming from. This is also true if the input comes from another program via the pipe mechanism:

1 otherprog | prog

2 provides the standard input for prog from the standard output of otherprog.

getchar returns the value EOF when it encounters the end of file (or an error) on whatever you are reading. The value of EOF is normally defined to be -1 , but it is unwise to take any advantage of that knowledge. As will become clear shortly, this value is automatically defined for you when you compile a program, and need not be of any concern.

Similarly, putchar(c) puts the character c on the ``standard output,'' which is also by default the terminal. The output can be captured on a file by using > : if prog uses putchar ,

1 prog >outfile

2 writes the standard output on outfile instead of the terminal. outfile is created if it doesn't exist; if it already exists, its previous contents are overwritten. And a pipe can be used:

1 prog | otherprog

2 puts the standard output of prog into the standard input of otherprog.

The function printf , which formats output in various ways, uses the same mechanism as putchar does, so calls to printf and putchar may be intermixed in any order; the output will appear in the order of the calls.

Similarly, the function scanf provides for formatted input conversion; it will read the standard input and break it up into strings, numbers, etc., as desired. scanf uses the same mechanism as getchar , so calls to them may also be intermixed.

Many programs read only one input and write one output; for such programs I/O with getchar , putchar , scanf , and printf may be entirely adequate, and it is almost always enough to get started. This is particularly true if the C UNIX pipe facility is used to connect the output of one program to the input of the next. For example, the following program strips out all ascii control characters from its input (except for newline and tab).

1 #include <stdio.h> main() /* ccstrip: strip non-graphic characters */ { int c; while ((c = getchar()) != EOF) if ((c >= ' ' && c < 0177) || c == '\et' || c == '\en') putchar(c); exit(0); }

2 The line

1 #include <stdio.h>

2 should appear at the beginning of each source file. It causes the C compiler to read a file T /usr/include/stdio.h ) ( of standard routines and symbols that includes the definition of EOF .

If it is necessary to treat multiple files, you can use cat to collect the files for you:

1 cat file1 file2 ... | ccstrip >output

2 and thus avoid learning how to access files from a program. By the way, the call to exit at the end is not necessary to make the program work properly, but it assures that any caller of the program will see a normal termination status (conventionally 0) from the program when it completes. Section 6 discusses status returns in more detail.