Xref: utzoo comp.sys.apollo:595 comp.unix.questions:4864 Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.sys.apollo,comp.unix.questions Subject: preconnected file descriptors Message-ID: <491@cresswell.quintus.UUCP> Date: 23 Dec 87 02:57:01 GMT Organization: Quintus Computer Systems, Mountain View, CA Lines: 46 Keywords: sh(1) Apollo SR9.5 preconnected fds I was under the impression that if you had a plain Bourne shell which had been invoked as part of logging in, and you ran a program without specifying any I/O redirection, you would have precisely three file descriptors already connected: ^^^^^^^^^ 0 - stdin 1 - stdout 2 - stderr A particular program we have which is part of a larger suite expects to be called with fds 3 and 4 connected (to pipes, as it happens). Part of the testing procedure when we put this thing on a new system is to run this program on its own, e.g. $ component 3test-output $ diff test-output expected-output At the moment we are putting this thing up on an Apollo running SR9.5, and the tester didn't realise this thing had arguments, and ran $ component with no I/O redirection. We were surprised to see output coming out on the terminal that was intended for fd 4. This can be reproduced by running the following script: #!/bin/sh cat >four.c <<'EOF' main() { static char message[] = "You should NOT see this!\n"; int rc; extern int errno; rc = write(4, message, -1+sizeof message); printf("sizeof message = %d, rc = %d, errno = %d\n", sizeof message, rc, errno); exit(0); } EOF cc -o four four.c echo This one IS supposed to write the message ./four 3/dev/tty echo This one is NOT supposed to write the message ./four The C shell acts as expected. On the other hand, it doesn't permit the redirection we really want. The question: are file descriptors other than 0,1,2 MEANT to be preconnected in the Apollo system, and if so, which, and to what? if we close 3 and 4, will something break? are there other "UNIX" systems which do this?