Date: Tue, 02 Sep 1997 10:44:08 +1100 From: Bill Currie Subject: Re: Rebuilding gcc - "c-parse.gperf" not found In-reply-to: <340a3b80.10574464@snews.zippo.com> To: pjfarley AT dorsai DOT org (Peter J. Farley III), djgpp AT delorie DOT com Message-id: <199709012249.KAA25368@teleng1.tait.co.nz gatekeeper.tait.co.nz> Organization: Tait Electronics Limited MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Comments: Authenticated sender is Precedence: bulk On 1 Sep 97 at 4:04, Peter J. Farley III wrote: > Wow! Now *that* is nice news to hear! Many thanks, friend. > > Let me repeat your statements, so I see if I understand them > correctly. Placing this entry in the registry under Win95 will > disable the creation of *initial* numeric suffixes (as with the > creation of a "longname" file that is the first of it's 8.3 flavor), > and files subsequent to the first of a given 8.3 name *will* result > in creation of 8.3 names with numeric suffixes (like ~1, ~2, etc.). Yes, this is correct. Hoever, be carefull with it, as there is one gotcha (trap): if you have a file called `Makefile.in.in' (goes to `MAKEFILE.IN') and you try to delete `Makefile.in', `Makefile.in.in' will be deleted. This happend to me when I tried to build gnu tar on my system. The configure script tried to build `Makefile.in' from `Makefile.in.in' but first would delete `Makefile.in', but because `Makefile.in' did not initially exist, `Makefile.in.in' had the short name `MAKEFILE.IN'. To me, this is an issue of bad design in the handling of long file names. I feel that when using the lfn calls, the shor file name should only ever be matched if there is no long file name for that file. Sigh, not to be I guess, and I suppose that's why numeric tails are on by default (had to turn them back on to build gnu tar). Just a warning. It doesn't happen often. Bill -- Leave others their otherness.