Date: Fri, 06 Apr 2001 10:51:50 +0200
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: <9003-Fri06Apr2001105150+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: djgpp-workers AT delorie DOT com
In-reply-to: <3ACD0321.18747.214DE3@localhost> (snowball3@bigfoot.com)
Subject: Re: system() and SHELL patch
References:  <3ACD0321 DOT 18747 DOT 214DE3 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." <snowball3 AT bigfoot DOT com>
> Date: Thu, 5 Apr 2001 23:43:29 -0400
> 
> This patch treats the SHELL variable like __spawnve treats a file starting 
> with "#! /bin/sh": if an executable extension can't be added, then PATH is 
> searched.

This change should be extensively tested, at least when linked into
Make and Bash, to see that it doesn't break anything.  Make (and some
other programs which invoke subordinate processes) do some
manipulations of their own with SHELL's value, and this change should
not break them.

I'd suggest to use Make and Bash linked with this change to build
several complicated GNU packages, such as Binutils and GCC, and also
Emacs, at the very least.  The former two packages use /bin/sh as
their shell while Emacs insists on using COMMAND.COM.

One comment I have right away is that perhaps this special treatment
should be only reserved for Unixy shells, of maybe for shells whose
names we know.  What if someone says "set SHELL=foobar" and you find
foobar.bat on the PATH or in the current working directory?

> I noticed that the command processor is figured out both in system
> and _shell_command. This seems unneccessary, but I did nothing about
> it since there may be a valid reason for doing it twice.

I don't remember whether there's any special reason, but it's probably
best not to make any changes in that mess, unless we think it's
necessary ;-)

> !   char unixy_shell[FILENAME_MAX];

Please don't use unixy_shell as the name of this variable: it's
misleading.  All we know at this stage is that we found the shell
along the PATH.