La barra / è il carattere di delimitazione che separa le directory nei percorsi nei sistemi operativi simili a Unix. Questo carattere sembra essere stato scelto negli anni '70 e, secondo fonti aneddotiche, le ragioni potrebbero essere legate al fatto che il predecessore di Unix, il sistema operativo Multics, usava il > carattere come separatore di percorso, ma i progettisti di Unix avevano già riservato i caratteri > e < per indicare il reindirizzamento I/O sulla riga di comando della shell molto prima che avessero un file system multilivello. Quindi, quando è arrivato il momento di progettare il filesystem, hanno dovuto trovare un altro carattere per indicare la separazione degli elementi del percorso.
Una cosa da notare qui è che nel terminale Lear-Siegler ADM-3A di uso comune durante gli anni '70, da cui tra l'altro la pratica di utilizzare il ~ carattere per rappresentare l'origine della directory home, il / chiave si trova accanto a > chiave:
Per quanto riguarda il motivo per cui la directory root è indicata da un singolo / , è una convenzione molto probabilmente influenzata dal fatto che la directory radice è la directory di primo livello della gerarchia di directory e, sebbene altre directory possano trovarsi al di sotto di essa, di solito non c'è motivo di fare riferimento a qualcosa al di fuori della directory radice . Allo stesso modo la voce della directory stessa non ha nome, perché è il limite dell'albero di directory visibile.
Il primo file system gerarchico come lo conosciamo oggi è stato progettato per Multics. Il design è descritto in "Un file system per uso generale per l'archiviazione secondaria" di R.C. Daley e P.G. Neumann. Una caratteristica saliente di questo filesystem è che una directory è un file che può essere contenuto in una directory come qualsiasi altro file. La struttura del file forma un albero, in cui tutti i nodi non foglia sono directory. La radice dell'albero è sempre una directory. Ogni file ha un nome (il nome della voce) che è univoco all'interno della sua directory padre. La directory radice non ha un nome poiché non è contenuta in un'altra directory.
Per designare un file, è necessario descrivere il percorso dalla radice dell'albero. Multics ha adottato una sintassi naturale per i nomi dei percorsi dove if P è il percorso di una directory e F è il nome di un file, quindi P>F è la sintassi per il file chiamato F all'interno della directory il cui percorso è P .
Per quei momenti in cui non vuoi caricarti di directory, Multics aveva un'idea di directory di lavoro. Un semplice nome di file senza indicazione di directory viene interpretato come un file nella directory di lavoro.
Combinando queste regole, foo è un file nella directory di lavoro; foo>bar è un file nella directory figlio foo della directory di lavoro e così via. Queste regole descrivono percorsi relativi, ma è necessaria una regola supplementare per costruire percorsi assoluti a partire dalla directory principale. Dato che leggere un segnavia da sinistra a destra corrisponde a spostarsi dalla radice alle foglie dell'albero, la radice va indicata con un apposito contrassegno a sinistra del segnavia. Dal momento che i nomi dei file non sono mai vuoti (perché ciò creerebbe spesso confusione), nessun nome di percorso relativo inizia mai con il carattere > , che lo rende un indicatore conveniente per i nomi di percorso assoluti. Così >foo è il file chiamato foo nella directory principale, >foo>bar è il file chiamato bar nella directory chiamata foo nella directory principale e così via. Questo lascia la directory root, che potrebbe essere la stringa vuota; tuttavia, spesso non è conveniente utilizzare la stringa vuota come percorso, quindi viene invece scritta > , che ha l'ulteriore vantaggio che un percorso è assoluto se e solo se il suo primo carattere è > .
Unix ha adottato questo design da Multics. Poiché Unix aveva già utilizzato il carattere > per il reindirizzamento dell'output nella sua shell di comando, i suoi progettisti hanno scelto un carattere diverso / per separare le directory nei nomi dei percorsi.
Nei componenti del nome di percorso su Unix, solo due caratteri non possono essere usati:il carattere nullo, che termina le stringhe in C (la lingua del kernel) e la barra, che è riservata come separatore di percorso. Inoltre, i componenti del percorso non possono essere stringhe vuote.
Quindi, in un nome di percorso, abbiamo solo due tipi di token:una barra e un componente.
Supponiamo che, senza aggiungere nuovi token , vorremmo supportare due tipi di percorsi, relativi e assoluti. Inoltre, vorremmo poter fare riferimento alla directory root, che non ha nome (non ha un genitore che le dia un nome).
Come possiamo rappresentare percorsi relativi, percorsi assoluti e fare riferimento alla directory principale, utilizzando solo la barra?
Il modo più ovvio per estendere un linguaggio (diverso dall'introduzione di un nuovo token) è creare una nuova sintassi:dare un nuovo significato a combinazioni di token che sono sintassi non valide.
I percorsi che iniziano con una barra non hanno senso, quindi perché non utilizzare una barra iniziale come indicatore che indica "questo percorso è assoluto, piuttosto che relativo".
Anche un percorso che non contiene altro che una barra non è valido, quindi perché non assegnargli il significato di "la directory principale".
Questi due significati si uniscono perché un percorso assoluto inizia la ricerca nella directory principale. In altre parole, si può considerare che una barra iniziale abbia il significato:
- vai alla directory principale e utilizza il carattere barra.
- se c'è più materiale nel percorso, elaboralo come percorso relativo, altrimenti hai finito.
Quindi, potremmo anche inserire una barra finale, che può significare "questo percorso afferma che l'ultimo componente del percorso è il nome di una directory piuttosto che un normale file o qualsiasi altro tipo di oggetto:quella barra finale denota quella directory in modo simile a il modo in cui la barra iniziale denota la directory principale."
Con tutta questa sintassi di cui sopra, abbiamo ancora una sintassi con un significato non assegnato:doppia barra, tripla barra e così via.
Perché non introdurre semplicemente un altro token e farlo in modo diverso. Ciò è probabilmente dovuto al fatto che i designer hanno adottato approcci minimalisti in generale. (Perché ed editor visualizza solo un ? quando fai qualcosa di sbagliato?) La barra è facile da digitare e non richiede spostamenti. Un linguaggio di percorso con solo due tipi di token (componente e barra) è facile da ricordare e utilizzare.
Un'altra considerazione importante è che è possibile manipolare facilmente i percorsi utilizzando solo rappresentazioni di stringhe. Per esempio, possiamo "re-rootare" facilmente i percorsi assoluti verso una nuova directory principale:
OLD_PATH=/old/path
NEW_HOME=/new/home
NEW_PATH="$NEW_HOME$OLD_PATH" /new/home/old/path
Questo non funzionerebbe se indicassimo i percorsi assoluti in qualche altro modo, come un segno di dollaro iniziale o qualsiasi altra cosa:
OLD_PATH=^old/path # ^ means absolute path
NEW_HOME=^new/home
# now we need more string kung-fu than just catenation
NEW_PATH="$NEW_HOME/${OLD_PATH#^}"
Questo tipo di codifica è ancora necessario in alcuni casi quando si ha a che fare con percorsi in stile Unix, ma ce n'è meno.