Showing posts with label execute. Show all posts
Showing posts with label execute. Show all posts

Tuesday, 28 August 2012

Different ways of running a shell script…

We hardly care about how a shell script executes, the only thing which we care about is that scripts should execute without any bugs. Here, we are going to discuss about some ways of running a script.
Before seeing the ways of running a shell script, let me clear a question. What is a Shell Script?
We all execute commands on shell. A shell is a program which provides us the environment to execute commands. This also means that we need to have shell running before we start running commands. Now, a shell script is nothing but collection of commands. We club some commands in a file and then ask the interpreter to run the file. This file, where we club our commands is known as interpreter file. Please note that it is not the interpreter file which executes, but the contents of the interpreter file is executed by interpreter, and interpreter is nothing but the shell. Not going in much details into shell and interpreters, we assume that now we know that a shell or interpreter is very necessary for execution of Shell Scripts.
Let's see the ways of running a script
1) /bin/sh testscript.sh
This is the first way in which we specify that we want to run the script using bash shell. Now, the main shell will fork a new shell and that subshell/interpreter will execute the shell script.
Note: We will not be able to access any variables from parent shell unless they are exported.
2) ./testscript.sh or {full-path}/testscript.sh
This is the second way in which we don't specify the shell name. Infact, we write a special line at the top of the interpreter file
#! /bin/sh
# in shell script means that the line is a comment, but # in the first line defines the interpreter to be used for running the script. This line is known as shebang line.
Note: If we don't specify shebang line in this format of running the script then by default, the executing shell will be of same type as the user's login shell. For ex: If the user's default login shell is ksh then ksh shell will be used for running the script.
It is necessary to give relative or full path of script, if we type only script name on the command line, the shell will treat it as a command and start searching in the PATH for the executable file of this command. We can set PATH variable to contain the script path if want to run the script using the script name only.
3) . ./testscript.sh
If we leave first dot, it is same as the second one, then what change does this first dot brings?
Here first dot means script will be run using the same/current shell, i.e. don't fork a new subshell for running the script. The script will be able to use all the variables of the current shell because it is running on the current shell.

For more info visit

Thursday, 12 April 2012

What is Sticky bit?

Sticky bit is used for advance level file permission in Unix. It is one of the twelve bits used in File security.  Generally, users know only about nine bits which are used in File permissions, i.e. 3 for user/owner, 3 for Group to which the file owner belongs and 3 for others. There are 3 other bits also used for advance level file permissions

i) SUID bit

ii) SGID bit

iii) Sticky bit

I already explained the use of SUID bit in this post.

Sticky bit can be used with files, as well as directories. Sticky bit is rarely used with files these days. The main use of Sticky bit comes when it is used with directories.

Sticky bit with files

Sticky bit is used with files in order to make it persist in the swap area or memory. In earlier days when RAM was limited in size, the scheduler used to swap programs very swiftly from RAM to Hard drive. This would cause problems when the part of the program was used very frequently in some process. So, what the programmer would do. He used to set sticky bit on files which were used very frequently, in order to retain them in the memory.

Now a days we have RAM of very high capacities, so Sticky bit is rarely used on files.

Sticky bit with directories

The main use of sticky bit is with directories. For understanding this, we will have to understand  file permissions on directories.

Suppose there is a public directory,  "pubdir" , which has permissions like following

rwxrwxrwx

Since it is  a public directory, it has executable and write permissions for everyone. Now suppose, I have a file "myfile" which is in this public directory , and I have given it permission like following

rwxr- -r- -

I have not given write or execute permission to others. This means that any other user will not be able to edit or execute my file. But will heshe able to delete my file? Well that depends on the directory permissions in which my file is residing.

Now, let's understand "pubdir" directory permissions.

i) Everyone has read permission: Everyone will be able to see the contents of this directory using   ls -l.

ii) Everyone has execute permission: Everyone will be able to access the directory, access on a directory means, anyone can go inside directory using cd command.

iii) Everyone has write permission: Anyone will be able to edit/delete any of the contents of directory.

Now, what are the contents of a directory?...........wwwoooooo  FFFFFFFFiiiiiiiilllllllllleeeeeeeeeeessssssssss.

Damn it. All the files, owned by any user, are vulnerable to a lot of threats.

Now you understood the problem.

Don't worry, we have a solution in the form of Sticky bit. When we set sticky bit for a directory then it puts a restriction on the directory that only the file owner of the file, which is inside the directory, will be able to delete it, and not anyone else.

Sticky bit can be set in the following way.

chmod +t filename

After setting the sticky bit, the directory permission would look like

rwxrwxrwt

The most practical use of sticky bit is in /var/temp. temp directory is public and common to every user.

For more information visit