No, but you might think a bit and find a more "computerised" way of achieving this goal. You can, for instance, write a small parser, which filters out all the shell keywords and other language constructs so that only commands are being left over, which you can then feed into a while-loop for instance to process as described below.

You can probably (but with less runtime-security) forego the parser and reduce it to a matter of sequential greps to arrive at the same list. Note, though, that this will be a more error-prone (altough more easily to achieve) alternative, because parsing adds context to the processed code which filtering doesn't (to add some theoretical background: the difference between Chomsky-Type 3 and Chomsky-Type 2 grammatics coming in here).


What exactly do you mean by "automatically"? If i remember correctly (Don Cragun may help out here) /usr/bin/dowhateverineed was not part of the POSIX standard last time i checked, so: no, you won't get that automatically. You will have to do work to achieve results like the rest of us.

Here is an idea: implement, what i proposed before, put that into a script, pass to this script the name of a another script you want to check, let the script go over the process of extracting commands and then, for every command found, execute a test if this command exists at the target system. This takes already care of the "command not found"-problem.

Here is another idea, which might sound a bit outlandish: STICK TO THE POSIX STANDARD! There are a lot of POSIX-certified platforms and even non-certified platforms will for most parts adhere to the standard. So, if you use only what is in this standard you will at most times be on the safe side even without complicated tests. If you want to use every obscure platform-specific speciality you are doomed to ultimately fail anyway, having tests or not. So, how about changing your working habits instead of wanting to change the world?

Frankly, i work in environments where i have to deal with up to a dozen different platforms (different OSes, different versions, etc.) and my scripts usually work even in these environments without problems (that is: problems coming from this diversity - my scripts are not flawless at all, but i don't have your problems). And 1000 lines of shell code is a typical size of one of my scripts, of which i have (and use) many dozens. My pity for you to have to manage 1000 lines of code is somewhat limited.

I hope this helps.

bakunin