What are stdin, stdout and stderr in Linux?

stdin,stdout, andstderrare three data streams that are created when you launch a Linux command. You can use them to determine whether your scripts are being forwarded or redirected. We'll show you how.

Streams connect two points

Once you start learning about Linux and Unix-like operating systems, you will come across the termsstdin,stdout, andstederr. These arethree standard streamswhich are created when a Linux command is executed. In computing, a stream is something that can transmit data. For these streams, this data is text.

Data streams, like water streams, have two ends. They have a source and an outlet. Whatever Linux command you use provides one end of each stream. The other end is determined by the shell that started the command. This end is connected to the terminal window, connected to a pipe, or redirected to a file or other command according to the command line that started the command.

Die Linux-Standardstreams

On Linux,stdinis the standard input stream. This accepts text as input. The text output of the command to the shell is done via thestdout(Standard Out) Stream. Error messages from the command are displayed via thestderr(Standardfehler) stream.

So you can see that there are two output streams,stdoutandstderr, and an input stream,stdin. Since error messages and normal output each lead to the terminal window via their own channel, they can be handled independently of each other.

Streams are treated like files

Streams are played under Linux? like almost everything else? treated as if they were files. You can read text from a file and write text to a file. Both actions involve a data stream. So the concept of processing a data stream as a file is not that far-fetched.

Each file associated with a process is assigned a unique number to identify it. This is called a file descriptor. Whenever an action needs to be performed on a file,the file descriptoris used to identify the file.

These values are always used forstdin,stdout,andstderr:

0: stdin
1: Standard
2: stderr

Respond to pipes and redirects

To help someone get started on a topic, a common technique is to teach a simplified version of the topic. For example, with grammar we are told that the rule ?I before E, except after C? is. But actually, thereare further exceptions to this rulethan there are cases that obey him.

Similarly, when talking about . speaksstdin,stdout, andstderrit is convenient to try out the accepted axiom that a process neither knows nor cares where its three standard streams end. Should a process care whether its output goes to the terminal or is redirected to a file? Can it even detect whether its input is coming from the keyboard or being routed there by another process?

Does a process actually know? or at least can find out should he decide to check? and it can change its behavior accordingly if the software author decides to add this functionality.

We can see this change in behavior very easily. Try these two commands:

ls

ls | cat

DielsCommand behaves differently when its output (stdout) is piped into another command. It islsthat switches to a single column output is not a conversion ofcat. Andlsdoes the same when output is redirected:

ls > capture.txt

cat capture.txt

Redirection of stdout and stderr

It is advantageous if error messages are delivered from a dedicated stream. This means we can redirect the output of a command (stdout) into a file and continue to see all error messages (stderr) in the terminal window. If necessary, you can react to the errors that occur. It also prevents the error messages from contaminating the filestdoutwas redirected.

Type the following text into an editor and save it to a file called error.sh.

#!/bin/bash

echo "About to try to access a file that doesn't exist"
cat bad-filename.txt

Make the script executable with this command:

chmod +x error.sh

The first line of the script gives text about thestdoutElectricity. The second line tries to access a file that doesn't exist. This will generate an error message via . is deliveredstderr.

Run the script with this command:

./error.sh

We can see that both output streams,stdoutandstderr, were displayed in the terminal windows.

Let's try redirecting the output to a file:

./error.sh > capture.txt

The error message that comes via . is deliveredstderris still sent to the terminal window. We can check the contents of the file to see if thestdoutOutput went to file.

cat capture.txt

The output ofstdinwas redirected to the file as expected.

Die>Redirect icon works withstdoutBy default. You can use one of the numeric file descriptors to specify which standard output stream you want to redirect.

To redirect explicitlystdout, use this redirection statement:

1>

To redirect explicitlystderr, use this redirection statement:

2>

Let's try our test again, and this time we use2>:

./error.sh 2> capture.txt

The error message is redirected and thestdout echoMessage is sent to the terminal window:

Let's see what is contained in the capture.txt file.

cat capture.txt

DiestderrThe message is in the capture.txt file as expected.

Redirection of stdout and stderr

Certainly if we can redirect eitherstdoutorstderrcan redirect to one file independently, should we be able to redirect both to two different files at the same time?

Yes we can. This command directsstdoutinto a file called capture.txt andstderrinto a file called error.txt.

./error.sh 1> capture.txt 2> error.txt

Since both output streams? Standard output and standard error? are redirected to files, there is no visible output in the terminal window. We return to the command line prompt as if nothing had happened.

Let's check the contents of each file:

cat capture.txt

cat error.txt

Redirecting stdout and stderr to the same file

That's nice, we have each of the standard output streams in their own dedicated file. The only other combination we can do is to send bothstdoutandstderrinto the same file.

We can achieve this with the following command:

./error.sh > capture.txt 2>&1

Let's break this down.

./error.sh: Starts the script file error.sh.
> capture.txt: Directs the . aroundstdoutstream to the capture.txt file.>is an abbreviation for1>.
2>&1: This uses the &> redirection statement. This directive allows you to tell the shell that a stream should go to the same destination as another stream. In this case we say “Redirect stream 2,stderr, to the same goal as Stream 1,stdout, will be forwarded.?

There is no visible output. That's encouraging.

Let's check the capture.txt file and see what's in it.

cat capture.txt

BothstdoutandstderrStreams were redirected to a single destination file.

To redirect and silently discard the output of a stream, direct the output/dev/null.

Detect redirection within a script

We've discussed how a command can detect if one of the streams is being redirected and change its behavior accordingly. Can we achieve this in our own scripts? Yes we can. And it is a very easy technique to understand and use.

Enter the following text into an editor and save it as input.sh.

#!/bin/bash

if [ -t 0 ]; then

  echo stdin coming from keyboard
 
else

  echo stdin coming from a pipe or a file
 
fi

Use the following command to make it executable:

chmod +x input.sh

The clever part is thistest within the square brackets. Die-t(Terminal) option returns true (0) if the file is associated with the file descriptorends in the terminal window. We used the file descriptor 0 as an argument to the test, whichstdin.

Ifstdinconnected to a terminal window, the test will prove true. Ifstdinis connected to a file or pipe, the test fails.

We can use any text file to generate input for the script. Here we are using one called dummy.txt.

./input.sh < dummy.txt

The output shows that the script recognizes that the input is not coming from a keyboard, but from a file. If you want, you can vary your script's behavior accordingly.

That was with a file redirection, let's try with a pipe.

cat dummy.txt | ./input.sh

The script recognizes that its input is piped. Or more precisely, it recognizes once again that thestdinstream is not connected to a terminal window.

Let's run the script without pipes or redirects.

./input.sh

Diestdinstream is connected to the terminal window and the script reports this accordingly.

To check the same with the output stream we need a new script. Type the following into an editor and save as output.sh.

#!/bin/bash

if [ -t 1 ]; then

echo stdout is going to the terminal window
 
else

echo stdout is being redirected or piped
 
fi

Use the following command to make it executable:

chmod +x input.sh

The only significant change to this script is in the square brackets in the test. We use the number 1 to represent the file descriptor for . to representstdout.

Let's try it. We pass the output throughcat.

./output | cat

The script recognizes that its output does not go directly to a terminal window.

We can also test the script by redirecting the output to a file.

./output.sh > capture.txt

There is no output in the terminal window, we return to the command prompt silently. As we would expect.

We can look into the capture.txt file to see what was captured. To do this, use the following command.

cat capture.sh

Here too, the simple test in our script detects that thestdoutstream is not sent directly to a terminal window.

If we run the script without pipes or redirects, it should detect thatstdoutis delivered directly to the terminal window.

./output.sh

And that's exactly what we see.

Streams of consciousness

If you know whether your scripts are connected to the terminal window or a pipe or are redirected, you can adjust their behavior accordingly.

Log and diagnostic output can be more or less detailed depending on whether it is output to the screen or to a file. Error messages may be logged to a file other than the normal program output.

As is often the case, more knowledge brings more opportunities.

	Linux commands
files	Teer·pv·Cat·tac·chmod·grep·difference·sed·With·Mann·pushed·popd·fsck·Testdisk·seq·fd·pandoc·CD·$PATH·awk·join·jq·fold·unique·Journalctl·tail·stat·ls·fstab·Echo·fewer·chgrp·chown·rev·look·Saiten·Typ·rename·Postal code·unpack·mount·ummount·To install·fdisk·mkfs·rm·is rm·rsync·df·gpg·we·Nano·mkdir·von·ln·Patch·Convert·rclon·shreds·srm
Processes	alias·Screen·above·nett·kidneys·Progress·strace·System·tmux·chsh·Story·at·Charge·for free·which·dmesg·chfn·User mod·ps·chroot·xargs·tty·pinkie finger·lsof·vmstat·Time out·Mauer·Yes indeed·kill·Sleep·sudo·It is·Time·groupadd·User mod·The group·etc·switch off·start anew·Halt·turn off·passwd·lscpu·crontab·Datum·bg·fg
Networking	netstat·Ring·Traceroute·ip·ss·who is·fail2ban·bmon·She·Finger·nmap·ftp·curl·wget·Wer·who am I·w·iptables·ssh-keygen·ufw