Por quê foi '.' escolhido para representar o diretório atual e '..' para o diretório pai?

Depois de ler esta pergunta Por que '~' foi escolhido para representar o diretório inicial? , a próxima pergunta óbvia em minha mente era por que '.' e '..' foi usado para representar o diretório atual e o diretório pai.

Parece tão intuitivo agora, mas alguma razão em particular?

Duvido que você encontre uma resposta tão interessante quanto à pergunta em aberto!

Eu não estava lá, mas .. é como uma elipse (...), o que faz sentido em contextos como cd ../../../there. Além disso, e especialmente olhando para o velho teclado do terminal, não há muitos caracteres elegíveis para esse fim. Você também não precisa mudar .. É perfeito.

O fato de um prefixo de ponto ser usado para arquivos ocultos pode ser outro motivo. Os arquivos ocultos não são listados por padrão por ferramentas como ls, portanto, nem os essencialmente redundantes .e ... Redundante no sentido de que não faz sentido considerá-los junto com outros arquivos - eles certamente são úteis de outra forma.

Acontece que eu posso tê-lo ao contrário ... da wikipedia :

A noção de que os nomes de arquivos são precedidos por um '.' deve estar oculto é o resultado de um erro de software nos primeiros dias do Unix. Quando o especial '.' e as entradas do diretório '..' foram adicionadas ao sistema de arquivos, foi decidido que o comando ls não deveria exibi-las. No entanto, o programa ls foi escrito por engano para excluir qualquer arquivo cujo nome iniciasse com '.', Em vez de apenas arquivos com o nome '.' ou '..'.

Isso acaba sendo útil na programação; desde que o sistema inclua. e .. em resposta aos readdir()comandos de tipo (e shell globs), ignorá-los e arquivos ocultos podem ser realizados da mesma maneira.

Uma opinião diferente sobre esse valor de uso está na referência da citação da Wikipedia. Claro, toda a história pode ser apócrifa ... é um pouco difícil de acreditar que, por exemplo, Dennis Ritchie imaginou que apenas verificar o primeiro personagem seria bom.

Não concordo com o autor, seria melhor colocar os arquivos de configuração ocultos em seu próprio diretório, em vez de fornecer a eles um prefixo universal. O prefixo é muito mais flexível, permitindo diretivas na árvore como .gitignoree .htaccess. Testemunhe que arquivos desse tipo também aparecem juntos quando classificados lexicograficamente - então talvez isso tenha sido de propósito, afinal .

^{Principalmente a mesma resposta que a @Panos 'no stackoverflow :}

Em suma, ele evoluiu de de dd(a directory ea dde irectory directory), que foram criados por usuários com a mão. dtornou-se ponto , e aqueles .e ..foram criados pela mkdirutilidade (setuid após ligando diretórios já não era permitido pela mera usuário) e, posteriormente, pela mkdir chamada de sistema.

Trecho de uma entrevista com Ken Thompson (06-09 1989):

MSM : Mas para o usuário, seria mais ou menos o mesmo que uma hierarquia de diretórios.

Thompson : Não, o primeiro foi um DG. De fato, nem era acíclico. Se você entendeu o sistema de arquivos UNIX, era .... havia a lista I, que é uma definição de todos os arquivos no sistema. E alguns desses arquivos eram diretórios que apenas continham nome e número-I. Não há nada lá que o restrinja a uma árvore. Portanto, não era de fato, nem hierárquico.

MSM : Entendo.

Thompson : E não o restringimos a uma árvore. Estávamos experimentando várias topologias. O que acabamos fazendo é transformar em concreto e forçar as topologias que de fato eram as topologias que vieram por convenção desse sistema. O ... Toda vez que criamos um diretório, por convenção, o colocamos em outro diretório chamado directory - directory , que era dd. Seu nome era dd e todos os diretórios de usuários e, de fato, a maioria dos outros diretórios, os usuários mantêm seus próprios sistemas de diretório, tinham ponteiros de volta para dd, e dd foi reduzido para ponto-ponto, e dd era para diretório-diretório. Era o local de volta para onde você podia acessar todos os outros diretórios do sistema para manter essa tigela de espaguete. Então, eu quero dizer esse tufo de várias formas, o que era estritamente convencional nesta implementação de DG de apenas um conjunto aleatório de diretórios e arquivos, sendo forçado a entrar numa tipologia que mantivemos. Quando começamos a escrever coisas como sistemas de arquivos, verificando programas e outras coisas, o bloqueio dos diretórios da tigela de espaguete e a descoberta de coisas desconexas, quero dizer que você disseveria alguma coisa e nunca a recuperaria, porque sabe que a perdeu. Esses problemas tornaram-se quase intransponíveis e, na próxima implementação, forçamos uma tipologia mais forte que isso.