Date: Wed, 24 May 2000 13:14:37 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: "Mark E." cc: DJGPP Workers Subject: Re: __dosexec_find_on_path question In-Reply-To: <392AE5B3.18142.1DADEC@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Tue, 23 May 2000, Mark E. wrote: > + /* Index to stop trying to add extensions. Just as 'foo' will match > + 'foo.exe' to emulate DOS shells, 'foo' will not match 'foo.sh' > + to emulate Unix shells. */ > + static const int ext_append_stop = 4; This creates a linkage between the order of looking for extensions (to find the appropriate interpreter) and the extensions that we append by default before looking for the name without the extension. Is it a good idea to introduce such a dependency? What if we will need to change the order of the interpreters[] array some day? Perhaps a better solution would be to add another member to the structure, a flag that says whether to consider this extension before the trunk. Comments? I would also ask people to think and/or check whether any program or function they know about relies on the present behavior, whereby looking for `foo' will find `foo.sh', `foo.pl', etc. if they exist. I don't think there are such programs, but if they do exist, we need to consider whether it is worth breaking them. One place where this change will show is in "test -x", at least in the stand-alone test.exe from Sh-utils (does Bash's built-in call __dosexec_find_on_path as well?).