Mail Archives: djgpp/2003/01/30/00:59:24
On Wed, 29 Jan 2003, Gary Hubbard wrote:
> The wildcard expansion is certainly not doing what I would expect.
Please explain why.
> I tried
> looking at the source and in the few minutes I have at the moment could not
> really make sense of the case sensitivity logic. Clearly the environment
> variable FNCASE is involved somehow. As near as I can determine
> empirically, setting FNCASE=N (the defaults neems to be Y), cause the
> matches to be case insensitive at the price of returning the names converted
> to upper case.
It's the other way around: the default for FNCASE is N, so matches are
mostly case-insensitive. If you set that to Y, they are case-sensitive.
> Somehow all of this seems to be strange to me. Since all Microsoft
> operating systems have case preserved but insensitive filenames
Yes, but the programs we use come from Unix, and Unix case-sensitivity is
in their blood, so to speak. For example, if you type "gcc foo.C", GCC
will compile foo.c as if it were a C++ program, not a C program (see the
FAQ for more about this). So DJGPP needs to emulate case-sensitivity to
some extent.
> it seems
> like the glob function should effectively convert the pattern each
> prospective filename match to lower case and then if fnmatch() succeeds, the
> original (un-lower cased) filename should be returned.
This doesn't work well in practice. The notable example where it breaks
is the DOS 8+3 file names that are stored IN CAPS in the directory
entries. If functions like `readdir' return the original file names, you
will see lots of caps in many directories. In particular, on plain DOS,
_all_ file names will be returned in caps, which will break Makefile's,
for example.
- Raw text -