Passing Data from One Command to Another with Linux I/O Redirection

Throughout the articles in the knowledge base, you may have seen a few interesting characters in the examples.  Specifically, I’m referring to these bad boys:  |, >, and <.  Break out your overalls and your toolbox.  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 of 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 exact same thing as the second, except that it uses the > character to change the desitnation 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 of the TCPIP 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 127.0.0.1:33200  127.0.0.2:19150  ESTABLISHED
tcp  0  0 127.0.0.1:45627  127.0.0.2:22     ESTABLISHED
tcp  0  0 127.0.0.1:43409  127.0.0.3:22     ESTABLISHED
tcp  0  0 127.0.0.1:57545  127.0.0.4:80     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 127.0.0.1:45627  127.0.0.2:22     ESTABLISHED
tcp  0  0 127.0.0.1:43409  127.0.0.3:22     ESTABLISHED

That’s a LOT better than the first go around, and now I can scroll back through and count all of 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:

32

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 prosterity:

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
support@liquidweb.com
https://manage.liquidweb.com/

Be Sociable, Share!
Here's $75, Launch a New VPS Today. Find out why 30,000 customers have chosen our Best-in-Class Performance & 24x7 Heroic Support.