From: Eric Blake <eblake@redhat.com>
To: cygwin@cygwin.com, sven.eden@gmx.de
Subject: Re: Problematic interpretion of paths starting with double slashes
Date: Tue, 12 Jun 2018 16:28:00 -0000 [thread overview]
Message-ID: <dc8418d2-2004-97f0-2d8c-ab438f007eba@redhat.com> (raw)
In-Reply-To: <trinity-82173dac-d842-4a87-8d1f-bed9a958d178-1528793630066@3c-app-gmx-bs08>
On 06/12/2018 03:53 AM, Sven Eden wrote:
> Hello everybody,
>
> I have a problem with a script that wants to copy a file,
> which has a variable paths build from various variables.
>
> The first variable is a possible prefix, the second an
> absolute path. If no prefix is needed, the first consists of
> just a slash.
Then fix your script to provide 3 slashes instead of 2. Only 2 slashes
has the magic UNC behavior.
That is, if you have a script that is concatenating:
${prefix}/${dir}
where ${prefix} might be empty, you can always rewrite it to be:
${prefix}///${dir}
to get portable behavior that always resolves to the root dir instead of
trying to dereference remote machines under //.
>
> This puzzled me, because this works perfectly well on every
> GNU/Linux (plus WSL) system I tried.
Just because your script "works" on a number of systems doesn't mean it
is portable.
> I am completely aware that §4.13 of the Open Group Base
> Specification Issue 7 (IEEE Std 1003.1-2017) reads:
> "If a pathname begins with two successive <slash>
> characters, the first component following the leading
> <slash> characters may be interpreted in an
> implementation-defined manner, although more than two
> leading <slash> characters shall be treated as a single
> <slash> character."
Yes, that's exactly why your script is not portable. So even though
Linux has chosen to make "/" and "//" synonymous, Cygwin has not.
>
> My question therefore is, whether the behavior can be gotten
> nearer what every other GNU/Linux system does.
> Maybe, if said first component can not be resolved as an smb
> host, try an absolute path instead?
That won't work as nicely as you want, because you will introduce long
timeouts for every time that Cygwin first has to ascertain that '//tmp'
does not exist as a remote host. Maybe we could indeed make '//tmp'
resolve to '/tmp' if there is no remote '//tmp' available, but the speed
penalties in doing so will not make it pleasant. Better is to fix your
script to not try accessing '//tmp' in the first place.
> I have searched the cygwin mailing list, but all I could find
> was some discussion about UNC paths from 1997.
Yes, we've had special support for // as UNC for a LOOONG time, and
changing it now would break existing users that expect it to work as
allowed by POSIX.
> P.S An example of a failing script line is:
> https://github.com/gentoo/gentoo/blob/331976f/eclass/toolchain.eclass#L2136
Well, then report that as a bug to the author of that script.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
--
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
next prev parent reply other threads:[~2018-06-12 11:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-12 11:45 Sven Eden
2018-06-12 11:52 ` Adam Dinwoodie
2018-06-12 16:28 ` Eric Blake [this message]
2018-06-12 17:12 ` Aw: " Sven Eden
2018-06-12 17:57 ` Brian Inglis
2018-06-13 10:14 ` Aw: " Sven Eden
2018-06-13 13:49 ` Andrey Repin
2018-06-15 2:41 ` Brian Inglis
2018-06-12 20:01 ` Aw: " Eric Blake
2018-06-13 13:05 ` Sven Eden
2018-06-12 20:32 ` Lee
2018-06-13 13:05 ` Aw: " Sven Eden
2018-06-12 23:31 ` Aw: " Achim Gratz
2018-06-13 9:57 ` Corinna Vinschen
2018-06-13 13:29 ` Sven Eden
2018-06-13 19:32 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dc8418d2-2004-97f0-2d8c-ab438f007eba@redhat.com \
--to=eblake@redhat.com \
--cc=cygwin@cygwin.com \
--cc=sven.eden@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).