Shell Programming and Scripting

I have searched far and wide for an explanation for some odd behavior for output redirection and haven't come up with anything.

A co-worker was working on old scripts which have run for years and embedded in their code were output redirects which worked for the script during execution and then reset back to normal output after the script completed. He tested the same script on a Solaris 10 box and found that the redirection continued after the script finished. I think that the redirection being persistent is normal, (one expects items set in a shell script to remain after execution i.e. .profiles etc.) the return to normal output seems to be the oddity. I have tested on several different boxes featuring solaris 8 9 and 10, and I get the same results everytime, the redirection persists.

Redirecting stdout works and stdout is redirected properly to the file. However, when trying a command like 2>&1 1>filename, this has the effect of redirecting stdout, but not stderr. (In testing the stderr came back to the terminal, and only stdout stuff went to the file)

If you run the code below, and you seem to lose the standard output, stdout can be recaptured to the tty using exec 1>/dev/tty on the command line and things get back to normal.

When stderr is redirected instead however, all output goes to the file, and the result feels like the session has hung. There doesn't seem to be any interaction. Closing the terminal seems to be the only option

I am interested to know if anyone else can replicate this behavior on their environments, and if anyone can suggest some reasons for it.

OS = Solaris 8,9,10
Arch = SPARC (Fujitsu clone)


Thanks


####################################
## CODE LINES
####################################


#!/bin/ksh

echo "Begin Testing, output to TTY"


# uncomment the following line to test stdout redirection
exec 1> output.file
echo "This should be in the file"

# uncomment the following line to test stderror redirection
# exec 2> output.file

#uncomment the following line to test dual redirection
#exec 2>$1 1>output.file

# Create an Error that should go out to the file
cat asdfasdfasdf


############################################
## END CODE
############################################

###
TESTING PROTOCOL


## The command line is :
>. test.sh
Begin Testing, output to TTY
cat: cannot open asdfasdfasdf

## after the script completes, try to obtain some output to the terminal

> ls -al

No result

> exec 1>/dev/tty

Recapture the stdout to the terminal screen

> cat output.file

This should be in the file
total 12
-rw-r--r-- 1 cogcrn cogcrn 0 Aug 6 16:27 -
drwxr-xr-x 2 cogcrn cogcrn 512 Aug 6 16:27 .
drwxr-xr-x 25 cogcrn cogcrn 1536 Aug 6 16:09 ..
-rwxr-xr-x 1 cogcrn cogcrn 969 Jun 13 13:00 ldap_query.pl
-rw-r--r-- 1 cogcrn cogcrn 27 Aug 6 18:52 output.file
-rw-r--r-- 1 cogcrn cogcrn 0 Aug 6 16:26 TERM
-rw-r--r-- 1 cogcrn cogcrn 394 Aug 6 18:49 test.sh

This is because you're "sourcing" the script

Code:

. test.sh

Execute the script in a subshell and this will not happen

Code:

./test.sh

Cheers
ZB

also

Code:

#uncomment the following line to test dual redirection
#exec 2>$1 1>output.file

should be
exec 1>output.file 2>&1


I'll break the operations down...
wrong version:

Code:

1. exec 2>&1   (stderr now points at stdout, which is the terminal)
2. 1> out        (stdout points to file, stderr still points at the terminal)

correct version

Code:

1. exec 1>out (stdout now points to the file "out")
2. 2>&1         (stdout now points to stdout which is still the file "out")

No - this code is to redirect STDERR to a new file (file given as first argument ($1) to the script) and STDOUT to "output.file".

Cheers,
ZB

oh right I see, apologies,
I thought it was a typo!

DOH!



anyway, it works OK for me as it stands,

SunOS primadtpdev 5.8 Generic_108528-20 sun4u sparc SUNW,Ultra-250

I appreciate the comments, they have all been helpful in that they addressed both of my troubles. I had forgotten the effect of running a program by sourcing it, and the information on redirecting the stderr was also very helpful as several examples on the web were done incorrectly. (That was were I found the syntax that is in my example)


Thanks again to everyone.