U/L case screwup

After a great deal of work, I finally found the source of a bug in a
script that has worked on lots of other unixoid systems. I wrote a
little wrapper around the find command, and called it Find. When I
ran it on OSX, it went berserk, flooding the system with as many find
and sh processes as it could. The tipoff about what was going wrong
was when I added a "which find" command to the script, and it told me
"/Users/jc/sh/find". WTF? There should be no such file; it's called
"/Users/jc/sh/Find". Finally I did this:

: ls -il sh/?ind
343724 -rwxr-xr-x 1 jc staff 350 Jul 19 23:16 sh/Find
: ls -il sh/[Ff]ind
343724 -rwxr-xr-x 1 jc staff 350 Jul 19 23:16 sh/Find
: ls -il sh/Find sh/find
343724 -rwxr-xr-x 1 jc staff 350 Jul 19 23:16 sh/Find
343724 -rwxr-xr-x 1 jc staff 350 Jul 19 23:16 sh/find
:

AHA! File 343724 is singly linked, but it matches both names. A shell
wildcard only finds the "Find", but ls finds both of them, with the same
inode number and only one link. And even worse, when /bin/sh looks for
the "find" command in $PATH, it finds a match with "/Users/jc/sh/Find".

So something somewhere in OSX is doing case-insensitive file matching,
and when my "Find" script tries to run the "find" command, it instead
recursively calls itself.

Is there a fix for this? Can OSX be made to do correct case-sensitive
matching, so that scripts from other systems run the command that they
think they're running?

This is a real showstopper ...

John Chambers <jmchambers.DeleteThis@rcn.com> wrote:
 > After a great deal of work, I finally found the source of a bug in a
 > script that has worked on lots of other unixoid systems. I wrote a
 > little wrapper around the find command, and called it Find. When I
 > ran it on OSX, it went berserk, flooding the system with as many find
 > and sh processes as it could. The tipoff about what was going wrong
 > was when I added a "which find" command to the script, and it told me
 > "/Users/jc/sh/find". WTF? There should be no such file; it's called
 > "/Users/jc/sh/Find". Finally I did this:

 > : ls -il sh/?ind
 > 343724 -rwxr-xr-x 1 jc staff 350 Jul 19 23:16 sh/Find
 > : ls -il sh/[Ff]ind
 > 343724 -rwxr-xr-x 1 jc staff 350 Jul 19 23:16 sh/Find
 > : ls -il sh/Find sh/find
 > 343724 -rwxr-xr-x 1 jc staff 350 Jul 19 23:16 sh/Find
 > 343724 -rwxr-xr-x 1 jc staff 350 Jul 19 23:16 sh/find
 > :

 > AHA! File 343724 is singly linked, but it matches both names. A shell
 > wildcard only finds the "Find", but ls finds both of them, with the same
 > inode number and only one link. And even worse, when /bin/sh looks for
 > the "find" command in $PATH, it finds a match with "/Users/jc/sh/Find".

 > So something somewhere in OSX is doing case-insensitive file matching,
 > and when my "Find" script tries to run the "find" command, it instead
 > recursively calls itself.

 > Is there a fix for this? Can OSX be made to do correct case-sensitive
 > matching, so that scripts from other systems run the command that they
 > think they're running?

 > This is a real showstopper ...

OS X does case insensitive matching on a HFS+ filesystem, it is case
preserving only. The only way around this is to use an UFS filesystem,
but that will break a number of Mac OS functions. You would be better
off to rethink your design so as not to depend on case sensitive matches
when using your "Find" for OS X.

Joe Heimann<!-- ~MESSAGE_AFTER~ -->