Begin with shell script.
Write a script which print “HELLO, coderInMe”.
#!/bin/bash echo "HELLO, coderInMe";
Output will be:
Now we know about shell or not? according to panix
A simple shell script
A shell script is little more than a list of commands that are run in sequence. Conventionally, a shellscript should start with a line such as the following:
THis indicates that the script should be run in the bash shell regardless of which interactive shell the user has chosen. This is very important, since the syntax of different shells can vary greatly.
A simple example
Here’s a very simple example of a shell script. It just runs a few simple commands
#!/bin/bash echo "hello, $USER. I wish to list some files of yours" echo "listing files in the current directory, $PWD" ls # list files
Firstly, notice the comment on line 4. In a bash script, anything following a pound sign # (besides the shell name on the first line) is treated as a comment. ie the shell ignores it. It is there for the benifit of people reading the script.
$USER and $PWD are variables. These are standard variables defined by the bash shell itself, they needn’t be defined in the script. Note that the variables are expanded when the variable name is inside double quotes. Expanded is a very appropriate word: the shell basically sees the string $USER and replaces it with the variable’s value then executes the command.
We continue the discussion on variables below …
Any programming language needs variables. You define a variable as follows:
and refer to it as follows:
More specifically, $X is used to denote the value of the variable X. Some things to take note of regarding semantics:
bash gets unhappy if you leave a space on either side of the = sign. For example, the following gives an error message:
X = hello
while I have quotes in my example, they are not always necessary. where you need quotes is when your variable names include spaces. For example,
X=hello world # error X="hello world" # OK
This is because the shell essentially sees the command line as a pile of commands and command arguments seperated by spaces. foo=baris considered a command. The problem with foo = bar is the shell sees the word foo seperated by spaces and interprets it as a command. Likewise, the problem with the command X=hello world is that the shell interprets X=hello as a command, and the word “world” does not make any sense (since the assignment command doesn’t take arguments).
Single Quotes versus double quotes
Basically, variable names are exapnded within double quotes, but not single quotes. If you do not need to refer to variables, single quotes are good to use as the results are more predictable.
#!/bin/bash echo -n '$USER=' # -n option stops echo from breaking the line echo "$USER" echo "\$USER=$USER" # this does the same thing as the first two lines The output looks like this (assuming your username is elflord) $USER=elflord $USER=elflord
so the double quotes still have a work around. Double quotes are more flexible, but less predictable. Given the choice between single quotes and double quotes, use single quotes.
Using Quotes to enclose your variables
Sometimes, it is a good idea to protect variable names in double quotes. This is usually the most important if your variables value either (a) contains spaces or (b) is the empty string. An example is as follows:
#!/bin/bash X="" if [ -n $X ]; then # -n tests to see if the argument is non empty echo "the variable X is not the empty string" fi
This script will give the following output:
the variable X is not the empty string
Why ? because the shell expands $X to the empty string. The expression [ -n ] returns true (since it is not provided with an argument). A better script would have been:
#!/bin/bash X="" if [ -n "$X" ]; then # -n tests to see if the argument is non empty echo "the variable X is not the empty string" fi
for more detail
You can click Panix.com
All rights reserved. No part of this Post may be copied, distributed, or transmitted in any form or by any means, without the prior written permission of the website admin, except in the case of brief quotations embodied in critical reviews and certain other noncommercial uses permitted by copyright law. For permission requests, write to the owner, addressed “Attention: Permissions Coordinator,” to the admin @coderinme