Date:	Fri, 06 Jul 2001 12:23:58 +0300
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	"Mark E." <snowball3 AT bigfoot DOT com>
Message-Id:	<6480-Fri06Jul2001122358+0300-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<3B44DBB0.9188.1772CD@localhost> (snowball3@bigfoot.com)
Subject:	Re: dosexec.c changes
References:	<3B44DBB0 DOT 9188 DOT 1772CD 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

> From: "Mark E." <snowball3 AT bigfoot DOT com>
> Date: Thu, 5 Jul 2001 21:27:12 -0400
> 
> Below are the changes I've made so far to dosexec.c and I'd like to
> see if I'm headed in the right direction.

I think the direction is right.

> I don't care too much for the spawnvx interface.

I wonder why do we need it at all.

> My preference would be to call something distinctive like
> __djgpp_spawn and allow more flexibility by (just brainstorming
> here...) allowing a flag to dictate the type of search, an
> interpreter hint (for example, Bash will have already discovered
> what interpreter is needed to handle an extensionless
> file). Comments?

I'd say, rename __spawn_internal to __djgpp_spawn, and add flags and
additional arguments for whatever you need.

As for the interpreter discovered by Bash: if we want to bypass
script_exec, I think we should make sure Bash supports the same
features as script_exec does.  It would be bad if scripts behaved
differently when invoked via spawn/system or via Bash.

I also am not sure why this particular case is relevant to the issue
we were discussing: if Bash wants to invoke the interpreter directly,
it can do so by calling dosexec with "/foo/bar/interp.exe -f script"
instead of just "script".  In the former case, script_exec will never
be called, I think.

> /* for libc/dosexec.h */
> #define SPAWN_FLAG_EXT_SEARCH    0
> #define SPAWN_FLAG_INTERP_SEARCH 1

A flag that's zero is a no-op, so it's probably not needed at all.
See below about SPAWN_FLAG_INTERP_SEARCH.

>   /* Perform an extension search when the flag SPAWN_INTERP_SEARCH is not
>      present.  If LFN is supported on the volume where rpath resides, we
>      might have something like foo.bar.exe or even foo.exe.com.
>      If so, look for RPATH.ext before even trying RPATH itself.
>      Otherwise, try to add an extension to a file without one.  */
>   if (!(flags & SPAWN_FLAG_INTERP_SEARCH))

I can't say I like the reverse logic.  If the flag is called
SPAWN_FLAG_INTERP_SEARCH, then its presence, not its absence, should
trigger the interpreter search.  Since the flag variable isn't static,
I see no reason to reverse the logic: the standard spawn* functions
could simply invoke __spawn_internal with a non-zero flag.

- Raw text -