Command line arguments, redirection, etc.

[Guy Harris]

> 1. Redirection of standard I/O is a part of C, piping is not.
>    Ref: K&R, chapter 7
> 
>    "Finally, the routines are meant to be 'portable', in the sense that
>     they will exist *in compatible form* on any system where C exists"...
> 
>    The routines mentioned are those which use "standard I/O".  See page
>    144... "output can be redirected to a file by using >...", and "On
>    the UNIX system, a pipe can also be used..."  This implies that
>    redirection is required functionality, whereas piping is a part of
>    a particular operating system.

No, you are *inferring*, incorrectly, that redirection is required
functionality.  First of all, the only part of K&R that is close to Sacred
Writ is Appendix A, which is the reference manual.  The rest of it is
tutorial information.  Second of all, if you'd read that stuff carefully,
you would have seen that it said "*In most environments that support C*, a
file may be substituted for the terminal by using the "<" convention...".
In other words, it is a property of the *environment* (including the
operating system), not of the language.  The UNIX Standard I/O library does
not "support" redirection; it's done by the shell (which, I hope, is NOT a
required portion of a C environment - the ANSI C committee is already
standardizing too many things which are properly part of the C binding of
the UNIX system or the P1003 standard).

(As for passing arguments to the program, it should use the conventions of
the host environment if possible; i.e., on VMS, it should presumably
tokenize the commands string (assuming VMS still, in effect, hands you the
whole string as a single lump) and set "argv" to point to the tokens, on
OS/360 and successors, it should use the "PARM=" string, presumably
tokenizing it using "," as the token separator, etc..  If the host
environment doesn't provide command parsing, it's up to the implementor;
they can request a single line of input and use that (and accept redirection
specifications on that line, too), which is what some implementations do, or
they can probably do nothing at all and still meet the ANSI standard's
specifications.)

> You know, I feel better already!  Hey kiddies, get out YOUR copy of K&R and
> read, read, read!   

Yes, read, but read what it says, not what you wish it had said....
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.arpa	(yes, really)