Date: Tue, 23 May 2000 16:42:19 -0400 (EDT) Message-Id: <200005232042.QAA29181@indy.delorie.com> From: Eli Zaretskii To: "Mark E." CC: djgpp-workers AT delorie DOT com In-reply-to: <392A8F46.19672.2E4043@localhost> (snowball3@bigfoot.com) Subject: Re: __dosexec_find_on_path question References: <392A8F46 DOT 19672 DOT 2E4043 AT localhost> 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 > From: "Mark E." > Date: Tue, 23 May 2000 14:01:42 -0400 > > I've been using __dosexec_find_on_path in my Bash 2.04 beta to find disk > commands. But when LFN is available, a search for "autoconf" will return > "autoconf.sh" when both "autoconf" and "autoconf.sh" are both in the same > directory in a PATH. This causes 'spawnve (P_WAIT, "autoconf", args, env)' to > execute autoconf.sh instead of autoconf. Is this the way it's supposed to > work? Yes, this is how it was intended to work. It favors the files with extensions due to 2 reasons: (1) when you have `foo' (a raw COFF image) and `foo.exe', you want the latter, because it doesn't need go32-v2 to run; and (2) under LFN you might have foo.bar and foo.bar.exe, so the only way to find foo.bar.exe is to try with the extension first. In addition, DOS seems to work this way as well. Neither of these reasons is relevant to your case. It's possible that we don't want the .sh extension to be recognized automatically in the same manner as we do with .exe and .com. So perhaps we need to exclude all the extensions except .bat, .com, .exe, and .btm from that search.