Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-Id: <3.0.5.32.20030417220115.007fa520@incoming.verizon.net>
X-Sender: vze1u1tg AT incoming DOT verizon DOT net
Date: Thu, 17 Apr 2003 22:01:15 -0400
To: Andrew DeFaria <ADeFaria AT Salira DOT com>, cygwin AT cygwin DOT com
From: "Pierre A. Humblet" <Pierre DOT Humblet AT ieee DOT org>
Subject: Re: Problem in executable file mechanism
In-Reply-To: <3E9EEBD3.5070305@Salira.com>
References: <20030416163529 DOT GQ11137 AT cygbert DOT vinschen DOT de>
 <Pine DOT GSO DOT 4 DOT 44 DOT 0304161257120 DOT 2150-100000 AT slinky DOT cs DOT nyu DOT edu>
 <20030417090005 DOT GU11137 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:00 AM 4/17/2003 -0700, Andrew DeFaria wrote:

>Couldn't exec (shouldn't exec) stat /usr/bin/ls as expected but then see 
>that that is a directory and then continue on in the algorithm to stat 
>/usr/bin/ls.exe? Again, just because you found a candidate (/usr/bin/ls) 
>does not mean that you should necessarily attempt to run it (i.e. run a 
>directory!).

This is a topic with many twists. There are two ways to look at the problem:
either make it the job of the shells, or the job of Cygwin. 

There is code in bash and sh (ash) to do what you describe, but the code in
bash is not enabled and sh only makes a partial attempt. These programs do
no always check for directories and there are other inconsistencies, e.g.: 
http://cygwin.com/ml/cygwin/2003-04/msg00471.html

Cygwin is also capable of searching for .exe, and does it for stat:
~: strace ls ~/xyz

 3508  180522 [main] ls 434 symlink_info::check: GetFileAttributes (h:\xyz) failed
  431  180953 [main] ls 434 geterrno_from_win_error: windows error 2 == errno 2
 1006  181959 [main] ls 434 symlink_info::check: GetFileAttributes (h:\xyz.exe) failed
  368  182327 [main] ls 434 geterrno_from_win_error: windows error 2 == errno 2
17716  200043 [main] ls 434 symlink_info::check: GetFileAttributes (h:\xyz.exe.lnk) failed
  398  200441 [main] ls 434 geterrno_from_win_error: windows error 2 == errno 2
 1102  201543 [main] ls 434 symlink_info::check: GetFileAttributes (h:\xyz.lnk) failed

One might have expected xyz.lnk to be searched before xyz.exe.lnk, as xyz is searched 
before xyz.exe. The current order has a perverse effect:

~/temp: ln -s foo xyz
~/temp: ln -s bar xyz.exe
~/temp: ls -l
total 0
lrwxrwxrwx    1 pierre   unknown        86 Apr 17 20:13 xyz -> bar
lrwxrwxrwx    1 pierre   unknown        86 Apr 17 20:13 xyz.exe -> bar

Note that xyz.exe masks xyz. However "rm xyz" works as expected because there is
no search for unlink, nor for most other system calls.

When it comes time to spawning a process, Cygwin behaves differently. 

~: strace bash -c ~/xyz
 2778  975580 [main] bash 258 symlink_info::check: GetFileAttributes (h:\xyz.exe) failed
  445  976025 [main] bash 258 geterrno_from_win_error: windows error 2 == errno 2
 2561  978586 [main] bash 258 symlink_info::check: GetFileAttributes (h:\xyz) failed
  388  978974 [main] bash 258 geterrno_from_win_error: windows error 2 == errno 2
 1477  980451 [main] bash 258 symlink_info::check: GetFileAttributes (h:\xyz.exe.lnk) failed
  370  980821 [main] bash 258 geterrno_from_win_error: windows error 2 == errno 2
 1042  981863 [main] bash 258 symlink_info::check: GetFileAttributes (h:\xyz.lnk) failed
 1331  983194 [main] bash 258 geterrno_from_win_error: windows error 2 == errno 2
  722  983916 [main] bash 258 symlink_info::check: GetFileAttributes (h:\xyz.lnk) failed

Note that .exe is searched first, the order with .lnk is as expected, 
but now xyz.lnk is searched twice.

It's because of the spawn search order that the following works:
~> mkdir /bin/date
~> bash -c /bin/date
Thu Apr 17 17:27:44 EDT 2003       although
~> date
bash: date: command not found      

Note that bash spawns without checking if /bin/date is a directory.
Not all shells are so permissive:
~> ksh -c /bin/date
ksh: /bin/date: cannot execute - Permission denied

If the Cygwin search order in stat was changed to match that in spawn, xyz.exe
would be found before xyz. The price is that xyz.exe would mask xyz in ls,
which could be very misleading.

So IMO the way to improve the situation is to work on the shells, PTC.
Or follow Corinna's advice: don't do it.

Pierre


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/