10-13-2016
freopen DOES NOT redirect standard output! You are only redirecting the C file pointer 'stdout', not the file descriptor it uses.
Basically, you're ripping the floor out from under your program without guaranteeing that the Right Thing has happened to put a new floor back. The 'stdout' file pointer will continue to work, but anything not informed of the change might not -- like cout, and any subprocesses you happen to run. Their output may not go where you expected, or go nowhere at all, or crash. It might work right, if the next file opened happens to land at file descriptor 1 -- or it might not. The behavior is undefined and at the mercy of what libraries and compiler you're using. All that's guaranteed after you do that is that stdio routines like printf() will go where you redirected.
Whatever file descriptor 1 went to before, might not be properly closed after freopen, either. If stdout was an open file descriptor to a terminal preventing your ssh window from closing, such is life.
The "right thing" to do if you really want to redirect "standard output", not just the stdio external variable "stdout", is to ensure that the file you want is opened specifically as file descriptor one, which is what dup2() does in the example you were given. Which is much simpler than it looks once you realize it's redirecting twice: Once for stdout, once for stderr. Re-opening onto file descriptor one with dup2() also guarantees that whatever was there before, is forced to close. This could be especially important if that happened to be a terminal or device file.
Also, your example is concerning. Never mix printf and cout, for starters, especially if you're going to play funny games with redirection.
Last edited by Corona688; 10-13-2016 at 08:04 PM..
10 More Discussions You Might Find Interesting
1. UNIX for Advanced & Expert Users
Hi all hope you can help as I am going MAD!!! :eek:
The below is in a shell script but the redirection in the sed line does not work and outputs to the screen and the $fname_2 does note get created ?????
Can any one help ??
#!/bin/ksh
cd /app/
for fname in `ls -1 X*`
do
sed 1d $fname... (3 Replies)
Discussion started by: mlucas
3 Replies
2. UNIX for Advanced & Expert Users
Hi all,
I have the following script:
-------------------------------------------------
#SCRIPT TO CHECK WHO HAS ACCESSED THE LOG/FILE IN PAST 'N' MINUTES, AND MAIL ACCORDINGLY.
MYPATH="/clocal/mqbrkrs/user/mqsiadm/sanjay/"
MAIL_RECIPIENTS="vg517@dcx.com"
Subject="File accessed in last... (6 Replies)
Discussion started by: varungupta
6 Replies
3. Shell Programming and Scripting
Hi friends
I am facing one problem while redirecting the out of the stderr and stdout to a file
let example my problem with a simple example
I have a file (say test.sh)in which i run 2 command in the background
ps -ef &
ls &
and now i am run this file and redirect the output to a file... (8 Replies)
Discussion started by: sushantnirwan
8 Replies
4. Programming
hello again!
i use dup2 to redirect stdout. I run what i want, now i want undo this redirection. how can i do that?
thanx in advance (7 Replies)
Discussion started by: nicos
7 Replies
5. Shell Programming and Scripting
Hi
I am not if this is possible: is it possible in bach (or another shell) to redirect GLOBALLY the stdout/stderr channels to a file.
So, if I have a script
script.sh
cmd1
cmd2
cmd3
I want all stdout/stderr goes to a file. I know I can do:
./script.sh 1>file 2>&1
OR
... (2 Replies)
Discussion started by: islegmar
2 Replies
6. Shell Programming and Scripting
Hi,
I would like to avoid re-directing line by line to a file.
What is the best way to re-direct STDOUT to a file in a subshell?
Thanks in advance.
Cheers
Vj (1 Reply)
Discussion started by: tnvee
1 Replies
7. Shell Programming and Scripting
Hello
I read a lot of post related to this topic, but nothing helped me. :mad:
I'm running a ksh script with subshell what processing some ldap command. I need to check output for possible errors.
#!/bin/ksh
...
readinput < $QCHAT_INPUT |&
while read -p line
do
echo $line
... (3 Replies)
Discussion started by: Osim
3 Replies
8. UNIX for Dummies Questions & Answers
Hi All,
I am using centOS.
When I try to redirect STDOUT to a file, it ends up in getting some funny characters. For example ...
STDOUT of the command as follows.
$ ls
H3k27me3
H3k36me3
H3k4me1
H3k4me2
H3k4me3
H3k9ac
H4k20me1
$ ls >test
$ cat test
^ (1 Reply)
Discussion started by: Chulamakuri
1 Replies
9. Shell Programming and Scripting
Dear all,
redirecting STDOUT & STDERR to file is quite simple, I'm currently using:
exec 1>>/tmp/tmp.log; exec 2>>/tmp/tmp.logBut during script execution I would like the output come back again to screen, how to do that?
Thanks
Lucas (4 Replies)
Discussion started by: Lord Spectre
4 Replies
10. Shell Programming and Scripting
Dear all,
redirecting STDOUT & STDERR to file is quite simple, I'm currently using:
Code:
exec 1>>/tmp/tmp.log; exec 2>>/tmp/tmp.log
But during script execution I would like the output come back again to screen, how to do that?
Thanks
Luc
edit by bakunin: please use CODE-tags like the... (6 Replies)
Discussion started by: tmonk1
6 Replies
STDIN(3) Linux Programmer's 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).
On program startup, 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>. (Applying freopen(3) to
one of these streams can change the file descriptor number associated with the stream.)
Note that mixing use of FILEs and raw file descriptors can produce unexpected results and should generally be avoided. (For the masochis-
tic among you: POSIX.1, section 8.2.3, describes in detail how this interaction is supposed to work.) A general rule is that file descrip-
tors are handled in the kernel, while stdio is just a library. This means for example, that after an exec(3), 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 nonportable. 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, std-
out, and stderr. The standard streams are closed by a call to exit(3) and by normal program termination.
CONFORMING TO
The stdin, stdout, and stderr macros conform to C89 and this standard also stipulates that these three streams shall be open at program
startup.
NOTES
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
buffering 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, normally terminal input is line buffered in the kernel.) This kernel input handling can be modified using calls like tcse-
tattr(3); see also stty(1), and termios(3).
SEE ALSO
csh(1), sh(1), open(2), fopen(3), stdio(3)
COLOPHON
This page is part of release 3.27 of the Linux man-pages project. A description of the project, and information about reporting bugs, can
be found at http://www.kernel.org/doc/man-pages/.
Linux 2008-07-14 STDIN(3)