Sur quels systèmes //foo/bar est-il différent de /foo/bar ?

Tout au long de la spécification POSIX, il y a des dispositions (1, 2, 3...) pour permettre aux implémentations de traiter un chemin commençant par deux / spécialement.

Une application POSIX (une application écrite selon la spécification POSIX pour être portable sur tous les systèmes compatibles POSIX) ne peut pas supposer que //foo/bar est identique à /foo/bar (bien qu'ils puissent supposer que ///foo/bar est identique à /foo/bar ).

Maintenant, quels sont ces systèmes POSIX (historiques et toujours maintenus) qui traitent //foo spécialement? Je croyais (on m'a maintenant prouvé que j'avais tort) que la fourniture de POSIX avait été poussée par Microsoft pour leur variante Unix (XENIX) et éventuellement la couche POSIX de Windows (quelqu'un peut-il le confirmer ?).

Il est utilisé par Cygwin qui est également une couche de type POSIX pour Microsoft Windows. Existe-t-il des systèmes non Microsoft Windows ? OuvrirVMS ?

Sur les systèmes où //foo/bar est spécial, à quoi ça sert ? //host/path pour l'accès aux systèmes de fichiers réseau ? Systèmes de fichiers virtuels ?

Faites quelques applications s'exécutant sur des systèmes similaires à Unix - si ce n'est pas l'API du système - traitez //foo/bar chemins spécialement (dans des contextes où ils traitent autrement /foo/bar comme chemin sur le système de fichiers) ?

Modifier , j'ai depuis posé une question sur la liste de diffusion austin-group sur l'origine de //foo/bar manipulation dans la spécification, et la discussion est une lecture intéressante (du moins d'un point de vue archéologique).

Réponse acceptée :

Il s'agit d'une compilation et d'un index des réponses données jusqu'à présent. Ce message est un wiki communautaire , il peut être modifié par toute personne ayant plus de 100 réputations et personne n'en tire de réputation. N'hésitez pas à publier votre propre réponse et à ajouter un lien vers celle-ci ici (ou attendez que je le fasse). Idéalement, cette réponse ne devrait être qu'un résumé (avec des entrées courtes tandis que les autres réponses individuelles contiendraient les détails).

Systèmes actuellement activement entretenus :

• Cygwin . Une couche POSIX pour Microsoft Windows. Utilisé pour les chemins UNC Windows.
• UWIN depuis la 1.3. Une autre couche POSIX pour Windows. Utilisé au moins pour //host/file chemins de partage de fichiers réseau.
• IBM z/OS comme mentionné dans le bug tracker POSIX, z/OS résout //pathname requêtes aux jeux de données MVS , pas aux fichiers réseau. Exemple.

Systèmes obsolètes

• Domaine/SE Apollo (confirmé). Également mentionné dans la description officielle UNC (Universal Naming Convention) comme origine possible de //host/path notations (voir aussi, page 2-15).

  Selon Donn Terry, c'est HP (qui a acquis Apollo Computers) qui a poussé à l'inclusion de cette disposition dans la spécification POSIX pour Domain/OS.

• Tektronix Utek (confirmé), où //host/path est un chemin sur un système de fichiers distribué .

• QNX 4 avec le système de traitement distribué FLEET, où //123/path est un /path sur le nœud 123. (Mentionné dans la documentation QNX 6.)

• AT&T SysV Release 3 (non vérifié). //host/path dans (abandonné dans SVR4) le système de partage de fichiers à distance RFS.

• SEL/Gould UTX-32 (non vérifié). Utilisé pour //host/path .

Applications qui traitent //foo/bar spécialement pour les chemins

• Perforer où //depot/A/B/C/D fait référence à un chemin dans un dépôt .
• Mélangeur . Dans sa configuration vous utilisez un // préfixe pour les chemins relatifs (au mélange associé au bloc de données).
• Le Bazel le système de construction utilise un // préfixe pour les étiquettes des cibles dans le graphique de construction Bazel.

En relation:Comment supprimer un message d'un programme lors de son installation pour l'utiliser dans un programme bash ??