Date: Mon, 1 Dec 1997 21:04:22 -0500 (EST)
Message-Id: <199712020204.VAA03253@delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: bcurrie AT tssc DOT co DOT nz
CC: djgpp-workers AT delorie DOT com
In-reply-to: <3483625B.601C@tssc.co.nz> (message from Bill Currie on Tue, 02
	Dec 1997 14:20:27 +1300)
Subject: Re: Possible enhancements on v2.02
Precedence: bulk


> DJ Delorie wrote:
> > If we enable LFN during startup, it should ONLY be for finding the
> > djgpp.env file.  Expanding wildcards with it is a bad idea, as long as
> > the short names can still be used after we switch to LFN.
> 
> By this, do you mean: wildcard expansion is SFN only; or wildcard
> expansion will be LFN iff LFN=y?  Your statement is a little ambiguous.

I mean that any changes this time around should affect only the
finding and reading of djgpp.env, and that I don't recommend doing
anything to change any other LFN functionality during startup until we
discuss and understand the ramifications.  Caution is advised.

> However, I agree that if djgpp.env turns off LFN, wildcards should be
> expanded using SFN.

Once djgpp.env is read, we have enough information to proceed with
whatever LFN settings the user wants, unless the application needs to
force LFN on or off for some reason.  We need to understand how these
settings and overrides relate before we make changes.