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:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=l3YN4hIOoCMlm4yP 2yZRajs3WCG8Kyquflq/c2pxvV2ODGLVeLipDRvoKoVsmqnbzvx7neSF4cEtFjka JXPqKA7vgw0qY5mjp+oGJ2h0V8YLGKo5oduX3HFq2fdCarNExGzMoXq3gFmgHope bYPqSpIOXyGrDD0w9EK67ZdDZtM= 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:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=4mDKVgFC6tVAY9DEcoxBWV 3jMdU=; b=SYeansofVC+KOKxJAqBxTYPelTounIgC5B91dbXlogkvT5S+yGtx37 TNlko8Uk1if+YmzGw8dVw/XW+TClmPd1vLXGqt6isYbyrvx4NC3HxI8ZHHAFZ2LN +up0S7DxrhIWiejQZ5fep8f6VmR0oqF60vWreqaDz2Y9s3bfQRIgM= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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=2.3 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=pathcc, path.cc, UD:path.cc, 13022017 X-HELO: mout.kundenserver.de Subject: Re: cygpath -w converts relative paths to absolute windows paths To: cygwin AT cygwin DOT com References: <10eb657d-a00b-1609-a9b9-6373092c1ac1 AT polyhack DOT io> <20170212112314 DOT GE11666 AT calimero DOT vinschen DOT de> <6055a8e1-bfd7-16c7-f25a-e02523863fdd AT towo DOT net> <20170213151614 DOT GA25846 AT calimero DOT vinschen DOT de> From: Thomas Wolff Message-ID: <797cd711-05a0-19f7-41b7-43321571da8c@towo.net> Date: Mon, 13 Feb 2017 20:34:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170213151614.GA25846@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-UI-Out-Filterresults: notjunk:1;V01:K0:0nWY1+RTQrs=:VzHzVKkjQO7JsSBQxuTW7q ZjKYSVF6hGJxTLxTbtWWZaAJ49ikkweXq/hW+vemRDoGshuHJfSOmIAjvztL8lVDUReOg6SDn CnzxBcaxlBZg90Y/Lal6k4ICU26FMwJIrDXvD2WinZze53OyRvJfkScgqoXVivd+0iJ6wlF66 Uj8/FasNdGlP4uD6UfUKd6tnQ6u084YVf/6KlJpgXq8JWG8rxoIOq7Oopk81FHFolStZZbCCa R9FbxB6szmwKtm1nPSCpa1TakY5FWzqICraXfGGKOanLQmrxJTK0CGbE2iGYWECxv5YPeTcAb NQvNR7GXdSPkbCfgQtqe8Ui+nmhRCNMKEbXuKq5t0GoePe8dqFfP6w+IPI2zjGkcpFGgTj7YW E0UDWiVPKiYZI+k6K/b8FWamXNjC3nXk3wjZPUrng+/vcTHarDwyXH9XWwVk/+G7b3GQu/MOu Tign0xoArOK1AWLMLyAnQH/IhiN+GUZzIqMgRm2Kuz+tstCzDPEoXivYn132XhPmDN5gpyvcq ZPdDyIx6B4mjMNYKpr73J2gd6SsTQm7JlGC0oWfRPa9I6nJnYPvZG5shTuFEnzAL2SlgTWWdJ mRS+pF1fC3r1kwOzAjncBDtxsylCxHlvFRX0z37b2N22nS5KSUjaGeeY5HDCZHmq5OPWmD6uI LdOyazsFRNJwhwPBzHgVmxm6+w2cpvpIxqvDWG+3mEST1rgFLcMcX5lmyRV4H28dJtDmvs/F+ AoCQaJCHpjJUh6Q6 X-IsSubscribed: yes Am 13.02.2017 um 16:16 schrieb Corinna Vinschen: > On Feb 12 18:38, Thomas Wolff wrote: >> Am 12.02.2017 um 12:23 schrieb Corinna Vinschen: >>> On Feb 7 14:35, Roger Qiu wrote: >>>> Hi, >>>> >>>> I've found that `cygpath --windows '../` will give back an absolute windows >>>> path. >>>> >>>> I thought this would only happen if you provide the `--absolute` flag, or >>>> when the path is a special cygwin path. >>>> >>>> But this occurs just for normal directories. >>>> >>>> I have come across a situation where I need to convert ntfs symlinks to unix >>>> symlinks and back. Sometimes these symlinks have relative paths them. Now by >>>> using cygpath --windows, I get back absolute paths, which means the >>>> integrity of the symlink isn't preserved. >>>> >>>> Can `cygpath --windows '../directory'` give back `..\directory` for paths >>>> aren't special cygwin paths? These relative backslashes are supported in >>>> Windows right now. >>> Not easily. All paths are evaluated as absolute paths inside Cygwin. >>> The result of the path conversion is always an absolute path. A relative >>> path is generated from there by checking if the path prefix in POSIX >>> notation is identical to the current working directory. If not, the >>> path stays absolute. Naturally, if you use a "..", the resulting path >>> does not match the CWD anymore, so you're out. >> How about converting getcwd(), too, and comparing that? > Converting to what? And how's that different from what I describe above? I was looking at path.cc, function mkrelpath, and (without tracing anything) assumed this would be the relevant function and had the impression that, when comparing path_prefix_p (cwd_win32, path, ...), path might be "normalized" (resolving links and folding ".." components) while cwd_win32 might not. If that's the case, it might be sufficient to "normalize" cwd_win32 as well. > Btw., did you see https://cygwin.com/ml/cygwin/2017-01/msg00404.html? No, I hadn't, sorry. Will respond there. ------ 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