Sponsored Content
Top Forums Shell Programming and Scripting Very Strange Behavior for redirection Post 302130562 by cahook on Monday 6th of August 2007 06:57:20 PM
Old 08-06-2007
Very Strange Behavior for redirection

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
 

9 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

strange sed behavior

I have a file called products.kp which contains, for example, 12345678,1^M 87654321,2^M 13579123,3 when I run the command cat products.kp| sed -f kp.sed where kp.sed contains s,^M,, I get the output 12345678,1 87654321,2 13579123,3 (5 Replies)
Discussion started by: Kevin Pryke
5 Replies

2. UNIX for Dummies Questions & Answers

Strange Behavior on COM2

Hi, I have a problem with a new touch screen controller that I am trying to use on a SCO 3.0 system. THe touch screen controller only wants to talk at 9600baud. I have updated /etc/inittab per the manual and also edited /usr/lib/event/devices to use 9600 baud. The only way I can get the... (0 Replies)
Discussion started by: Elwood51
0 Replies

3. Programming

Strange behavior in C++

I have the following program: int main(int argc, char** argv){ unsigned long int mean=0; for(int i=1;i<10;i++){ mean+=poisson(12); cout<<mean<<endl; } cout<<"Sum of poisson: "<< mean; return 0; } when I run it, I get the... (4 Replies)
Discussion started by: santiagorf
4 Replies

4. Red Hat

strange mail behavior

Hi I have script to to take backup and send mail to a group once a day. One strange behavior I have observed recently is that most of the time the mail we receive is fine . But someday it just sends out mail without any subject with undisclosed recipients. I dont know how to find the cause... (0 Replies)
Discussion started by: ningy
0 Replies

5. Shell Programming and Scripting

Insane redirection behavior

Hi guys, I know computers don't misbehave. But I'm puzzled by what's happening right know in a script : I simplified the example to point out what seems weird to me. Don't try to find any sense to this stupid script. There are 10 rows in /tmp/tmp.txt i=0 tmpfile=/tmp/tmp.txt while... (3 Replies)
Discussion started by: chebarbudo
3 Replies

6. AIX

Strange memory behavior

Hello together, i have a strange memory behavior on a AIX 7.1 System, which i cannot explain. The Filesystem-Cache will not be grow up and drops often after few minutes. I know if a file was deleted, that the same segment in the FS-Cache will also be cleared. But i am not sure if this is the... (8 Replies)
Discussion started by: -=XrAy=-
8 Replies

7. Shell Programming and Scripting

Strange behavior on one of my server

I am not sure what is wrong, but I have some strange behavior when printing things out. I do create a file with only one word test, no space, no new line etc. nano file<enter> test<ctrl x>y<enter> Server 1 gets (fail) awk '{print "+"$0"*"}' file *test Server 2 gets (OK) awk '{print... (9 Replies)
Discussion started by: Jotne
9 Replies

8. Shell Programming and Scripting

Strange behavior of grep

Hi All, I am facing a strange problem while grepping for a process. Here is the small script that i have written. It will look for any process running with the parameter passed to the script. If no process is running it should print appropriate message. $ cat t.ksh #!/bin/ksh set -x ... (9 Replies)
Discussion started by: veeresh_15
9 Replies

9. Shell Programming and Scripting

Strange Ctrl+C behavior

Hello All, I have a strange issue. I've created a shell script which connects to RMAN (Oracle Recovery Manager) and executes full DB backup. I then executed this script with nohup and in the background: $ nohup my_script.sh > logfile.log 2>&1 &The issue is that when I tried to take a look into... (6 Replies)
Discussion started by: JackK
6 Replies
STDIN(3)						   BSD Library Functions Manual 						  STDIN(3)

NAME
stdin, stdout, stderr -- standard I/O streams SYNOPSIS
#include <stdio.h> extern FILE *stdin; extern FILE *stdout; extern FILE *stderr; DESCRIPTION
Under normal circumstances every Unix program has three streams opened for it when it starts up, one for input, one for output, and one for printing diagnostic or error messages. These are typically attached to the user's terminal (see tty(4)) but might instead refer to files or other devices, depending on what the parent process chose to set up. (See also the ``Redirection'' section of sh(1) .) The input stream is referred to as ``standard input''; the output stream is referred to as ``standard output''; and the error stream is referred to as ``standard error''. These terms are abbreviated to form the symbols used to refer to these files, namely stdin, stdout, and stderr. Each of these symbols is a stdio(3) macro of type pointer to FILE, and can be used with functions like fprintf(3) or fread(3). Since FILEs are a buffering wrapper around Unix file descriptors, the same underlying files may also be accessed using the raw Unix file interface, that is, the functions like read(2) and lseek(2). The integer file descriptors associated with the streams stdin, stdout, and stderr are 0, 1, and 2, respectively. The preprocessor symbols STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO are defined with these values in <unistd.h>. Note that mixing use of FILEs and raw file descriptors can produce unexpected results and should generally be avoided. (For the masochistic among you: POSIX.1, section 8.2.3, describes in detail how this interaction is supposed to work.) A general rule is that file descriptors are handled in the kernel, while stdio is just a library. This means for example, that after an exec, the child inherits all open file descriptors, but all old streams have become inaccessible. Since the symbols stdin, stdout, and stderr are specified to be macros, assigning to them is non-portable. The standard streams can be made to refer to different files with help of the library function freopen(3), specially introduced to make it possible to reassign stdin, stdout, and stderr. The standard streams are closed by a call to exit(3) and by normal program termination. SEE ALSO
sh(1), csh(1), open(2), fopen(3), stdio(3) CONSIDERATIONS
The stream stderr is unbuffered. The stream stdout is line-buffered when it points to a terminal. Partial lines will not appear until fflush(3) or exit(3) is called, or a newline is printed. This can produce unexpected results, especially with debugging output. The buffer- ing mode of the standard streams (or any other stream) can be changed using the setbuf(3) or setvbuf(3) call. Note that in case stdin is associated with a terminal, there may also be input buffering in the terminal driver, entirely unrelated to stdio buffering. (Indeed, nor- mally terminal input is line buffered in the kernel.) This kernel input handling can be modified using calls like tcsetattr(3); see also stty(1), and termios(3). CONFORMING TO
The stdin, stdout, and stderr macros conform to ANSI X3.159-1989 (``ANSI C89''), and this standard also stipulates that these three streams shall be open at program startup. Linux 2.0 March 24, 1998 Linux 2.0
All times are GMT -4. The time now is 05:31 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy