delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2015/02/12/05:29:42

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:message-id:date:from:mime-version:to:subject
:references:in-reply-to:content-type:content-transfer-encoding;
q=dns; s=default; b=RSlXubVVtuO7QH/Wu96mW+lqnaR1nc64K0z1uQcrpyM
iG1eerHMlg5sAWIHBEK0nLbMpnaINIEdRhvCHbWFLilaIRsZtN6fvIWunkgjqAJ4
wI5QmOZ29jDEwShe6mA1H/AG+gdtAYTjfVDDwsYzs2BNdjyh+91xw1Yvn8iWHu7o
=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:message-id:date:from:mime-version:to:subject
:references:in-reply-to:content-type:content-transfer-encoding;
s=default; bh=iQhMJaAKQw3cPD03gNnO53SrtWc=; b=NNCqU4uRAY8IAWmYv
bGWIMgEPXxS9nMAyToHSLJMDveK/vEVOGAtWP54p0pMZ8CEMGCivRc4ypUP69d13
iIJOBWPH1fJb9LRloFcak+7TzUIQiTjVjaUFzdVdsdKIAtb7JI5h3+Lvv2VQeBp+
zWwt9Dh/6s+bV9aloFGv3trLAg=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.2
X-HELO: demumfd001.nsn-inter.net
Message-ID: <54DC804A.3020008@towo.net>
Date: Thu, 12 Feb 2015 11:28:26 +0100
From: Thomas Wolff <towo AT towo DOT net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: execlp/execvp needs case-correct PATH
References: <54D7EB8E DOT 8070308 AT towo DOT net> <20150209101747 DOT GA12131 AT calimero DOT vinschen DOT de> <54D91D54 DOT 5000705 AT towo DOT net> <20150210092756 DOT GC15989 AT calimero DOT vinschen DOT de> <54DA5890 DOT 8060609 AT towo DOT net> <20150211132810 DOT GI7818 AT calimero DOT vinschen DOT de>
In-Reply-To: <20150211132810.GI7818@calimero.vinschen.de>
X-TagToolbar-Keys: D20150212112826244
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2642
X-purgate-ID: 151667::1423736907-00007286-98D0A668/0/0
X-IsSubscribed: yes

On 11.02.2015 14:28, ext Corinna Vinschen wrote:
> On Feb 10 20:14, Thomas Wolff wrote:
>> Am 10.02.2015 um 10:27 schrieb Corinna Vinschen:
>>> On Feb  9 21:49, Thomas Wolff wrote:
>>>> Am 09.02.2015 um 11:17 schrieb Corinna Vinschen:
>>>>> On Feb  9 00:04, Thomas Wolff wrote:
>>>>>> With a Windows case sensitive file system (and according mount flags
>>>>>> for /cygdrive), the PATH does not properly reflect casing of the actual
>>>>>> directories (e.g. C:\WINDOWS vs. C:\Windows, thanks MS...).
>>>>>> However, the shell finds programs anyway, like e.g. notepad.
>>>>>> The exec*p system calls, on the other hand, do not find a program in this
>>>>>> case as demonstrated by the attached test program.
>>>>>> This is in contrast to the Linux (and POSIX?) manual page which claims
>>>>>> „The execlp(), execvp(), and execvpe() functions duplicate the actions
>>>>>> of the shell in searching for an executable file …“
>>>>> ...
>>>> Sorry, I forgot one detail: I added /cygdrive/c/Windows/System32 to my path
>>>> so the shell will find it, but yet execlp does not find it.
>>> Which makes sense, given that notepad is not in C:\Windows\System32, but in C:\Windows.
>> On my systems (Windows 7 Professional/Ultimate) it’s in both C:\Windows and
>> C:\Windows\System32
>> (otherwise the shell wouldn’t have found it after adding to the path).
>>
>> However, I could resolve the issue partly by putting
>> /cygdrive/c/Windows (or ../System32) in the path *before* the bogus
>> /cygdrive/c/WINDOWS - weird, but this way exec*p works.
>>
>> With the old setting (bogus first in path), apparently/assumedly exec*p
>> somehow finds the file in /cygdrive/c/WINDOWS but then cannot start it from
>> there because of the case mis-match.
>> There’s still the inconsistency with shell behaviour.
> I found the cause.  The function searching for executables in $PATH was
> searching on the Win32 PATH variable.  The underlying conversion
> functionality treats Win32 paths with default flags.  I revamped the
> search function to iterate over the POSIX PATH variable so the
> posix=[0|1] mount flag is taken into account.  As a nice side effect,
> the search function is mow much simpler and easier to understand.
>
> I tested this new stuff in a variety of situations, but there's still
> the chance that I missed something.  So this needs a good, sturdy testing.
>
> I just uploaded new snapshots to the usual place:
> https://cygwin.com/snapshots/
>
> Please give it a try.
Excellent, thank you. I also tested with ping vs. PING vs. PING.EXE and 
behaviour is consistent.
------
Thomas

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019