cygpath -w converts relative paths to absolute windows paths

Thomas Wolff towo@towo.net
Mon Feb 13 19:34:00 GMT 2017


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



More information about the Cygwin mailing list