Setting Up a Command Line Script

[00:00:00]
>> Kyle Simpson: So we're gonna set about to make, essentially, an executable shell script. And the one that we're gonna do in this exercise is admittedly a little silly, but you can probably imagine a variety of shell scripts that you've used from time to time. Even stuff where you have like you're running a babble or you're running something like a web pack or something, those command line scripts.

[00:00:26]
Those are essentially like bash scripts but they've been written in node. So let's talk about how we could write a command line script and have it actually execute similar to if it was a bash script. Again, this is gonna be a thing that's gonna be different between the Linux, Mac, Crowd, and if you're working on Windows.

[00:00:48]
But one of the standard conventions if you're working in a typical Linux kind of shell like bash or ZHS or whatever, is that you can put what's called the shebang comment at the top of a file and that will tell the shell environment that when it starts to execute it, it knows what program to hand that execution off to.

[00:01:11]
Instead of trying to interpret it as a bash script it'll handed off to something else. So that's called the shebang or the hash bang because, we do hash symbol. And then the bang and then we give it a file to use for the interpretation. So we want ours to be interpreted by node so we can give it the full path to our node program, but it turns out that there are places, there are differences were node gets installed in different systems and if you want your script to be able to run on all of your developer machines at your company, you probably want to be a little more agnostic about it.

[00:01:47]
So there's a trick, there's another program called env, E N V that'll be included in all your distributions of Linux or Mac. You give it the name of an executable and it finds where that is for you. So what we're actually gonna do is do usr/bin/env, and then we're gonna tell it node.

[00:02:08]
This is saying go find node wherever it is in my system and use node to interpret the rest of my program. Before I forget, because I always seem to forget this, you should always be running your code in strict mode. So go ahead and put a use strict there.

[00:02:25]
But I wanna make a point about use strict because we typically think of use strict as only working if it's at the very top of the file without anything in front if it. And we actually have something here in front of it. So the thing that you should be aware of is that by the time this line of code runs with node, that line of code is actually empty.

[00:02:46]
So it's already been stripped out by the processing environment by the time it runs. You don't have to worry about this being invalid JavaScript syntax. All right, so now that we have it interpretable by an environment, by the shell environment. Now what we wanna do is actually make it an executable.

[00:03:06]
So again, because I'm in a kind of Linuxy sort of a system, if you look at the file descriptors here, you'll see that the user has execution bit on it. That's because that's how I have already edited this file and it may already be depending on how you got these files, it may already be set, but if that x is not there, then it can't be executed as a user.

[00:03:29]
So if you don't have the x there you can say, change mod and you can say user plus x and then say ex1.js. And that will tell it to put that x bit on there if you didn't already have it. Once you have that executable bit, that file permission on your .ex1 instead of saying node ex1.js, now you're gonna be able to say just ./ex1.js.

[00:04:01]
Very similar to how you might run any other program that might be installed on your computer, you can say .1./exi.js. So now we've made it an executable script. But one other thing that we wanna do, right off the bat whenever you're going to work with a node script, or any kind of shell script that you're making is you wanna have a good, clean output for these things.

[00:04:26]
And it's incredibly common to skip this step, and I'm just gonna tell you don't skip this step. Whenever you're writing scripts, put for yourself some kind of help output for your scripts, because you will come back to the script three days from now and completely forget how it is you're supposed to pass stuff in or run it or whatever.

[00:04:43]
Just always remember, it's a good idea to have some help output. So we're just going to, and you can do this however you like. But I'm gonna write a little print help function, just to print some basic help output. So we're gonna say, console.log, and then we'll say ("ex1 usage").

[00:05:05]
I will say ("ex1 usage") and then console.log, and then we'll say ("ex1.js--help"). And then,
>> Kyle Simpson: However you want it to read, but just something kind of slightly friendly for future you or anybody else who wants to use this. So, just define that function and then call it.
>> Kyle Simpson: And then as you start to run this, if you go back to your command line and you run it.

[00:06:04]
Now you should see what looks like a typical command line script, this got some like official looking output to it. You can put a copyright there if you really want to protect your intellectual property.