I see you already know linuxcommand.org, which is a good step-by-step tutorial. But I recommend the BashGuide for a more thorough, and readable, introduction to scripting. It covers all the basic concepts you need to know.

I think the first thing you need to understand is that a shell script is, in the end, just a collection of shell commands contained in a text file. It's simply a way to automate the actions you would normally do in the shell, so pretty much anything you'd run directly can also be placed in a script, and vice versa. Scripts always run serially, from first line to last, although this can include loops, functions, and other complex commands as well, so the execution doesn't always flow exactly line-by-line.

The next thing I think you need to recognize is the concept of environments. The shell you're running (like all commands) has an environment consisting of various variables, functions, and other settings, including the "$PWD" (present working directory), "$PATH", and others. The env command or the declare -p built-in, will list the values set in your current environment.

When you execute a script, it will run in a separate process, with an environment of its own. Some of these values are inherited from the parent process (i.e. if the export flag was set), and other can be set/modified inside the script itself at any time. Remember too that no process can ever directly affect the environment of another, and whenever a process exits, it's environment disappears with it.


Most scripts follow this general pattern:

1) The shebang. The first line tells the system which interpreting program to use for the script. If the code that follows is designed for bash, then the shebang needs to be #!/bin/bash. Note that the shebang is only important for direct execution of the script file (there are other ways to run it), but this is certainly what you'll usually want to do anyway.

2) Environment settings. Remember the serial nature of the script; all settings have to be made before the commands that use them. This includes shell variables, user variables, functions, and various shell settings. You'll also need to export any values that need to be inherited by sub-processes, i.e. any command that's not built in to shell. Most of the time, however these values will only be needed by the shell itself.

3) The commands you will run, in order of operation. These will generally look exactly the same as they would if you ran them directly, except that variables can be substituted for fixed values. This can also include complex commands such as loops and tests. In general, one command has to finish before the next one is executed, although there are ways to run commands in parallel.


Can you run it as-is in the shell? If so, then it can be placed in a script (assuming the script's environment is similar enough).

Speaking of which, the $PATH environment variable is simply a list of directories that the shell looks into when trying to find a command. And so it's really only necessary if you want to use commands without typing the full path to them. The following are equivalent:



As a bit of more general advice, I recommend not trying to rush into it too fast. In spite of some of the things I just wrote, there are a lot of subtle nuances and gotchas to scripting that can trip you. Build yourself up step-by-step with simple scripts first, and make sure you understand the basics of what you're doing before you dive into anything really deep.

If you post your scripting attempts here you're bound to get a lot of good pointers.

And no, you probably do NOT want to dive into something like C at this point. Languages like that are several times more complex than shell scripting, and you're likely to only lose yourself further. Working your way up the other way is reasonable, however, as scripting will teach you many of the foundational concepts that are also used in more advanced languages.

PS: cron is a command that runs other commands at scheduled times. So write your script so that it does the operation you want once, and use cron to run that script when you want it to.

Thanks for the reply I really was having trouble understanding -

Agreed; the environment (I think) I understand; it's the variables (because there are many) is what makes it a little hard for me to remember. Learning more about environments I think is also the key for me.

I now have a better understanding ie:) whether or not I can run what I want to run.

This question I can now ask myself in the future as a guide so there will be no more doubt and will be an aid to me.
Thank You!
Thanks for that confirmation; I did not know that even after weeks of reading about Bash and all the documentation.
One of our Moderators posted several links for me to learn from as well however; that documentation is good but It still alludes me to some degree. I suspect that Shell Scripting is going to take time for me to fully understand.
Some things are not so easy to pick up on.

Thanks for the link to the Guide at wooledge.org. That Guide I have not come across on my own and it's my hope that It will enlighten me. In your experience have you observed that Bash Scripting is hard to comprehend for a lot of people?

I won't look into 'C' as you advised as that may just make my learning experience more complicated and I most certainly don't want that.

Variables are the main component of the environment. It includes ones preset when the shell starts, those inherited from the parent environment (sometimes starting several levels up, even from the system init process), and your own user-created variables. In the end there's almost no real difference between system variables and user variables, other than how they were set and what commands use them.


I did find scripting a bit confusing when I first started out 10 years ago, yes. But back then there weren't that many good scripting guides. Linuxcommand.org helped a lot, and the ABSG was very useful as a reference after I got the basics down. I also still use the bash man page a lot. But these days I recommend the wooledge site and Bash Hackers, which I think provide much better and easier-to-understand coverage than what I had to use.

But more than that, programming is just like any other skill -- you have to study and practice if you want to get good at it. And it's always slow when you're just starting out, particularly if it's a subject that's completely new to you. Of course some people will naturally find it easier than others, but with determination anyone can do it.


BTW, don't think like you have to avoid C-type languages completely. If you're really interested then find a tutorial and give it a try. You might personally find doing both in parallel beneficial. Or you may not, but it could help just to familiarize yourself with the "feeling" of it. Just remember that there's a much deeper level of complexity and sophistication involved in full programming languages, and that you have to be careful to keep them separate in your head.

As for myself, at various times I've tried my hand at several other language tutorials, including C, python, and perl, but I've yet to stick with any of them for very long. But I have noticed that it's becoming noticeably easier to understand what's going on in them as my scripting knowledge has improved. As I said, the basic concepts carry over very well between languages, even if the specifics do not

Glad I'm not alone in this department-
It's a little frustrating but I'm not giving in and most certainly not giving up-

Agreed, but finding the right curriculum and practicing that is the key for me that I haven't found yet.
I take heed to all the websites you and others have posted for me it's just that I'm struggeling a little.
But that's ok and most likely expected-

Thanks for the encouragement-
Your right; why limit what I could potentialy enjoy-

Your experience shows in what you write thank you for giving it!
It's helped me ;)

Member Response
 

Hi,

You can build on what you learn with scripting. Most shops use scripting to work a problem set before even considering a higher level language. Sometimes they will even work the problem out via scripts and never move to another language.

Once you learn to think out the problem from either inside out, linearly or outside to simpler terms then achievement will be reached. Problem identification and how you break things into tasks will determine success. Just do not try to complete the task in one set, break into terms you can understand and translate into a successful script.

HTH!

Never looked at it this way (as I don't possess the experience you have) you put light on the subject effectively.This makes sense and helps a great deal.

Thanks! Onebuck;)

Member Response
 

Hi,

Your Welcome!

One other thing, have fun and enjoy the learning experience.