Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!mjs
From: mjs@mentor.cc.purdue.edu (Mike Spitzer)
Newsgroups: comp.unix.questions
Subject: Re: Unix deficiencies/problems
Message-ID: <2656@mentor.cc.purdue.edu>
Date: 7 May 89 15:37:28 GMT
References: <810038@hpsemc.HP.COM> <810046@hpsemc.HP.COM> <159@dg.dg.com> <424@algor2.UUCP>
Reply-To: mjs@mentor.cc.purdue.edu (Mike Spitzer)
Organization: Purdue University
Lines: 33
In article <424@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes:
>I miss very little from the IBM world, but the availability of formal file
>names is one of them. Once UNIX starts getting into commercial
>environments they will become more useful. Briefly, a formal file name is
>a name by which the program interfaces with a JCL (or shell) language and
>which can be redefined. UNIX has 3 usable ones, stdin, stdout and stderr,
>and that covers a remarkable variety of situations. But an application
>might well want one or two databases, an transaction input file, an error
>output, a logging file and 2 or 3 reports. It would be nice if each of
>these could be redirected as easily as stdin, stdout and stderr.
The Bourne shell and other reasonably sh-compatatible shells (like
ksh) allow the redirection of any file descriptor, not just stdin,
stdout, and stderr. You can have the shell open these file
descriptors for your program and have "formal files" as you describe
above. To use your example, you could:
application logfile 2>errs 3rep1 6>rep2
Of course, "application" would have to know which file descriptors to
use for which purpose. Also, the first thing that it should do is
verify that all of the proper file descriptors are open (fstat(2)
would work).
There is a limitation, though. In this case you might want to have
db1 and db2 open for both reading and writing, but there is no way to
make the shell do that do you. You could always have one file
descriptor for reading and one for writing on the same file, but that
isn't always what you really want to do....
--
Michael J. Spitzer Purdue University Computing Center
mjs@mentor.cc.purdue.edu pur-ee!mentor.cc.purdue.edu!mjs