Web lists-archives.com

Re: Problematic interpretion of paths starting with double slashes




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