I do not understand your objection. Of course it does nothing for the script that I posted, because it has now been debugged and is working fine. The purpose of it is to detect any issues if some maintenance programmer comes along and mucks with it.

Personally, I think that it should always be an error to use an uninitialized variable; if I had written sh, it would not even be an option. Neither would -n. (Both would always be on.) But I have to work with whats there.


First, why would I ever want to use the full path to a command? That makes it totally unportable! The whole purpose of something like the PATH env var is to get around issues like this.

Second, you did not complete your thought: what is the or clause?


I hear you, and wish that I could obey, but after looking into the paucity of stuff actually supported by POSIX find I gave up. It does not support any of the functionality that I really want this function to have, like recursive finding in a directory tree and case insensitivity. If you know of an elegant way to do those things I am open, but I really do not want to write all of them inside this function.

When I did a "man find" just now on a linux box, it did note that many of the non-POSIX options that I am using are not unique to GNU's find but are implemented on other systems too, somaybe it is mostly portable...


Rant mode on: there is nothing more annoying than the lazy unix programmer habit of responding to an input error with the correct usage.

I usually have already read the man page or whatever before using the command, so that usage message tells me NOTHING.

What I really need to know is what--out of the million things that could possibly be wrong--is the actual wrong thing with my input, not what the correct generic form is.

If a command needs exactly 7 args and I have supplied 8, dang it, tell me that I have 1 extra argument as the error message--don't tell me
I could waste minutes staring at my input trying to determine what is wrong until I realize what the problem is that the error message should have told me in the first place.

This unix practice is done solely, as near as I can tell, because it makes the programmer's job slightly easier. But it is bad for the user.


I am slightly confused by your request. My function currently only looks for *.sh files, so why should I not assume that they are bourne shell scripts? Do people routinely write korn shell, c shell, etc script files and use the same .sh file extension for all of them, instead of using something sensible like .ksh, .csh, etc?

I do not even know if other shells support the -n syntax check option, so I would just as soon ignore all script files except those purporting to be bourne shell scripts.

Would it be a better idea to abandon searching for *.sh files, and instead look at every normal file and read its first line and only assume that it is a bourne shell script if the first line starts with "#!/bin/sh"?