In one word: yes! Seen from the outside a script is just a command. It uses other commands (system commands and other scripts) and might be used by other commands as well.

If you have a look in the man pages you will notice that almost every command gives a return code. Not giving back a return code will bereave the calling process to determine if the called process has had success or not.

For instance: "ls" returns usually "0", regardless of what was found in the directory. But it will give back "2" if the directory doesn't exist. Even if you redirect every output to "/dev/null" you still could use this return code:

Code:

$ ls > /dev/null 2> /dev/null ; echo $?
0
$ ls /some/where/does/not/exist > /dev/null 2> /dev/null ; echo $?
2

You could now base some program logic on this:

Code:

#! /bin/sh
DIR=""
RESULT=0

echo "Enter a directory name: "
read DIR

ls $DIR >/dev/null 2>/dev/null
RESULT=$?

if [ $RESULT -eq 0 ] ; then
     echo "Directory $DIR exists"
elif [ $RESULT -eq 2 ] ; then
     echo "Directory $DIR does not exist."
else
     echo "Some unknown error occurred."
fi

exit 0

This is done quite often in production code. For instance, suppose a script copies a file. Using the return code of "cp" the script could find out if everything went well (RC=0) or if maybe there was not enough disk space (another RC) or the destination was not writable for the process (yet another RC) or any other error occurred and the copying failed - by analysing the RC. The scripts author could base a meaningful error message on this instead of just saying "failed" and abort.

Now, what you use from other programs you should also provide because there might be a script calling your script which might want to base its own decisions on what you report back to it.

Btw. "exit" by default means "exit 0", so you don't have to write that. But you should make your exit codes to be meaningful and documented, for instance:

0: success (always! - that is standard)
1: file not found
2: no space left on device
3: ....

Yes. "$1" in script language (that is: inside the scripts program text) is not the same as in awk language. These are different programming languages and therefore the same text doesn't have to have the same meaning. It is like, say, Javascript inside an HTML page: the same text might have different meanings inside the JS part and outside, in the HTML part.

In a script "$1" is the first positional parameter. If you call a script like this:

Code:

$ script.sh first second third

then inside the scripts program the first parameter ("first") would automatically be assigned the variable "$1", the second ("second") would be assigned "$2", etc.

In awk this is completely different. awk is a language to work through text files and manipulate them. Basically a text file is constructed of lines and awk is presented one line after the other. So, an awk program gets the first line, works through the program until its end, then starts over with the next line, and so forth.

Every "line" in a text file is interpreted as a series of fields, separated by field separators (per default the separators are blanks, so the "fields" are "words").

When an awk program starts with a new line some variables are automatically filled with values: "$0" is the content of the whole line, "$1" the content of the first field, "$2" that of the second field, etc.. Your awk program now has only one command: "print $1", which simply means: "print the content of the first field" or, on other words: "everything from the beginning of the line to the first field separator", which is still the default "blank". Therefore the first word is printed to output.

No, you are doing alright. Both regexps are matching what you want to match. Why methyls regexp is still better is not easy to see:

You want to match the part with the filemode at the beginning of the line. Your regexp does match this. But: you should ask yourself not only, if it would catch all the intended catches, but also, if it could catch things you didn't want to get caught - false positives.

You search for a "-" followed by nine characters - any characters. That means that a string like "-abcdefghi" would match this definition too. Look at the following listing and ask yourself if your regexp would get confused or not:

Code:

# ls -log
total 132
drwxr-xr-x. 11  4096 Aug  1 17:34 my-downloads
-rw-r--r--   1     2 Jun 25 15:26 some.file

methyls regexps avoids this because he includes the beginning of line to the prerequisites, which would prevent "-downloads" to be matched like in your regexp. (Notice that "^" at the beginning of a regexp means "beginning of line". "a" matches any "a", "^a" only an "a" as the first character of a line.)

A second thing is: you should not search for "any character", because the file modes can only be "r", "w" and "x" or a "-" respectively (i intentionally leave out sticky-bits to keep this simple). So your regexp would be a bit more robust if you would narrow it down this way:

Code:

f_count=$(grep -c "-[r-][w-][x-][r-][w-][x-][r-][w-][x-]" $TF)

Now it is not "a dash followed by any nine characters", but "a dash, followed by either a 'r' or a '-', followed by either a 'w' or a '-', followed by ....".

But even this tighter match might be fooled whereas methyls regexp is fool-prof because of his "anchoring" at the line start.

And there is either another point to it: when will the grep program be able to determine if the line is a match or not? Lets see your case: it will have to look at every character in a line save for the last n characters, where "n" is 10 - the length of your regexp - in the best case (if it hasn't matched any character so far everything beyond the tenth to last couldn't provide a full match any more).

In methyls case it has to check only one character: the first in the line. It doesn't have to look beyond to determine if the line is a match or not. This is why his regexp will be a lot faster then yours. You will not notice this if you check 10 lines, but if you have thousands of lines to check it will make a difference.

I hope this helps.

bakunin