You are entitled to thinks so. I disagree but that is a question of opinion, by all means do that. I just said it was unnecessary in this case.

Sorry I didn't follow you here.

The purpose of PATH is to tell the shell in which directories and in which order to look for commands. A properly written script would not normally depend on login environment to know that. There are some exceptions, but I really don't see a reason for having one here. The script will currently break if the user has a different command (or different non-pompatible version of a command) with the same name as one of the ones you use in their PATH before the one you want; or has a command aliased to behave in a way you don't expect which would be worse. If you really want to use PATH, include it in the script, don't depend on the user to set it.

I did, but you didn't receive it.

What I said was, what is preferable if you don't want to use full paths directly use a variable, which I always do by the way, and it is easier to port also.

for eample:

Code:

FIND=/usr/bin/find
...
$FIND $opt_p $opt_R -type f

Also doing it in that way if the command you are using has a verbose option so for example 'tar' you could do:

Code:

TAR="/usr/bin/tar v"

and turn on verbose output for all instances of the command in the script while debugging.

Then to port it is a simple matter of updating the variable if required, or adding a clause for each OS you expect to run on for any non-shared paths.

I'm guessing you mean non-recursive, since it recurses by default:

Code:

find <dir> \( ! -name <dir> -prune \)

Case insenitivity you can do with grep -i or more simply :

Code:

-name "*.[sS][hH]"

Maybe...Solaris and HPUX for example do not.

It has little or nothing to do with laziness. It is more effort for the programmer to write the message, and saves the user a lot of time if they forget the order of the arguments, there are a lot of characters in a man page and some people use slow connections. Most users I have dealt with much prefer to run a commmand with no arguments or -h and get a usage message. Maybe the -h options solves it from either POV. I am not saying don't print the message that says what is wrong, just display the generic form as a reminder too or tell the user how to do so, this kind of thing:

Code:

# check.sh -B
Illegal option -B
    Try `check.sh -h' for more information

Yes.

bourne derived shells such as ksh and bash do.

You could if you wanted to. Something like this inserted in the find would do it:

Code:

find ..... -exec awk ' FNR==1 && /\/sh$/ { print FILENAME; quit}' \; | .....