So I have a program lets call it foo. I am attempting to redirect its terminal output to a file using the following command.
foo > ./someFile.txt
Now when I run that command someFile.txt gets created however it is empty. Any suggestions on how I could redirect the terminal output?
It is expected behavior, that a file someFile.txt will be created. Whether or not this file contains anything, depends on what your program foo is supposed to do.
Whatever problem you are encountering, does not seem to be related to output redirection. You can try following command as a test:
cat > someFile.txt
type anything. Whatever you typed will be redirected to someFile.txt (end with ctrl+d).
Bytheway, the output file is being created by your shell, not by your program foo. Even if you type a nonexistent command, the output file will still be created (empty):
/bin/nonexistent > zzz
>zzz will create the file zzz in the current directory.
Another possibility is that foo uses isatty and doesn't write anything to stdout if stdout does not point somewhere interactive.
SYNOPSIS
#include <unistd.h> int isatty(int fd);DESCRIPTION The isatty() function tests whether fd is an open file descriptor referring to a terminal.
This short Python program demonstrates it:
import sys, os
if sys.stdout.isatty():
print "Hello, tty %s" % os.ttyname(1)
else:
print "stdout: not a typewriter: how boring"
As does this short C program:
#include <stdio.h>
#include <unistd.h>
int main (void) {
if ( isatty(stdout) ) {
printf("Hello, tty %s\n", ttyname(1));
} else {
printf("stdout: not a typewriter: how boring\n");
}
return 0;
}
Both programs have the identical behaviour:
$ ./isatty > notatty ; cat notatty
stdout: not a typewriter: how boring
$ ./isatty.py
Hello, tty /dev/pts/1
$ ./isatty | cat
stdout: not a typewriter: how boring
Programs can choose how, what and whether or not they print based on whether they are being redirected.
A common application of this is to avoid writing ANSI escape sequences read by terminals (\e[33;1m, etc) for text colouring to files, which looks ugly and confuses parsers.
I had the same problem. My program log was not written to [stdout] as expected, but to [stderr] instead. A redirection of both [stdout] and [stderr] was therefore the solution:
foo >> someFile.txt 2>&1
