Detect If Stdout Is Redirected to a Pipe (Not to a File, Character Device, Terminal, or Socket)

Detect if stdout is redirected to a pipe (not to a file, character device, terminal, or socket)?

(my comment turned to answer per Alex Dupuy's suggestion)
Since you said you can use perl, I guess you can use its -p file test operator (perldoc.perl.org/functions/-X.html); something like perl -e 'exit(-p STDOUT ? 0 : 1);' will tell you if stdout if a pipe or a fifo (without distinguishing between them).

Fwiw, calling that from the shell is exactly the reason why I used perl -e :)

Check if a already running process has the stdin redirected on Linux?

You should just be able to look at /proc/<PID>/fd for this information. For example, if I redirect stdin for a command from a file:

sleep inf < somefile.txt

Then I fill find in the corresponding /proc directory:

$ ls -l /proc/12345/fd
lr-x------. 1 lars lars 64 Nov  4 21:43 0 -> /home/lars/somefile.txt
lrwx------. 1 lars lars 64 Nov  4 21:43 1 -> /dev/pts/5
lrwx------. 1 lars lars 64 Nov  4 21:43 2 -> /dev/pts/5

The same thing works when redirecting stdout to a file. If I run:

sleep inf > somefile.txt

Then I see:

$ ls -l /proc/23456/fd
lrwx------. 1 lars lars 64 Nov  4 21:45 0 -> /dev/pts/5
l-wx------. 1 lars lars 64 Nov  4 21:45 1 -> /home/lars/somefile.txt
lrwx------. 1 lars lars 64 Nov  4 21:45 2 -> /dev/pts/5

Confused about stdin, stdout and stderr?

Standard input - this is the file handle that your process reads to get information from you.

Standard output - your process writes conventional output to this file handle.

Standard error - your process writes diagnostic output to this file handle.

That's about as dumbed-down as I can make it :-)

Of course, that's mostly by convention. There's nothing stopping you from writing your diagnostic information to standard output if you wish. You can even close the three file handles totally and open your own files for I/O.

When your process starts, it should already have these handles open and it can just read from and/or write to them.

By default, they're probably connected to your terminal device (e.g., /dev/tty) but shells will allow you to set up connections between these handles and specific files and/or devices (or even pipelines to other processes) before your process starts (some of the manipulations possible are rather clever).

An example being:

my_prog <inputfile 2>errorfile | grep XYZ

which will:

• create a process for my_prog.
• open inputfile as your standard input (file handle 0).
• open errorfile as your standard error (file handle 2).
• create another process for grep.
• attach the standard output of my_prog to the standard input of grep.

---

Re your comment:

When I open these files in /dev folder, how come I never get to see the output of a process running?

It's because they're not normal files. While UNIX presents everything as a file in a file system somewhere, that doesn't make it so at the lowest levels. Most files in the /dev hierarchy are either character or block devices, effectively a device driver. They don't have a size but they do have a major and minor device number.

When you open them, you're connected to the device driver rather than a physical file, and the device driver is smart enough to know that separate processes should be handled separately.

The same is true for the Linux /proc filesystem. Those aren't real files, just tightly controlled gateways to kernel information.

Redirecting python's stdout to the file fails with UnicodeEncodeError

Since nobody's jumped in yet, here's my shot. Python sets stdout's encoding when writing to a console but not when writing to a file. This script reproduces the problem:

import sys

msg = {'text':u'\2026'}
sys.stderr.write('default encoding: %s\n' % sys.stdout.encoding)
print msg['text']

when running the above shows the error:

$ python bad.py>/tmp/xxx
default encoding: None
Traceback (most recent call last):
  File "fix.py", line 5, in <module>
    print msg['text']
UnicodeEncodeError: 'ascii' codec can't encode character u'\x82' in position 0: ordinal not in range(128)

Adding the encoding to the above script:

import sys

msg = {'text':u'\2026'}
sys.stderr.write('default encoding: %s\n' % sys.stdout.encoding)
encoding = sys.stdout.encoding or 'utf-8'
print msg['text'].encode(encoding)

and the problem is solved:

$ python good.py >/tmp/xxx
default encoding: None
$ cat /tmp/xxx
6

Is stdout Ever Anything Other Than a Console Window?

On most systems you can redirect the standard input/output/error to other file descriptors or locations.

For example (on Unix):

./appname > output

Redirects the stdout from appname to a file named output.

./appname 2> errors > output

Redirects stdout to a file named output, and all errors from stderr to a file named errors.

On unix systems you can also have a program open a file descriptor and point it at stdin, such as this:

echo "input" > input
cat input | ./appname

This will cause the program to read from the pipe for stdin.

---

This is how in unix you can "pipe" various different utilities together to create one larger tool.

find . -type f | ./appname | grep -iv "search"

This will run the find command, and take its output and pipe it into ./appname, then appname's output will be sent to grep's input which then searches for the word "search", displaying just the results that match.

It allows many small utilities to have a very powerful effect.

---

Think of the >, <, and | like plumbing.

> is like the drain in a sink, it accepts data and stores it where you want to put it. When a shell encounters the > it will open a file.

> file

When the shell sees the above, it will open the file using a standard system call, and remember that file descriptor. In the above case since there is no input it will create an empty file and allow you to type more commands.

banner Hello

This command writes Hello in really big letters to the console, and will cause it to scroll (I am using Unix here since it is what I know best). The output is simply written to standard out. Using a "sink" (>) we can control where the output goes, so

banner Hello > bannerout

will cause all of the data from banner's standard output to be redirected to the file descriptor the shell has opened and thus be written to a file named bannerout.

Pipes work similarly to >'s in that they help control the flow of where the data goes. Pipes however can't write to files, and can only be used to help the flow of data go from one point to another.

For example, here is water flowing through several substations and waste cleaning:

pump --from lake | treatment --cleanse-water | pump | reservoir | pump > glass

The water flows from the lake, through a pipe to the water treatment plant, from the plant back into a pump that moves it to a reservoir, then it is pumped once more into the municipal water pipes and through your sink into your glass.

Notice that the pipes simply connect all of the outputs together, ultimately it ends up in your glass.

It is the same way with commands and processing them in a shell on Linux. It also follows a path to get to an end result.

Now there is one final thing that I hadn't discussed yet in my previous statements, that is the < input character. What it does is read from a file and output it to stdin on programs.

cat < bannerout

Will simply print what was stored in bannerout. This can be used if you have a file you want to process, but don't want to prepend cat <file> because of not wanting to run an extra command in the chain.

So try this:

echo "Hello" > bannerinput
banner < bannerinput

This will first put the string "Hello" in the file bannerinput, and then when your run banner it will read from the file bannerinput.

I hope this helps you understand how redirection and pipping works on Unix (some if not most will apply to Windows as well).

---

Related Topics