ash and executable files (Was: sometimes ash does not like a.out)

[Hubert Garavel <Hubert dot Garavel at inrialpes dot fr>]

Dear all,

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.

Best regards
Hubert

-- 
',',',',',',',',',',',',' Hubert GARAVEL           | INRIA Rhone-Alpes / VASY
',',',',',',',',',',',',' hubert.garavel@inria.fr  | 655, avenue de l'Europe
',',',',',',',',',',',',' tel: +(33) 4 76 61 52 24 | 38330 Montbonnot St Martin
',',',',',',',',',',',',' fax: +(33) 4 76 61 52 52 | France
',',',',',',',',',',',',' http://www.inrialpes.fr/vasy


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com