Xref: utzoo comp.unix.questions:25316 comp.unix.internals:134
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.unix.questions,comp.unix.internals
Subject: Re: temporary redirection under a Bourne-shell using "exec"
Keywords: shell exec redirection
Message-ID: <906@mwtech.UUCP>
Date: 7 Sep 90 10:08:02 GMT
References: <977@ign.UUCP>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 28

In article <977@ign.UUCP> eh@ign.UUCP (eh@phenix pour news) writes:
[about temporarily supressing outout to stdout in shell scripts]
>Here is a short example :
>
>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
>echo invisible	# shell stdout is closed, local stdout is FD 3
>exec 1>&3 3>&-	# reopen stdout (and close FD 3)
>echo hello

The original example is fine so far, except that a output-channel should
stay a output-channel (though duping to an input-channel mostly works, as
the example demonstrates) and 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.
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83