In this lesson, we're going to look at what shell scripts are, why you should learn them, and how they can be helpful to you. 

First off, a shell script is simply a file that contains a series of Linux commands and shell statements. The shelf script itself, the file, is made up of ASCII text, also called plain text. This means that you need to use a text editor to create shell scripts. Some good command line text editors include Vim, Emacs, and Nano. If you want to create shell scripts in a desktop environment using a graphical user interface, you can use texts editors like Atom, Sublime Text, Notepad++. and TextWrangler. 

I'm being very careful with my words here. I'm saying text editor for a reason. Do not use a word processor, such as Microsoft Word, LibreOffice Writer, or Apple's Pages to create shell scripts. Many word processors add additional formatting and make changes to the text that you're typing in. One common thing word processors do is they turn normal straight quotation marks into curly quotation marks. Those straight quotation marks and shell scripts are actually part of the syntax. So, using fancy or curly quotation marks will cause your shell scripts to either report an error or produce some unexpected behaviors. Also, these plain text files do not include any other types of special formatting, such as bold text, italics, and so on. When a shell script is executed, it in turn executes the commands listed in the script. It starts at the top and executes the commands on each line, one line at a time until the end of the file. Executing a shell script will produce the exact same result, as if you had typed in each line by hand directly into the terminal. 

So, shell scripts are plain text files that contain a series of commands. But why would you want to save a series of commands into a script? For starters, it can save you a lot of time and work. Anytime you find yourself entering multiple shell commands in the terminal in order to accomplish a task, and you'll need to do that task again in the future, it's time to write a shell script. 

Once you figure out the set of commands that needs to be executed in order to get the word done, you can put those commands in a shell script and simply execute the script itself the next time you need to do that task. If it's a task that has to be done on a regular basis, that's even better, because you can write a shell script and then schedule that script to run at a certain time, and then you'll never have to do it yourself again. So shell scripts save you time and effort by allowing you to eliminate repetitive tasks through automation. That means instead of typing the same commands over and over again, you can spend that time doing more valuable and higher level tasks. Another good time to write a shell script is for a task that you have to do more than once, but it's something that you rarely do. 

I'll give you an example of a task I had to do at one of my previous jobs. Each time a new version of this one particular application came out, I would have to put a copy of the production database into our test environment so that the new version of the application could be tested against actual production data. On the production side, this involves suspending rights to the database, creating a clone of the underlying sand disks, and resuming the database. To my initial point, because I rarely did this, I would end up forgetting the command to initiate the clone, and all the options that were required to go with it. Each time I did this, I had to spend some time rereading the man page and more or less reteaching myself how to do this process. That alone was reason enough for me to create a shell script. 

If we go beyond my original point of, it's something that I rarely did, there was another reason to write a shell script. You see, I wanted to make sure that the production database was paused for as little time as possible. I wrote the shell script so as soon as the clone was successfully kicked off, it would resume the database. That way I didn't have to manually recheck the clone status and then manually type in the command to resume the database. The script did it, and it did it faster than a human could do it. A third takeaway from this one example is that since this was the company's most valuable database, I really didn't want to take any chances and make a mistake. Once I had tested my script in a non production environment, I could let it do the hard work of picking out all the correct disks, typing all the right commands with the right options, and so on. Using a good script can reduce the chance of errors. Many times, I would have to do this at midnight when I was tired and not as alert as usual. When you're tired, the chances of making mistakes go up, so to have some extra help in the form of a shell script was a very good thing for me. If you want to delegate a task to less experienced or knowledgeable staff, then create a shell script for it. 

If you have some specific knowledge of how a piece of work needs to be performed, you can put that knowledge in a shell script. The shell script then becomes a black box to others, but they can still use it to get the same results. Take, for example, an employee separation process. Let's say someone from Human Resources submits a help desk ticket to notify the Information Technology Department that a given employee has left the company. The help desk then transfers that ticket to you so you can lock the Linux account on all the Linux systems. If you created a shell script that performed the work, you could hand this task over to the help desk. They don't have to know all the details of how the shell script actually works, they just need instructions on how and when to use it. That frees you up from that particular task. 

If you need information from more than one command or source, that is another great time to create a shell script. If you ever find yourself making notes, that's a good sign there's an easier way to do it. For example, let's say you manage a web server, and for each IP address that generated a web server error, you wanted to know their host name as well as see all the web pages that they visited. If you were doing this by hand, you would have to look through the error log and note each IP address. Perhaps you would copy and paste these IP address and put them in a scrap file, for example. And then what you would do is look up each IP address to determine their host name. Finally, you would search for those IP addresses in the web server access logs. Now you could write a shell script that does this entire process for you, and displays it in an easy to consume and easy to read format. 

Okay, so I've given you a couple of examples of shell scripts. When you think about it, shell scripts are really just computer programs written in the shell language. So, why would you choose to write programs in shell instead of writing programs in a compiled language, such as C or C++? The main reason is speed of development. For example, you can write a shell script that will perform a simple backup by first archiving a set of files, and then copying that archive over the network to another server. You could do that in just a few lines of shell code and be done fairly quickly. However, accomplishing that same task in C would take a lot of time and effort. When you're writing shell scripts, you don't have to worry about low level programming objects, such as bytes, pointers, declaring data types, and so on. The shell is a high level language that allows you to express complex operations simply and clearly. Related to the speed development is the ease and speed of learning how to shell script. If you use the command line already, then the leap to creating shell scripts is really a small one. You just need to learn a few shell specific operators and rules, and you're ready to start. Of course, if you want to learn advanced techniques and write really complicated shell scripts, it's going to take more time and effort, but the initial learning curve is relatively low for simple scripts. 

In all fairness, there is a trade off for the ease and speed of development. That trade-off comes at the cost of performance and efficiency. That shell script that you wrote in 30 minutes will not execute as fast as the equivalent program that might take days to write in C++, but the trade-off is often well worth it, especially when the shell script will run fast enough for the intended purpose. You can create shell scripts for almost anything, but the real sweet spot is typically for system administration and reporting tasks, where getting the job done is more important than getting the job done a few microseconds quicker. 

I want you to keep in mind that any tasks that you can do on the command line can be automated by a shell script. I want to say that again, any task you can do on the command line can be automated by a script. Of course, some scripts are going to be harder than others, but you can do it. In this course, we'll cover it the simple examples, all the way to the very complex situations where many people might think it's practically impossible to automate such the task. 

To quickly recap a shelf, a shell script is a plain text file that contains a series of commands. When a shell script is executed, it, in turn, executes the commands listed in the script, line by line, starting at the top of the script, just as if you had typed the commands in yourself. Shell scripts can save you a lot of time and work. You can fully automate tedious or repetitive tasks. You can hand off work to others by providing them a script of reform in action. Scripts can also act as a form of documentation for a process or procedure that you perform infrequently. In general, shell scripts are fairly quick and easy to write. Instead of spending your time worrying about low-level programming tasks, you can focus on accomplishing the goal at hand. And finally, anything that you can do on the command line can be automated with a shell script.