No worries: I have never felt that you are beating me up on anything. I solicited feedback, and you generously shared your knowledge with me. I appreciate that. My delay in responding is merely because I have been so busy for so long.

Speaking of overwork, I have no more time to invest in this shell script, but I have these final points to make:


1) I now think that aliases for this script (e.g. an alias for find) are no problem at all. Reason: aliases defined on the shell before executing this script are not inherited by the script when the user runs it (at least on cygwin and linux--is this true of all unixes?). Execute

Code:

alias find
alias find="lfsdllgfsdfnsdfjskjs"
alias find

on the command line; the first line should have the output

Code:

bash: alias: find: not found

while the third should have output

Code:

alias find='lfsdllgfsdfnsdfjskjs'

Then put this as the contents of the file t.sh:

Code:

#!/bin/sh
alias find

and on the command line execute

Code:

sh t.sh

I get as its output

Code:

bash: alias: find: not found

which proves that shell script files do not inherit aliases from their parent shell, at least on my systems.

Since my cs.sh file does not use any internal aliases, either explicitly or implicitly (e.g. by sourcing .bashrc or something), it should be immune from aliases.

If it was vulnerable to aliases, then the way that I would temporarily suppress them is by encasing all commands inside single quotes (e.g. 'find'), an idea that I got from
Alias (Unix shell - Wikipedia, the free encyclopedia)


2) I have been struggling for a while now to understand why you think that hardcoding full command paths inside a script--which will require a decent percentage of users to have to open the shell file and understand it and then modify it--is easier than having the user modify their path if there are issues with, say, the find command.

I stand by my approach, particularly for who my target is with this shell script (primarily script developers, not the general user).

But I now think that I can see maybe where you are coming from: are you a sys admin at a large company? Or at least a sys admin on a machine with many different user accounts but whose system level configuration (e.g. where the commands are installed) you control? Or maybe you simply always use the same unix variant so that you reliably know what paths to use. In this case, if you are responsible for writing a shell script that has to work for all your different users, then I can see why you use hard coded paths.


3) Security:
That sounds crazy! I use relative paths, for example, in all kinds of programming applications and they are utterly invaluable (e.g. in having a configuration that always works regardless of where the user installs my package). I cannot imagine that too many companies have a policy that anything other than full paths is a security hazard.