From: "Mark E." To: djgpp-workers AT delorie DOT com Date: Fri, 6 Jul 2001 15:00:54 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Subject: Re: dosexec.c changes Message-ID: <3B45D2A6.11785.CA64A0@localhost> In-reply-to: <6480-Fri06Jul2001122358+0300-eliz@is.elta.co.il> References: <3B44DBB0 DOT 9188 DOT 1772CD AT localhost> (snowball3 AT bigfoot DOT com) X-mailer: Pegasus Mail for Win32 (v3.12c) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by delorie.com id PAA01794 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 > 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 does. I've added a check for files that don't begin with '#!' to return ENOEXEC because script_exec doesn't know how to deal with those files. Bash then invokes itself with the name of the script as argv[1] which is much like script_exec does. And in the portion of the posix draft dealing with the exec* family, it now requires similiar handling of executables like shell scripts: 9866 One common historical implementation is that the execl(), execv(), execle( ), and execve() functions return an [ENOEXEC] error for any file not recognizable as executable, including a shell script. When the execlp( ) and execvp( ) functions encounter such a file, they assume the file to be a shell script and invoke a known command interpreter to interpret such files. This is now required by IEEE Std 1003.1-200x. These implementations of execvp( ) and execlp( ) only give the error in the rare case of a problem with the command interpreter’s executable file. I think this new requirement can be applied to djgpp by having script_exec use SHELL for the program to run if it can't find a hash bang line. Any problems with my interpretation? Mark