Quote:
1. Your set -u is doing nothing at all since you have defaults for the only variables you use.
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.
Quote:
2. Use either a variable set to the full path (preferable) for a full path to programs you run.
eg
Code:
---------
FIND=/usr/bin/find
...
$FIND $opt_p $opt_R -type f -iname "*.sh"...
---------
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?
Quote:
3. Use POSIX arguments to find, it takes more work but is portable.
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...
Quote:
4. Instead of saying that the script will exit, print a usage message, you have that in the comments, but a usage message is better.
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
Quote:
usage: someCommand arg1 arg2 arg3 arg4 arg5 arg6 arg7
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.
Quote:
As an improvement, instead of assuming bourne/bourne compatability, test for a magic number in the first line of the script and run the <script interpreter> -n based on that, if there is none, then by all means default to using bourne.
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"?