Date:	Sun, 28 Mar 1999 14:23:44 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Bash 2.03 update (March 19th)
In-Reply-To:	<Pine.LNX.3.93.990326162327.16984G-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.990328142327.22925N-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Fri, 26 Mar 1999, Hans-Bernhard Broeker wrote:

> > You cannot do that on LFN systems, because `program' might be actually
> > something like `foo.bar.bat', and to further complicate matters, there
> > might be a program in the same directory called `foo.bar.bat.exe'.  
> 
> That's funny, indeed. OTOH, the traditional method is to not search for
> any of the .com/.exe/.bat at all, if the program had been called with the
> full filename, including extension.

libc still behaves this way, but only on non-LFN systems.  Under LFN,
it tries to append extensions first, since LFN systems aren't limited
to a single dot in the trunk of a file name.

> I.e.  calling 'foo.bat' would start foo.bat, even if foo.com exists.

We are compatible with this.  If you call `foo.bat', and there's no
`foo.bat.{exe,com,bat,sh,...}', `foo.bat' *will* be called, and
`foo.com' will *never* be called.

> By extension, that'd mean that if I call `foo.bar.bat' and that file
> exists, it should definitely be executed, and not `foo.bar.bat.exe'. 

Sorry, we disagree here.  There's nothing magic about `.bat',
especially since we could be talking about a Unix program that invokes
some `foo.bat' where in our case we have `foo.bat.exe'.  Under LFN, a
dot is just like any other file-name character, so `foo.bat' should be
processed like e.g. `foo-bat' would.

- Raw text -