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

The "Path & Variables" 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 demonstrates how to create paths to Bash scripts to simplify running scripts through the terminal without having to be in a specific directory. Then, best practices to add variables to a bash script and allow the script to access a variable are outlined.


Transcript from the "Path & Variables" Lesson

>> All right, so let's talk about path. I actually got a question about this earlier in the class. So this is actually what I'll talk about so that you have a thing called your path. So if you say echo $PATH right now, you can see that you get this really long string of like paths, right, various different paths, like locations on your computer.

This is where all of your programs are. So you can see here, if I say ls usr/local/sbin, actually it doesn't have anything in there. I know usr/local/games has logcat in it right, or it should, looks like it doesn't. All right, how about snap/bin? Some of these are open.

So you can see here this has all my various different snap binaries and this is how Bash figures out where all of your programs are. So it goes from left to right. So it's going to first check if I say run node, right? So if I say here, run node, it's going to check is there a node here?

No. Here, here, here, until eventually it gets to the snap, then I was like cool. I found something called node, I can invoke it from here. So notice what I'm running gen_files or node_test, right, I have to say .slash to let Bash knows I'm not reaching for something that's in my path.

I'm actually wanting to run something that's in this directory and it's called node_test. That's what the .slash means. But what happens if I wanted to run something like gen_files like this, right? Without any sort of prefix to run it as if it was like a system wide command.

Well, let's make our own directory called my_bin. And I'm gonna move, we'll move node_test into my_bin. And we'll move gen_files into my_bin as well. So if I look in my_bin, you should see I have gen_files and node_test and now we just have to put that on our path.

So the way that we would do that is we're going to vi into our bash RC. And just down here at the end, I'm going to add another line under our another variable and I'm gonna say export PATH =, you need a full path there, so I'm gonna put the tilda and then under my_bin like this, and then I'm going to put colon, the colon is what separates all the various different things on the path and then I'm gonna put PATH there.

Okay, so I have my_bin on there and then it's going to reattach like the rest of the path on it. So I'm not overriding the path. If I didn't put this :$PATH on there, it would overwrite everything that's in the path, and all I'm trying to do is add something on the beginning of it, right?

So now if I write, oops, write quit, actually, just a funny side note about VI again because I love making jokes about VI. If you search for :wq inside of files, it's a bunch of people that have been meaning to write quit out of them, but didn't word in the proper mode, and it's just all over GitHub.

It's hilarious, anyway. So if I echo my path again, you can see here that my_bin is on there. And if I look inside of my_bin, right, you can see that I got gen_files and node_test in there. So now, hopefully I should be able to just say node_test, like that.

And there you go. Now that that's on my path it's like, I can see that and I can run it. Or if I say gen_files, just like that, it runs my program that I put in there. So this is a really useful thing for you to know how to do, because you can create a bunch of your own personal Bash scripts that you can use whenever you want.

And then you can put them on your path and you can run them as if they were just normal commands for your computer. So I mean, it'll even autocomplete, right? So I put gen_ and if I hit tab, files will show up So that is how you use Shibang and that's how you put things onto your path as well.

One thing I was going to throw in here which is useful for you, if I go back into something like my_bin, gen_files, right? A lot of times it's useful to put comments and things, like we're supposed to comment our code, you can do that with Bash scripts as well, if you just put a hash, right?

So this is a comment. In fact, technically this first thing up here, the reason why it doesn't get run is it's technically a comment, right? It's just a special comment. But you'll see all over my notes I have, you can put comments at the ends here. I can say, this is an echo, right.

So that's how you do comments right? So this will still get run because on the left side of the hash but everything after here, this is just a comment, you can put whatever you want there. Cool. All right, so let's talk about variables and how to do variables inside of Bash scripts.

So let's go back into gen_files. Okay, and we're using this path in multiple places, so it'd be cool if that was a variable, and then we could set that variable, right? So let's go do that. We're gonna say, DESTINATION= our path that we're using there. You can put quotes here as well, that's optional, because there's no spaces here you don't have to.

So up to you if you want to put that there. And then here we can just refer to this as DESTINATION, like this. Same here DESTINATION. Okay? So this should feel relatively familiar for you because this looks like what we were doing with environmental variables. And that's because it's literally the same process, the same thing that's been doing that.

So it works just as well. Let's say we wanted to put file here into its own variables, so we can have a file prefix. So let's do that, we're going to say FILE_PREFIX= file. By the way, these don't necessarily have to be screaming cases, as people often call that.

It just frequently is for Bash. I don't know if there's even necessarily a good reason for that. I just always see it that way, so I always just do. But you could absolutely make it lowercase. And I'll see, inside of Bash scripts, I will see people use Pascal case or, I don't see as much camel casing, but I will see people do file prefix like this, up to you, whatever you decide.

But I always see environmental variables written as screaming case always. Okay, so this one's a little bit weirder. We can't just say $FILE_PREFIX like this, because then it makes it ambiguous is what this curly brace refers to, because that could be accessing an array as well. So we have to put curly braces around this as well.

So anywhere that you do destination right here, I could technically put curly braces on this as well. They're just unnecessary so people don't always put them there. But down here I'm doing the touch command that's actually necessary, so I have to put those curly braces on. So just be aware of that.

And now this should work exactly the same way as it did before. So if I write quit and run gen_files, everything still works the way that we anticipated it. And something to keep in mind is, notice that we're using curly braces here. So curly brace is important because that means get a variable, if I put parentheses around it, you remember that's running a sub command.

And it's yet different if you use square brackets. I know it's confusing but just keep in mind that curly braces with the dollar sign that's going to be accessing a variable.

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