Perchè era '.' scelto per rappresentare la directory corrente e '..' per la directory principale?

Dopo aver letto questa domanda Perché '~' è stato scelto per rappresentare la home directory? , la prossima ovvia domanda nella mia mente era perché "." e '..' è stato usato per rappresentare la directory corrente e la directory principale.

Sembra così intuitivo ora, ma qualche motivo particolare?

Dubito che troverai una risposta tanto interessante quanto la domanda sulle tilde!

Non ero lì, ma .. è come un'ellissi (...), che ha senso in contesti come cd ../../../there. Inoltre, e soprattutto guardando la vecchia tastiera del terminale dalla custodia tilde, non ci sono molti personaggi idonei per questo scopo. Non è necessario cambiare .neanche. È perfetto.

Il fatto che venga utilizzato un prefisso punto per i file nascosti potrebbe essere un altro motivo. I file nascosti non sono elencati per impostazione predefinita da strumenti come ls, quindi non sono nemmeno sostanzialmente ridondanti .e ... Ridondanti nel senso che non ha senso prenderli in considerazione insieme ad altri file - altrimenti sono sicuramente utili.

Come si è visto io possa avere all'indietro ... da Wikipedia :

L'idea che i nomi dei file siano preceduti da un '.' dovrebbe essere nascosto è il risultato di un bug del software nei primi giorni di Unix. Quando lo speciale "." e '..' le voci della directory sono state aggiunte al filesystem, si è deciso che il comando ls non dovesse visualizzarle. Tuttavia, il programma ls è stato erroneamente scritto per escludere qualsiasi file il cui nome è iniziato con un '.', Anziché solo i file denominati '.' o '..'.

Ciò risulta utile durante la programmazione; poiché il sistema include. e .. in risposta a readdir()comandi di tipo (e globi di shell), ignorandoli e file nascosti possono essere eseguiti allo stesso modo.

Una diversa opinione su questo valore d'uso è il riferimento per la citazione wikipedia. Certo, l'intera storia potrebbe essere apocrifa ... è un po 'difficile credere che, ad esempio, Dennis Ritchie abbia pensato che il controllo del primo personaggio sarebbe andato bene.

Non sono d'accordo con l'autore vis, sarebbe meglio mettere i file di configurazione nascosti nella propria directory piuttosto che dare loro un prefisso universale. Il prefisso è molto più flessibile, consentendo direttive in-tree come .gitignoree .htaccess. Testimone che i file di quel tipo compaiono anche insieme quando sono ordinati lessicograficamente - quindi forse questo era apposta dopotutto .

^{Principalmente la stessa risposta di @Panos 'su StackOverflow :}

In breve, si è evoluto da de dd(l' directory e l' directory ddell'irectory) che sono stati creati dagli utenti a mano. ddivenne punto e quelli .e ..furono creati prima mkdirdall'utilità (setuid dopo il collegamento delle directory non era più consentito dal semplice utente) e successivamente dalla mkdir chiamata di sistema.

Estratto da un'intervista a Ken Thompson (1989-09-06):

MSM : Ma per l'utente sembrerebbe all'incirca la stessa di una gerarchia di directory.

Thompson : No, il primo era un DG. In realtà, non era nemmeno aciclico. Se hai capito il file system UNIX, era .... c'era la I-list, che è una definizione di tutti i file sul sistema. E poi alcuni di quei file erano directory che contenevano solo nome e numero I. Non c'è niente lì dentro che lo limiti a un albero. Quindi in realtà non era affatto gerarchico.

MSM : Capisco.

Thompson : E non l'abbiamo limitato a un albero. Stavamo sperimentando varie topologie. Ciò che abbiamo finito per fare è trasformarsi in concreto e forzare le topologie che in realtà erano le topologie che venivano per convenzione da quel sistema. Il ... Ogni volta che creavamo una directory, per convenzione la mettevamo in un'altra directory chiamata directory - directory , che era dd. Il suo nome era dd e che tutte le directory degli utenti e in effetti la maggior parte delle altre directory, gli utenti mantengono i propri sistemi di directory, avevano i puntatori a dd e dd si accorciava in punto-puntoe dd era per directory-directory. Era il posto in cui era possibile raggiungere tutte le altre directory del sistema per mantenere questa ciotola di spaghetti. Quindi, intendo questo tufo in varie forme, che era rigorosamente una convenzione in questa implementazione della DG di solo un insieme casuale di directory e file è stato forzato in una tipologia che abbiamo mantenuto. Quando abbiamo iniziato a scrivere cose come i filesystem che controllavano programmi e cose, il blocco delle directory degli spaghetti bowl e la ricerca di cose sconnesse, intendo dire che avresti diviso qualcosa e non l'avresti mai recuperato, perché sai che l'avresti perso. Questi problemi sono diventati quasi insormontabili, e così nella prossima implementazione abbiamo costretto una tipologia più forte di così.