Su quali sistemi //foo/bar è diverso da /foo/bar?

In tutta la specifica POSIX, sono disponibili (1, 2, 3...) per consentire alle implementazioni di trattare un percorso che inizia con due / specialmente.

Un'applicazione POSIX (un'applicazione scritta nella specifica POSIX per essere portabile su tutti i sistemi compatibili con POSIX) non può presumere che //foo/bar è lo stesso di /foo/bar (anche se possono presumere che ///foo/bar è lo stesso di /foo/bar ).

Ora quali sono quei sistemi POSIX (storici e ancora mantenuti) che trattano //foo appositamente? Credevo (ora mi è stato smentito) che la fornitura di POSIX fosse stata spinta da Microsoft per la loro variante Unix (XENIX) e forse per il livello POSIX di Windows (qualcuno può confermarlo?).

È utilizzato da Cygwin, che è anche un livello simile a POSIX per Microsoft Windows. Esistono sistemi Windows non Microsoft? OpenVMS?

Sui sistemi in cui //foo/bar è speciale, a cosa serve? //host/path per l'accesso ai file system di rete? File system virtuali?

Esegui alcune applicazioni in esecuzione su Mi piace Unix, se non l'API del sistema, trattare //foo/bar percorsi specialmente (in contesti in cui trattano altrimenti /foo/bar come percorso nel filesystem)?

Modifica , da allora ho posto una domanda sulla mailing list di austin-group sull'origine di //foo/bar la gestione delle specifiche e la discussione è una lettura interessante (almeno dal punto di vista archeologico).

Risposta accettata:

Questa è una raccolta e un indice delle risposte fornite finora. Questo post è wiki della comunità , può essere modificato da chiunque abbia più di 100 reputazione e nessuno ne ottiene la reputazione. Sentiti libero di pubblicare la tua risposta e aggiungere un link qui (o aspetta che lo faccia io). Idealmente, questa risposta dovrebbe essere solo un riepilogo (con voci brevi mentre le altre risposte individuali avrebbero i dettagli).

Sistemi attualmente mantenuti attivamente:

• Cygwin . Un livello POSIX per Microsoft Windows. Utilizzato per i percorsi UNC di Windows.
• UWIN dal 1.3. Un altro livello POSIX per Windows. Utilizzato almeno per //host/file percorsi di condivisione file di rete.
• IBM z/OS come menzionato nel bug tracker POSIX, z/OS risolve //pathname richieste ai dataset MVS , non ai file di rete. Esempio.

Sistemi defunti

• Dominio/sistema operativo Apollo (confermato). Citato anche nella descrizione ufficiale UNC (Universal Naming Convention) come possibile origine di //host/path notazioni (vedi anche pagina 2-15).

  Secondo Donn Terry, è stata HP (che ha acquisito Apollo Computers) a spingere per l'inclusione di tale disposizione nelle specifiche POSIX per Dominio/OS.

• Tektronix Utek (confermato), dove //host/path è un percorso su un file system distribuito .

• QNX 4 con il sistema di elaborazione distribuito FLEET, dove //123/path è un /path sul nodo 123. (Menzionato nella documentazione di QNX 6.)

• AT&T SysV versione 3 (non verificato). //host/path nel sistema di condivisione file remota RFS (fuori produzione in SVR4).

• SEL/Gould UTX-32 (non verificato). Usato per //host/path .

Applicazioni che trattano //foo/bar specialmente per i percorsi

• Perforza dove //depot/A/B/C/D fa riferimento a un percorso in un deposito .
• Frullatore . Nella sua configurazione usi un // prefisso per percorsi relativi (alla blend associata al data-block).
• Il bazel il sistema di compilazione utilizza un // prefisso per le etichette dei target all'interno del grafico di build Bazel.

Correlati:come sopprimere un messaggio da un programma durante l'installazione per utilizzarlo in un programma bash?