Date: Thu, 11 Oct 2001 09:58:23 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Van Holder cc: djgpp-workers AT delorie DOT com Subject: Re: First round of XP tests In-Reply-To: <1002781857.1294.23.camel@bender.falconsoft.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 11 Oct 2001, Tim Van Holder wrote: > > 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? I'm not sure I follow: the packaged binary distribution of the DJGPP port doesn't have any _emacs file. There's an example init file called _emacs.xmpl, but Emacs doesn't know about it; you need to rename it to use it. > So our emacs uses HOME=$DJDIR/gnu/emacs by > default? More accurately, it uses $SELFDIR/../, where SELFDIR is where emacs.exe lives. If you unzip the binaries from DJDIR, then $DJDIR/gnu/emacs is the default place. > > > 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? Our libc by default downcases all the 8+3 names (inside readdir, in this case). > 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). That's something private to the Explorer; the OS itself simply returns what's recorded in the directory. That is why we downcase the DOS names: many of them are recorded in UPPER case. > 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. That's too far fetched, especially when dealing with MS OSes ;-) Anyway, you can use -iname if you want case-insensitive search.