On 2018-06-12 07:14, Sven Eden wrote: >> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr >> Von: "Eric Blake" <ebl...@redhat.com> >> Then fix your script to provide 3 slashes instead of 2. Only 2 slashes >> has the magic UNC behavior. > It is not my script. *my* scripts are portable by all means. >> 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} > The script was "fixed" from ${prefix}/${dir} a while ago. Before that the > outcome was "///". Which is very bad style. Good style is to guarantee, that > not more than one slash is issued.
Which is equivalent to //localhost/ on Cygwin and elsewhere - / on Linux - this is semantics not "style". >> Just because your script "works" on a number of systems doesn't mean it >> is portable. > I neither wrote it was my script, nor that it was portable per se. But > thanks for jumping down my throat for nothing. I won't quote and answer to > your further attacks, but instead concentrate on the relevant stuff, okay? Eric contributes to The Open Group Single Unix Spec and elsewhere and provides these explanations frequently - that's his "style" ;^> >>> 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. > The speed penalties would only apply if > a) "Something" looks up //foo/bar > b) "Something" made a mistake and actually wanted > /foo/bar > So apart from the speed penalty that "Something" has to suffer, and its their > own damn fault, the only real consequence would be that "Something" does not > die from ENOENT any more. If you can't fix the target, wrap it with another script or function, and run it with "command script paths...", so it never sees non-POSIX-compliant paths. >>> 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. > Keeping it, changing it, extending it. It doesn't matter. All three variants > would be fully POSIX compliant. However, I never asked to actually change the > current behaviour. Only whether it was possible to extend it. > Looking up // as UNC is the default, wanted and expected behaviour. I got > that right from the start and even wrote that I find that pretty cool. > Doing a simple stat on / if (and only if) the UNC lookup fails, does not > endanger anything. It wouldn't break anything or do any other damage. Besides > from adding an additional <0.01s lag to any failed access that *really* meant > a network share. > So no. Adding this tiny extra functionality wouldn't break anything for > anybody, but allowed the usage of software that relies on the non-cygwin > behaviour. (And is outside the users control.) > Am I right that the relevant stuff can be found in winsup/cygwin? Overhead is ~2.5s for non-existent share checks on my system: $ for p in / // ///; do time ls ${p}tmp/foo/bar; done ls: cannot access '/tmp/foo/bar': No such file or directory real 0m0.040s user 0m0.015s sys 0m0.030s ls: cannot access '//tmp/foo/bar': No such file or directory real 0m2.333s user 0m0.015s sys 0m0.015s ls: cannot access '///tmp/foo/bar': No such file or directory real 0m0.035s user 0m0.015s sys 0m0.015s -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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