Date: Sun, 28 Mar 1999 14:23:44 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Hans-Bernhard Broeker cc: djgpp-workers AT delorie DOT com Subject: Re: Bash 2.03 update (March 19th) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.