>> == me
> = reborg
(Only one level of quoting seems to be supported on this forum, so I am reverting to old usenet style attribution.)


>>Personally, I think that it should always be an error to use an uninitialized variable.
>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.

I feel more strongly that -n should always be on, or at least be the default behavior then I do about -u. I can live with -u not being on if every shell implementation has a standard behavior that it must adhere to (e.g. that an unitialized variable always has an empty string value, will never cause a null pointer exeception, etc). When you have problems is when different implementations subtly differ, which seems to be a major problem in the unix world (in contrast to, say, Java, which is properly stringent in implementation consistency). In cases like this, my experience is that it is better to be safe than sorry.


>>If I had written sh, it would not even be an option.
>Sorry I didn't follow you here.

I would not have set -n as an option to sh; set -n would be the default behavior. Possibly I -might- make set +n available if someone could convince me that there was a real need (e.g. performance increase) in some cases. As mentioned above, I would likewise have set -u be the default behavior unless the uninitialzed behavior is consistent and safe enough that this is not an issue. In which case I recant.


>>First, why would I ever want to use the full path to a command? That makes it totally unportable!...
>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.

Of course your script has to rely on the login environment to know where commands are--what else can it do, guess?

In the examples that you provide, you assumed that find (or a suitable version of find) is always found in /usr/bin/, but what if it isn't? Then your script is broken and the user will have to debug the script and fix it by hand.

If you instead rely on the PATH, it is a) far likelier that the user will have gotten things like having find on his path straightened out long before he runs this script and b) even if find is not there, he is much more likely to know how to do a generic unix task like fix his path then to debug and edit a custom script.


>The script will currently break if the user has a different command
>(or different non-compatible version of a command) with the same name
>as one of the ones you use in their PATH before the one you want

Assuming that /usr/bin/find exists and is the suitable version likewise is open to failure. No win there.


>or has a command aliased to behave in a way you don't expect which would be worse.

Agreed: aliases is one (the only?) failure mode that hard coding the path to find inside the script will overcome.

Unless the use has done something amazing, like alias find to rm or something, the worst that should happen in this script if they have aliased find is that it does not work correctly.

Is there a good way to detect if a command is actually being aliased? And to unalias it, at least inside the script, and use the raw command?

Actually, now that I think more on this, if you really think that aliases are a dangerous failure mode then you have to go to extreme lengths to cope with it. For instance, with the cs.sh script that I have presented so far, you not only need to worry about the find command being aliased, but you need to worry about every single other command in that script which could also be aliased: set, echo, while, read... Its basically impossible! Larry Wall was right about it being easier to write a new shell than to port (or guarantee the correct working of) a shell script.


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

Right: I mistyped.


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

I think that the complete command that I want (for dir = "./") is more like

Code:

find "./" -nowarn \( ! -name "./" -prune \) | grep \.sh

That -nowarn option is critical, else you always get this nasty warning message (at least with GNU find):

find: warning: Unix filenames usually don't contain slashes (though pathnames do). That means that '-name `./'' will probably evaluate to false all the time on this system. You might find the '-wholename' test more useful, or perhaps '-samefile'. Alternatively, if you are using GNU grep, you could use 'find ... -print0 | grep -FzZ `./''.

But it appears that -nowarn is not a POSIX option, so we are back to square one...


>It has little or nothing to do with laziness.
>It is more effort for the programmer to write the message

The "more effort for the programmer" is the laziness that I referred to.

And its actually not all that much extra effort, assuming you are actually doing the right thing and argument checking your code, because at that point you already have all the conditional logic put in; you simply need to notify the user too when things go wrong. But if you have done no arg checking and just blindly proceed, then yes it is more work.


>...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:

I agree: decent behavior is to print both the specific error, as well as to print proper usage. The version of the script file in my next post below does this. You were also correct in saying that the proper usage should be printed out somehow (I chose to write a function to do this) then to merely store it as program comments.


>>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?
>Yes.

>>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.
>bourne derived shells such as ksh and bash do.

The version of the script file presented in my next post below retains searching for .sh files and assumes that whatever actually shell is executing it (and hence will be doing the syntax checking) is also a shell that is compatible with all the other .sh files.

For instance, on both my cygwin and linux boxes, the shell is actually bash, and its syntax checker seems to have no problem with bash (but not bourne) constructs like [[ in .sh files.

At this point, I think that this is the most reasonable approach, even if it is not a cure all.


Writing a POSIX compatible find seems to be the hangup; my newbie scripting skills are not up to it.