Up to $100 off Dedicated Servers

How to Pass Command Data With I/O Redirection

Posted on by J. Mays | Updated:
Reading Time: 3 minutes

Throughout the articles in the Knowledge Base, you may have seen a few interesting characters in the examples.  Specifically, we are referring to these characters:  |, >, and <.  Today, we’re going to talk a bit about pipes.

At the base of things, command-line pipes are roughly the same as the pipes in a building.  Whereas those in a building most typically carry water from an origin to a destination,  command-line pipes carry data from an origin to a destination.  In the most basic sense, the command-line itself (standard input, STDIN) is the origin and the screen (standard output, STDOUT) is the destination.

That example is just a little too simplistic, and it doesn’t really make for an interesting article if that’s all that happens.  That’s where the pipe redirections (|, <, >) come into play … they make things a bit more interesting.  Granted, the purpose behind them is not to make for more interesting examples, but specifically to make the operating environment more useful and/or interesting.  In effect, command-line pipe redirections are a lot like pipe junctions in a building, as they redirect the flow of data based on a switch that has been flipped by the user.  Here are a few examples of their use:

cat blah.txt | grep blah

grep blah < blah.txt

grep blah < blah.txt >&2

In effect, these three examples all do the same thing, except that the last example adds a slightly different twist.  All the examples use grep to search for the word “blah” in the file “blah.txt,” but they do so using different pipe redirections.

The first example uses the cat command to print the contents of blah.txt to STDOUT, and then the | character redirects the output of cat to the STDIN stream for grep.  The second example uses the < character to change the origin for the grep command from STDIN to blah.txt, and grep prints to STDOUT by default.  The third example does the same thing as the second, except that it uses the > character to change the destination of the pipe from STDOUT to standard error (STDERR), which is where most of the error messages that you see in your daily life end up.

In the fine tradition of article examples, all three of these are fairly well useless, considering that grep takes a list of files to search as its optional arguments.  That being the case, you might wonder how pipe redirections are actually useful.  I’ve wondered the same thing for a rather long time, so let’s see if we can figure it out.

I sometimes (read “always”) forget to close my SSH sessions from my workstation to the servers that I maintain, so I occasionally find myself wondering exactly how many sessions I have open.  The netstat command will tell me about all the TCP IP connections that currently exist to and from my workstation, so that will give me a huge list if I type the following command:

netstat -ntu

The “-ntu” is just a set of options for netstat that mean “tell me everything, numerically, about the TCP and UDP connections.”  Indeed, I now have a huge list of connections of all sorts on my terminal (this is just part of the output):

tcp  0  0  ESTABLISHED
tcp  0  0     ESTABLISHED
tcp  0  0     ESTABLISHED
tcp  0  0     ESTABLISHED

That’s not really all that helpful, but knowing what we do about pipe redirections, maybe there is something that we can do about that.  For starters, I’m only interested in connections to port 22 (the standard SSH port), so what say we grep those out?

netstat -ntu | grep ":22"

That’s a little better, as now I’m not seeing the gkrellmd and HTTP connections that I saw the last time around:

tcp  0  0     ESTABLISHED
tcp  0  0     ESTABLISHED

That’s a LOT better than the first go around, and now I can scroll back through and count all the lines that show me connecting to another system via SSH.  On the other hand, I’m pretty lazy, so let’s see if I can make use of another redirect to make wc (word count) count up the lines for me:

netstat -ntu | grep ":22" | wc -l

I think we have a winner here, but let’s see if the output agrees:


Indeed, it worked like a charm, and it looks like I have a good number of SSH connections that I should probably close.  Before I start killing them off, however, I would like to save this output for posterity:

netstat -ntu | grep ":22" | wc -l > most_ssh_connections_ever.txt

I’ll go ahead and take care of closing those now, and we’ll talk a bit more about pipes the next time around.


Liquid Web’s Heroic Support is always available to assist customers with this or any other issue. If you need our assistance please contact us:
Toll Free 1.800.580.4985
International 517.322.0434

Avatar for J. Mays

About the Author: J. Mays

As a previous contributor, JMays shares his insight with our Knowledge Base center. In our Knowledge Base, you'll be able to find how-to articles on Ubuntu, CentOS, Fedora and much more!

Latest Articles

Mount ISO files via IPMI using a local file and the Java method

Read Article

How to use NextCloud — setup and features

Read Article

Use ChatGPT to diagnose and resolve server issues

Read Article

What is SDDC VMware?

Read Article

Best authentication practices for email senders

Read Article