Mail Archives: djgpp-workers/2001/10/11/02:34:49
> > using a batch file just feels more hackish.
>
> That's hardly a nice thing to say to someone who put a great deal of
> effort into getting that batch file as reliable and portable as
> possible.
It was no reflection on the quality of the batch file involved; I just
feel more comfortable running _a_ configure script, than I do _a_
config.bat file. It's a completely irrational feeling, I know; that
doesn't make it go away though. Guess I need some therapy :-)
> If djgpp.env sets HOME, every program that a DJGPP program invokes
> will inherit that setting. Since many non-DJGPP programs could react
> to that in surprising ways, I don't think we should define HOME unless
> it's absolutely required. Emacs does that because many Emacs packages
> will crash and burn without HOME, and because it needs some reasonable
> place to look for the _emacs startup file.
That's another thing; besides the fact that 'make install' currently
doesn't work properly, emacs isn't loading _emacs, even though it's in
the location specified by $HOME. Another potential XP bug.
I'll look into it later in the week.
> If you (and Mark) think that Bash needs HOME as well, let's define
I suppose 'need' is exaggerated; it uses it for some thinks (like a
plain 'cd', which changes directory to $HOME).
> HOME in the [bash] section. But doing so globally would be IMHO a
> mistake; in particular, it will instantly break almost every Emacs
> installation out there, since Emacs defines HOME to point to its
> installation directory (if the user didn't define otherwise).
Which is only a problem because the DJGPP package of emacs puts it in
gnu/emacs/bin, right? So our emacs uses HOME=$DJDIR/gnu/emacs by
default?
> > find '*.cvs' returns nothing, find '*.CVS' returns the list of
> > '_.CVS' files in the tree.
>
> That sounds like a bug.
Well, yes and no, I guess. Is it WinME that reports all-uppercase,
non-LFN names as lowercase, or is it our libc?
If the former, it's subject to change; Win98 (I think) introduced the
option for Explorer to actually show all-uppercase names as such
(instead of capitalized). So if XP returns all filenames 'as is', that
is really OK, as those are the actual names, not names that happen to
map onto the same file due to case insensitivity.
> > Since the filesystem is case insensitive, name comparisons done by
> > find should be case insensitive as well.
>
> No, `find' is case-sensitive, and the DJGPP port tries to behave the
> same, as much as this is possible.
Given that non-LFN DOS names are lowercased, this is just fine I
suppose.
> > find '*.cvs' returns
> >
> > ./z/z1/!.cvs
> > ./_.cvs
> >
> > on WinME, but nothing under WinXP; find -name '*.CVS' returns
> >
> > ./y/foo.CVS
>
> You may have found another XP bug; perhaps some other LFN-related
> system call is botched. Please consider looking into this.
Cfr. above, could be that XP returns the exact filename in all cases.
> > I can see a few cases where being so strict might be useful
> > (e.g. a find -name '*.S' might be intended to only return
> > asm-with-cpp files), but since the filesystem doesn't care, I
> > don't we should either.
>
> Why should `find' not care about the difference between *.s and *.S,
> when GCC and Make do? Don't you think it would be terribly confusing?
Because gcc/make have different rules for both those file types (as
horrible as using extensions that only differ in case is), and are
expected to process them accordingly.
But teaching find about filesystem limitations would be excessive I
guess; besides case insensitivity, it would also have to start caring
about 8+3 limitations.
I guess the point is what is perceived as find's goal. One way would be
to say that if I run "find foo -name 'BAR'" and it returns nothing, I
should be able to create a file called "BAR" in any (readable) directory
under foo without worrying about clobbering an existing file. This
would not necessarily hold true for our find (for many values of BAR).
If, on the other hand, find is merely supposed to return a list of files
with only the guarantee that the files returned exist, then our find
does OK (though it might possibly omit some files that would be included
under Unix).
> > Still, if 2K and XP return different values, that could be used to
> > distinguish them for W2K-only/WXP-only patches (AFAIK, currently
> > those simply check for 0x532).
>
> Alas, NT/W2K/XP don't let DOS programs access the Windows version.
> The function of Int 2Fh that's supposed to report the Windows version,
> and which works on Windows 3.X, 9X, and ME, simply fails on NT and its
> family, as if Windows were not there. In other words, Windows NT and
> its descendants want DOS programs to think they are running on plain
> DOS 5.
Hmm. Praise be to M$ for their infinite wisdom in OS design.
- Raw text -