Check out a free preview of the full Complete Intro to Linux and the Command-Line course

The "Pipes" Lesson is part of the full, Complete Intro to Linux and the Command-Line course featured in this preview video. Here's what you'd learn in this lesson:

Brian explains that in order to move from one program to another within the command line, developers have to use pipes. A few commands that allow users to remove multiple files or find multiple files with common characteristics are also explored in this segment.


Transcript from the "Pipes" Lesson

>> Everything that I've been talking about so far has been specifically dealing with going in and out to files. But what if you wanna go from program to program? That's called a pipe, right? So we're piping one thing to another. So if I cat ls.txt, right, this takes whatever is in ls.txt, and then it puts it onto the next thing, right?

But the next thing in this particular case is just displaying, and so that's what it does. But let's say instead of, How we did it before, I could say cat ls.txt and I want to feed this into grep, right? So I can do pipe, which is that vertical bar above your Enter key.

And then I do grep "ls-error.txt". So this is taking the output of cat ls.txt [COUGH] and then it's piping that into grep "ls-error.txt", right? So this is connecting cat together with grep. And you can pipe this as many times, I can, I guess they're the same thing, but let's just echo hey into ls, .txt like this.

And if I say cat ls.txt, Then I have here down at the end. Now we have the ability to input from one thing to another. So let me show you another little thing. We're gonna talk about processes here in a little bit. But if you say ps aux, This is running quite a bit.

What this does is it outputs all of the currently running processes on your computer, which you can see is quite a lot. So what if I wanted to run this? And I only wanted to find the actual process of finding itself, right? So if I say ps aux, all grep does is it takes a list of text and finds something in that.

So if I say grep for ps aux, it's going to find the process of finding itself. So as you can see here, it found this one right here, the process of finding itself. And then it also found the grep, which is it took the input as ps aux.

So that's what this is doing is it's taking ps aux, this super long wall of text and then it's feeding that into grep to find things. So you'll find that grep is frequently one of the things you're gonna be piping into because you'll get 10,000 lines of text and you wanna find two of them, right?

I find myself frequently grepping for Node .js because I wanna kill the process, right? And that's a really good way of doing it. So actually, a really good way of demonstrating this is that yes program. So let's say I have yes and I pipe the output to /dev/null.

And then we'll talk about this in a little bit. But if you put this ampersand in the background, it means it's running in the background, don't run in the foreground. And so now I have process here, 1224. But now I just have that yes running in the background and it's not doing anything other than just running.

If I say ps aux, this is an overwhelming wall of text. Luckily, this is here. But if you're running a real production server, you can have thousands and tens of thousands of processes. It can be pretty difficult to find things. So if I say ps aux and then I grep for yes, I'll find it immediately, and I found the process id right there.

So that's a time that I use the piping a lot is to try and find rogue processes. And then we can use our kill skills that we found before, kill -9 yes, or not yes, but 1224, which is this number right there. And there you go. Now if I run ps aux grep "yes", you'll find it didn't find anything and it also just lets you know, it's like, by the way, I killed this just now.

Or let's do something kind of fun here. Let's go into, what was it, folder3. So in here, I have a lot of files. And let's say I wanted to delete all of them, but you can do rm -i, which is going to force it to ask you yes or no questions.

Yes, I wanna remove all these. And I do file*, like this. It's like, do you wanna remove file cool.txt? Yes, do you wanna remove file1? Yes, do you wanna file10? No, I'm gonna hit Ctrl+C, I wanna exit. I don't wanna do that, right? So this is what I was telling you that yes was actually written for.

If I do yes, and then I pipe that into rm -i file*, it's going to answer yes to all those questions. So just for fun right now, I'm gonna answer no to all the questions, but check this out. It asked me a bunch of times, do you wanna remove this file?

Do you wanna remove this file? And I answered no to every one of them. So they're all still here. But what happens if I say yes with the y instead? Now if you look in here, it's empty cuz it went through and answered yes to all those questions.

So that's why yes exist and so you can answer yes to all those questions. Makes sense? Kind of a fun trick. So yeah, piping and streams and all that kinds of stuff, that's a positively core concept to bash. And if you get a little bit of a grasp on it, it's gonna go a long way in helping you be a more professional developer.

>> It was a question about somebody did cat file.txt and then, Greater than greater than echo. Why doesn't that work?
>> So okay, that's a good question. So let's say I say echo lollerskates. I don't know why that came to mind, but that's what came to mind, into file.txt, right?

So now if I cat file.txt, I believe the question is if I say cat file.txt, and then I, Wait, ask me the question one more time.
>> Trying to push that in echo.
>> Like this, right? So this doesn't work because this is actually going to make a file called echo.

So when you put these right here, that means it's going into a file, right? Whereas if I do, I think if you just do pipe like this, I think it won't do it at all. Okay, so echo doesn't read from standard in. So if you wanted it to go to the output, what you would actually pipe it into is cat.

So you would have cat piping into cat, which doesn't make a ton of sense, but it does work, right? So echo doesn't read from standard in. I mean, you can do this and say echo hi. And it's just going to ignore all this because echo doesn't read from standard in.

And whereas that's what cat is specifically for is from reading from standard in. That makes sense? It's a little split hairy, but all echo does is it just takes in something and spits it back out to standard out.
>> Why did two processes show up for yes in the ps aux?

>> All right. So I ran this one here, so now this is running in the background. And this is the actual process running right here, right, 1257, which matched up to this one. I think the question is why is this one here? Because when you grep for something, grep also shows up in the list that returns back to you.

So grep detects itself. So in this particular case, the yes that it's detecting is the search string from grep. That makes sense? So it's detecting itself is the answer. The search is detecting itself.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now