eh@ign.UUCP (eh@phenix pour news) (09/06/90)
Hi, Here is a small trick in Bourne Shell, concerning temporary redirections (and correct restoration) without entering a sub-shell. In a shell-script (Sys V.3, Bourne shell), I wanted to temporarly desactivate "stdout" without entering a sub-shell, because I assigned variables in it. The order to close stdout for the given shell is "exec >&-", but once it is closed, it is lost till the end of the shell, unless you save it in a brand new File Descriptor. This is an application of the "exec" command. 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 In this example, you assign "stdout" to FD 3 and you close FD 1 (stdout of the shell). When I run this shell-script (toto), "hello" appears. When I run toto >/dev/null, nothing appears, which proves that "stdout" is correctly restored. Of course, you can use files for temporary redirection, or devices... If you want to desactivate the echo on the console (e.g. reading a password), you can use "stty -echo" : echo "Password: \c" stty -echo read word stty echo # then crypt it and compare it to the crypted entry Yours, Eric --------------------------------------------------------------------------- Eric HURTEBIS (Institut Geographique National - France) Net: eh@ign.uucp Tel: +33 1 43 98 80 00 ext.7366 ---------------------------------------------------------------------------
martin@mwtech.UUCP (Martin Weitzel) (09/07/90)
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
jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) (10/13/90)
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@tree.uucp (Chris Gonnerman) (10/16/90)
In article <3845@awdprime.UUCP>, jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) writes: > 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 Some shells don't like you using fd 3... in particular, ash and some implementations of csh (sorry, forget which ones) use fd 3 for reading the shell script. Redirecting it causes strange behavior. I have an application where I do much the same thing, but I (arbitrarily) chose to use fd 9 instead of 3 (after my program repeatedly broke). -- +----------------------------------------------------------------------------+ | Chris Gonnerman (Mad Programmer At Large) csusac.ecs.csus.edu!tree!jcg | | @ the Tree BBS, Sacramento, CA ucbvax!ucdavis!csusac!tree!jcg | +---------- DISCLAIMER: These opinions are mine... MINE, I say! -----------+