LinuxQuestions.org - [SOLVED] First Script and bin directory

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - First Script and bin directory (https://www.linuxquestions.org/questions/programming-9/first-script-and-bin-directory-4175439612/)

First Script and bin directory

;)Hi:

This is my first script and I know it probably has errors but I am trying to understand. I used gedit to make it. I have read this article to help http://www.linuxcommand.org/wss0010.php

Code:

#!/bin/bash

#my first script 

echo "Hello World!"

chmod 755 my_script

./my_script

echo $PATH

export PATH=$PATH:documents

mkdir bin

my_script

Where the line that says export PATH=$PATH: Is this where I put the path to my script in my documents?
ztcoracat/documents/my_script?

And the line for mkdir bin; if I make a new directory is there only one bin that it will be dedicated to?

Does my script have to be named 'my_script"?
Can it be named my_firstscript1?

The instructions say to move my script into my new bin directory.
Where are new bin directories located? In the Home folder?

Your script could look like this

Code:

#!/bin/bash

#my first script 

echo "Hello World!"

echo $PATH

and your commands run outside the script could look like this

Code:

chmod 755 my_script

./my_script

echo $PATH

export PATH=$PATH:~/bin

echo $PATH

mkdir bin

mv my_script bin/

my_script

Quote:

Originally Posted by linosaurusroot (Post 4840883)

Your script could look like this

Code:

#!/bin/bash

#my first script 

echo "Hello World!"

echo $PATH

and your commands run outside the script could look like this

Code:

chmod 755 my_script

./my_script

echo $PATH

export PATH=$PATH:~/bin

echo $PATH

mkdir bin

mv my_script bin/

my_script

Thanks for showing me what belongs in the script it's self and what I'd run in the terminal.

How or where can I learn and read more to understand?

I'm asking because I need to learn how to write a script for 2 cron jobs to run and I still don't understand even after reading all this that a moderator posted for me.
I've read through all of this documentation and Bash scripting is still foreign to me.
http://www.tldp.org/
http://tldp.org/LDP/Bash-Beginners-G...tml/index.html
http://www.gnu.org/software/bash/manual/bashref.html
http://www.webring.org/hub/linux?w=1...hat-linux;rd=1
I didn't read through the Advanced Bash Scripting Guides because I'm still struggling with basic scripting-

Would going and learning Perl help me anymore in understanding Bash?

What else can you recommend?

Go to the Programming forum and look at the bash scripting questions and answers. Also, try the pinfo bash command for a useful on-line reference. (Depending on your distribution, you may need to install the pinfo command, or just use the older info command.) Often whilst I program a bash script, I keep the pinfo bash output in a tab on my terminal emulator so I can refer to it as needed.

You could also look at the scripts in /etc/cron.*/ to see how they are written.

Consider asking the forum moderator(s) to move you thread into the Programming forum. (You can make the request by "reporting" your thread - there should be a button at the bottom of your first post.)

Perl is a great language but it wouldn't help you much with bash.

Programming needs to be learned by doing it - and having exercises that are actual small (to start with) things you want programmed.

Quote:

Originally Posted by PTrenholme (Post 4840957)

Thanks for enlightening me. I was unaware of 'pinfo bash'
My distro is Debian 6.0.5 Stable Squeeze AMD 64bit-

Reading through the Programming Forum is not helping but I just started so I will give it a chance. Thanks for the good advice.

Quote:

Originally Posted by linosaurusroot (Post 4840959)

Perl is a great language but it wouldn't help you much with bash.

Programming needs to be learned by doing it - and having exercises that are actual small (to start with) things you want programmed.

Agreed-
I hope to find more exercises that are small that I can grasp-

I'll check in my "The Debian Administrators Handbook" as there might be a few chapters that discuss Bash-

I found these differnt entries for Bash after the hashbang and am wondering why is the command interpreter different when these are used?

#!bin/bash
#!bin/sh
#usr/bin/perl
#!usr/awk

I looked in etc/cron.d to learn from the file. It's output is:

Code:

CRON.d 

# /etc/cron.d/anacron: crontab entries for the anacron package



SHELL=/bin/sh

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin



30 7    * * *  root        test -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d anacron start >/dev/null

I have read this file several times but still do not understand how to write a shell script for rkhunter and chkrootkit that I would like an executable script to run. Otherwise I have been opening the terminal and running these applications manually.
Any suggestions?

Quote:

Originally Posted by Ztcoracat (Post 4842846)

I found these differnt entries for Bash after the hashbang and am wondering why is the command interpreter different when these are used?

#!bin/bash
#!bin/sh
#usr/bin/perl
#!usr/awk

These are different programs. And you're missing the first / after #!

Quote:

Originally Posted by linosaurusroot (Post 4842894)

These are different programs. And you're missing the first / after #!

Since they are different programs how do I know which one is appropriate for the task I wish to accomplish or run?

Got it; like this:

#!/bin/sh
#!/bin/bash

Moderator Response

Moved: This thread is more suitable in <Programming> and has been moved accordingly to help your thread/question get the exposure it deserves.

Where in the script would I type my explanation of the purpose of the script?

For example:
This script is for cron jobs to run rkhunter and chkrookit @ 8 o'clock p.m. every Friday to make certain that there are not any root kits on my system-
Before or after the PATH?
And where should the PATH start from the /usr/bin or etc/cron?

Bash script or Terminal

Is this argument suitable for a script?

Quote:

run rkhunter_1.3.6-4 and chkrootkit_0.49-4 every Friday at 8 O'clock p.m.?

Quote:

Originally Posted by Ztcoracat (Post 4844772)

Is this argument suitable for a script?

Anyone?

Is there anywhere else I could go to better understand scripting?
And would learning C programming or C+ make Bash scripting make any more sense to me?

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.

Quote:

Is this argument suitable for a script?

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:

Code:

$ /path/to/myscript.sh        #run the script directly, specifying the absolute path



$ export PATH=/path/to:$PATH        #prepend the script's directory to the existing PATH

$ myscript.sh                        #the run the script

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 -

Quote:

The next thing I think you need to recognize is the concept of environments.

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.

Quote:

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).

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!

Quote:

When you execute a script, it will run in a separate process, with an environment of its own.

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

Quote:

I did find scripting a bit confusing when I first started out 10 years ago

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-

Quote:

you have to study and practice if you want to get good at it

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-

Quote:

BTW, don't think like you have to avoid C-type languages completely.

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 ;)

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!

Quote:

Originally Posted by onebuck (Post 4853362)

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;)

Hi,

Your Welcome!

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