Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!romp!auschs!awdprime!sandino.austin.ibm.com
From: jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091)
Newsgroups: comp.unix.internals
Subject: Re: temporary redirection under a Bourne-shell using "exec"
Message-ID: <3845@awdprime.UUCP>
Date: 13 Oct 90 00:33:24 GMT
References: <977@ign.UUCP> <906@mwtech.UUCP>
Sender: news@awdprime.UUCP
Organization: IBM AWD, Austin, TX
Lines: 30

In article <906@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
->exec 3<&1 >&-	# open File Descriptor 3 (stdout), and close stdout
->echo invisible	# shell stdout is closed, local stdout is FD 3
->exec 1<&3 3>&-	# reopen stdout (and close FD 3)
->echo hello
-
-I would rather change this as follows:
-
->exec 3>&1 >/dev/null
-
-[...] I would not CLOSE stdout (...>&-...) but
-REDIRECT it to /dev/null in the first exec.
-
-Maybe many programs don't care for error returns from their output
-operations, but *some* may do (and IMHO these are the ones written
-by the more careful programmers). Such a program may assume that a
-severe error occured if sending something to stdout returns an error
-and terminate in an unexpected way.

And perhaps a more important reason to leave stdout open (but redirected)
is that if a program does an open() it will probably pick up file descriptor
1 if stdout has been closed.  Then, anything it puts on stdout will get
munged in with what is going to the opened file.  Very messy...

-------------------------------------------------------------------------------
  disclaimer: given the subjective nature of reality, the opinions contained
  herein can have no relationship to any other person's conception of reality,
  and cannot therefore constitute grounds for a lawsuit, right?

Peter Jeffe   ...uunet!cs.utexas.edu!ibmchs!auschs!sandino.austin.ibm.com!jeffe