Terminal Friday: Standard Stream

Welcome to another Friday ...

It's time to get to know a tiny part of the terminal. After much thought I decided to create a post about the standard streams; Although it will be superficial, I think it is something that everyone should know.

Standard Stream

Standard Stream It is made up of several communication channels between the user and the terminal. These Input / Output “channels” display or capture information when a command is executed.

Quick diagram on standard streams.

The 3 I / O connections are: stdin standard input, stdout Standard output, stderr standard error.

stdin:Standard input

Standard input is the way in which we capture information from a command, either through pipes, redirection, keyboard, etc. We identify it with the file descriptor 0.

An example of stdin would be:

sort <listing

It takes all the information that is in the list -in this case the numbers written randomly-, and when redirecting the file to the ls command, it sorts the numerical list alphabetically. In this example the flags are implicit.

stdout: Standard output

Standard output, as its name implies, displays the output of a command via the console. If we write ls, all the information it shows us on the screen is the standard output. It is represented by descriptor 1.

Now I will try to instantiate stdin and stdout with a script written in bash, simply because I love bash hahaha. 🙂

test.sh

#! / bin / bash if [-t 0]; then echo "You're using stdout" elif [-t 1]; then echo "You are using stdin" else echo "Brutal error" fi

Now a screenshot that demonstrates how to use the script. When redirecting or using a pipe with the script use test -t to know if only the stdout script is executed, and if not it is obviously stdin.

bash test.sh ls | bash test.sh bash test.sh </ etc / passwd

The script in question and its outputs ...

Remember to modify the command and practice so you learn.

stderr:Standard error

Standard Error is the way programs display errors or diagnostics. It is represented by descriptor 2.

To understand the concept, this is the situation: when we want to save a command error, the first thing we think about is redirecting the output to plain text.

ls> info.txt

This would work, the command information will be stored in a plain text file. But when saving the error, it does not store it, but it shows it on the screen and the plain text file is empty.

Instead if we use 2> to indicate to save stderr in the file:

ls foo 2> info.txt

Now it will save the error information in the text file.

Most Shell allow stderr and stdout to be stored in a single command command with &> where Foo is a non-existent directory

ls Downloads Foo &> info.txt

This file will contain the information of the error when executing ls in Foo and will list the directories under Downloads.

And finally, what does that famous 2> & 1?

Simple, redirect stderr to stdout. That & in the middle of> and 1 means it will redirect to stdout. If it weren't there it would be something like ... "redirect the error to file 1".

And with this it is possible to redirect:

• stdout to a file
• stderr to a file
• stdout to stderr
• stderr to stdout
• stderr and stdout to a file
• among others

That's it for today people. We read and thanks for stopping by. 😀