Date: Fri, 06 Jul 2001 12:23:58 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Mark E." 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 Precedence: bulk > From: "Mark E." > 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.