Date:	Wed, 24 May 2000 13:14:37 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Mark E." <snowball3 AT bigfoot DOT com>
cc:	DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject:	Re: __dosexec_find_on_path question
In-Reply-To:	<392AE5B3.18142.1DADEC@localhost>
Message-ID:	<Pine.SUN.3.91.1000524131310.13642G-100000@is>
MIME-Version:	1.0
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

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?).

- Raw text -