Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Date: Thu, 26 Oct 2000 13:48:06 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT sources DOT redhat DOT com
Subject: Re: ash and executable files (Was: sometimes ash does not like a.out)
Message-ID: <20001026134806.A32324@redhat.com>
Reply-To: cygwin AT sources DOT redhat DOT com
Mail-Followup-To: cygwin AT sources DOT redhat DOT com
References: <200010261511 DOT RAA18344 AT ubac DOT inrialpes DOT fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.6i
In-Reply-To: <200010261511.RAA18344@ubac.inrialpes.fr>; from Hubert.Garavel@inrialpes.fr on Thu, Oct 26, 2000 at 05:11:04PM +0200

I've mentioned in other email that you can use mount's '-x' option to
either mount individual files or directories.  That will force the
executable bit on for the file or directory.

I appreciate that you seem to have given this a lot of thought but,
if this is important to you, then a patch is what is required.  This
mailing list is great because DJ, Corinna, and I all are responsive
and fix problems.  That does not mean that we are available to make
suggestions into reality.

Ideas are wonderful.  Everybody is filled with good ideas.  Actual
work is scarce.  Especially in this mailing list.

So, you have the sources.  Go nuts.

cgf

On Thu, Oct 26, 2000 at 05:11:04PM +0200, Hubert Garavel wrote:
>It was reported recently that using "sh" to build RCS does not work 
>because "sh" refuses to execute a file named "a.out". 
>
>This is again the same problem I reported on September, 29 
>( see http://sources.redhat.com/ml/cygwin/2000-09/msg01019.html )
>
>    /bin/sh.exe fails to execute a binary program
>    that has no ".exe" extension, if the pathname
>    used to invoke his executable program contains
>    at least one slash.
>
>Chris Faylor answered wisely that "sh" does not execute files if 
>they do not have the executable bit set. On FAT partitions, this bit  
>is always 0ff if the file has no ".exe" extension. On NTFS, this
>bit can also be set if CYGWIN=ntsec and a "chmod +x" is done.
>( see http://sources.redhat.com/ml/cygwin/2000-09/msg01022.html )
>
>This solution is not satisfactory, although I understand that it 
>is difficult to emulate the executable bit on FAT partitions that 
>do not support it. 
>
>Using "CYGWIN=ntsec" could do the job. But there are still many FAT
>partitions and everyone would prefer a Cygwin solution that works
>identically on both FAT and NTFS.
>
>Drawbacks of the current approach
>---------------------------------
>
>1/ It causes a lot of confusion, as proven by the recent discussion
>   on RCS build. Traditional Unix users do not understand why
>   a binary program named "a.out" cannot be launched by "sh"
>
>2/ Relying on the ".exe" suffix to set the executable bit gives strange 
>   (non-POSIX?) behaviours. For instance, when executing:
>	mv program.exe new_program.out
>   the program.exe loose its executable bit, although "mv" is not 
>   supposed to modify the stat attributes.
>
>Solution 1 : modify the implementation of stat()
>------------------------------------------------
>
>A solution would be to refine the implementation of stat()
>to check the contents of the file, in addition to its ".exe"
>extension. The executable bit would be set to 1: 
>
> - if the file has an ".exe" extension
>
> - but also if the first bytes of the file look like a Win32 executable
>
>  - if the file starts with "!#" (which probably indicates a Unix shell)
>
>This would be similar to the file(1) command, which tries to guess the
>type of a file by a quick analyzis of its contents.
>
>This approach might slow down all calls to stat(), fstat(), etc. 
>
>Solution 2 : keep stat() as is, but improve /bin/sh.exe
>-------------------------------------------------------
>
>If stat() remain unchanged, then "sh.exe" should be improved, because
>this is the main place where the approximation on the executable bit
>creates troubles.
>
>Notice first that "sh.exe" has problems, but "bash.exe" doesn't.
>
>Example: if you type the following commands
>	cp /bin/echo.exe /tmp/echo.out 
>	/tmp/echo.out foo
>in a bash window, bash will display "foo". If you give the same
>commands to "sh", you will get an error message 
>	"/tmp/echo.out: not found"  
>
>Therefore, it seems reasonable to modify "sh.exe" in order to
>make it compatible with "bash" and to avoid the confusion
>created by the annoying "not found" messages.
>
>The change should probably took place in the find_command() 
>of the "exec.c" module of "sh". Currently, if the name of
>the file contains a slash, "sh" checks that the file exists, 
>is regular, and is executable. The "executable" condition
>should be relaxed, by being aligned with the strategy used
>in bash.exe.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com