Formal file names (was: Unix deficiencies/problems)

Jan B. Andersen d.jba at harald.ruc.dk
Sun May 7 02:57:48 AEST 1989


I have been following the discussion on LOGICALS vs ENVIRONMENT with
interest. It's true that you can achieve the same with both methods, but
environment variables requires a bit work than logicals.

As jeffrey at algor2.UUCP (Jeffrey Kegler) writes:

>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.

One thing which I haven't seen mentioned in the discussion is how to extend
stdin and stdout with something like stddata[] and stdlist[]. As I understand
it, it's the shell which handles io-redirection etc. and sets up stdin,
stdout and stderr before forking the process. Now, instead of modifying the
shell to handle stddata and stdlist, why not having a special io-shell
do the extra work involved in opening stddata[] and stdlist[].

Assume the following enviroment variables:

STDDATA="db1 db2 my-transactions"
STDLIST="/dev/conslog /dev/tape |lp"

With the proposed io-shell the job might be started with:

  $ io-shell my-job

The io-shell would then open db1, db2, my-transactions for input,
/dev/conslog and /dev/tape for writing, and fork lp with input coming from
a pipe and these file-descriptors could then be passed to my-job just like
stdin, stdout and stderr.

Is there any thing wrong with this idea?



More information about the Comp.unix.questions mailing list