X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD1DF3851371
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1670863095;
	bh=QYnohCIZmfue+hCHJ01PDwadlmaVEMYPyX1VqBQvUWc=;
	h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=mAh/x3J2glueqxtCYodQLu9Fd0Pq1V8o0bT+iMrCALMCnwhQor+kziikzQH+u2aak
	 ae3SMBO/wlYQOo0n8X9SoPnlFwz4KC5K/rQngyO24MyHqE+TbLxi/HMiHfdFWCZBPb
	 X34NSqjKD95yOM+JrGO7hEAPUwosca4pf+iY0CS0=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B074B385F3D2
Message-ID: <6dae8101-abe2-6ddc-9792-b38e1d689b9b@razorcat.com>
Date: Mon, 12 Dec 2022 17:40:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.1
Subject: Re: [EXTERNAL] Re: Strange behavior when executing programs
To: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
References: <1031eafe-fc3b-ab5b-6e63-b0f56c038332 AT razorcat DOT com>
 <Y5camvZ8vSCNwXUu AT calimero DOT vinschen DOT de>
 <DM8PR09MB709545D94DCD99F42D17D099A5E29 AT DM8PR09MB7095 DOT namprd09 DOT prod DOT outlook DOT com>
 <DM8PR09MB7095E6DC8CBBDEFCD5BE4C44A5E29 AT DM8PR09MB7095 DOT namprd09 DOT prod DOT outlook DOT com>
 <Y5dLjMP2xGa2UTtO AT calimero DOT vinschen DOT de>
Organization: Razorcat Development GmbH
In-Reply-To: <Y5dLjMP2xGa2UTtO@calimero.vinschen.de>
X-Df-Sender: ZnJhbmsucmVkZWtlckByYXpvcmNhdC5jb20=
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,
 RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE,
 TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Frank Redeker via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Frank Redeker <frank DOT redeker AT razorcat DOT com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>



Am 12/12/2022 um 4:41 PM schrieb Corinna Vinschen via Cygwin:
> On Dec 12 15:22, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>> Sorry about the earlier typos
>>
>>> (and, hence, I suppose for the purposes of the OP).
>>
>> and, hence, I suppose, *would work* for the purposes of the OP.
>>
>>> Since realpath is supposed to resolve all symlinks,
>>
>> I meant by default (the -P behavior).  If -s was asked, then the output would be corect.
> 
> Options are only available in realpath(1).  As for under the hood,
> realpath(3) has no options so it can only return one of the
> alternatives.
> 
> 
> Corinna
> 
I don't have a problem with *realpath* but with the fact that a native 
program in a cygwin or msys shell gives a different result than in a 
Windows CMD or older versions of cygwin and msys.

Consider the following simple sample unsing the WIN32 API. (Compiled 
with MinGW, Borland, Visual Studio, ....)

#include <windows.h>
#include <stdio.h>

int main(int argc, char ** argv) {
    char     buffer[PATH_MAX];

    argc--; argv++;
    if (argc) {
       char *   dummy;

       GetFullPathName(*argv, sizeof(buffer), buffer, &dummy);
       printf("[%s] -> [%s]\n", *argv, buffer);
    }

    return 0;
}

If I execute the program from inside CMD it gives the expected result.

S:\ado>sample msadox.dll
[msadox.dll] -> [S:\ado\msadox.dll]

 From inside a bash the result depends on passed argument and/or the 
current working directory of the shell.

f DOT redeker AT MIMIR-2 /cygdrive/s/ado
$ sample msadox.dll
[msadox.dll] -> [C:\Program Files\Common Files\System\ado\msadox.dll]

With Process Monitor I have observed that the shell does not execute the 
program directly, but starts a subshell and that subshell then starts 
the actual program.

The created Windows Process has as working directory not S:\ado but 
C:\Program Files\Common Files\System\ado.

But if the first argument of GetFullPathName() is a relative path, then 
Windows takes into account the in my eyes incorrect working directory. 
The same thing happens when you use GetCurrentDirectory() in your program.


Frank


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