Por que o diretório raiz é indicado por um sinal /?

Eu fiz algumas pesquisas sobre isso no Google, mas os resultados foram nublados. Por que o /sinal é usado para denotar o diretório raiz. Existem razões sólidas por trás disso?

A barra /é o caractere delimitante que separa os diretórios em caminhos nos sistemas operacionais do tipo Unix. Esse personagem parece ter sido escolhido em algum momento da década de 1970 e, de acordo com fontes anedóticas , os motivos podem estar relacionados ao fato de o antecessor do Unix, o sistema operacional Multics , ter usado o >personagem como separador de caminho, mas os designers do Unix já haviam reservado os caracteres >e <para indicar o redirecionamento de E / S na linha de comando do shell muito antes de eles terem um sistema de arquivos em vários níveis. Então, quando chegou a hora de projetar o sistema de arquivos, eles tiveram que encontrar outro caractere para significar a separação do elemento do nome do caminho.

Um ponto a ser observado aqui é que, no terminal Lear-Siegler ADM-3A em uso comum durante a década de 1970, do qual, entre outras coisas , se origina a prática de usar o ~caractere para representar o diretório inicial , a /chave está próxima à >chave:

Quanto ao motivo pelo qual o diretório raiz é indicado por um único /, é uma convenção provavelmente influenciada pelo fato de o diretório raiz ser o diretório de nível superior da hierarquia de diretórios e, embora outros diretórios possam estar abaixo dele, geralmente não há ' há um motivo para se referir a qualquer coisa fora do diretório raiz. Da mesma forma, a entrada do diretório em si não tem nome, porque é o limite da árvore de diretórios visível.

O primeiro sistema de arquivos hierárquico como o conhecemos hoje foi projetado para o Multics . O design é descrito em "Um sistema de arquivos de uso geral para armazenamento secundário" por RC Daley e PG Neumann. Uma característica marcante deste sistema de arquivos é que um diretório é um arquivo que pode estar contido em um diretório como qualquer outro arquivo. A estrutura do arquivo forma uma árvore, na qual todos os nós que não são folhas são diretórios. A raiz da árvore é sempre um diretório. Cada arquivo possui um nome (o nome da entrada ) que é exclusivo em seu diretório pai. O diretório raiz não tem um nome, pois não está contido em outro diretório.

Para designar um arquivo, você precisa descrever o caminho a partir da raiz da árvore. Multics adotou uma sintaxe natural para nomes de caminhos, onde if Pé o caminho para um diretório e Fé o nome de um arquivo, então é a sintaxe para o arquivo chamado dentro do diretório cujo caminho é .P>FFP

Para aqueles momentos em que você não quer se sobrecarregar com diretórios, o Multics tinha uma noção de diretório de trabalho . Um nome de arquivo simples sem indicação de diretório é interpretado como um arquivo no diretório de trabalho.

Combinando essas regras, foohá um arquivo no diretório de trabalho; foo>baré um arquivo no diretório filho do diretório foode trabalho e assim por diante. Essas regras descrevem caminhos relativos, mas é necessária uma regra suplementar para construir caminhos absolutos a partir do diretório raiz. Dado que ler um nome de caminho da esquerda para a direita corresponde a mover-se da raiz para as folhas da árvore, a raiz deve ser indicada por um marcador especial à esquerda do nome do caminho. Como os nomes de arquivos nunca estão vazios (porque isso geralmente seria confuso), nenhum nome de caminho relativo começa com o caractere >, o que o torna um marcador conveniente para nomes de caminhos absolutos. Assim, >fooo arquivo é chamado foono diretório raiz, >foo>baré o arquivo chamado barno diretório chamadofoono diretório raiz e assim por diante. Isso deixa o diretório raiz, que pode ser a string vazia; no entanto, muitas vezes não é conveniente usar a string vazia como um nome de caminho; portanto, ela é gravada >, o que traz o benefício adicional de que um nome de caminho é absoluto se e somente se seu primeiro caractere for >.

O Unix adotou esse design da Multics. Como o Unix já havia usado o caractere >para redirecionamento de saída em seu shell de comando, seus designers escolheram um caractere diferente /para separar os diretórios nos nomes dos caminhos.

Nos componentes de nome do caminho no Unix, apenas dois caracteres não podem ser usados: o caractere nulo, que termina as seqüências de caracteres em C (o idioma do kernel) e a barra, reservada como separador de caminhos. Além disso, os componentes do caminho não podem ser cadeias vazias.

Portanto, em um nome de caminho, temos apenas dois tipos de tokens: uma barra e um componente.

Suponha que, sem adicionar novos tokens , gostaríamos de oferecer suporte a dois tipos de caminhos, relativo e absoluto. Além disso, gostaríamos de poder nos referir ao diretório raiz, que não tem nome (não possui pai, o que daria um nome).

Como podemos representar caminhos relativos, caminhos absolutos e nos referir ao diretório raiz, usando apenas a barra?

A maneira mais óbvia de estender um idioma (que não seja a introdução de um novo token) é criar uma nova sintaxe: dê um novo significado às combinações de tokens com sintaxe inválida.

Os caminhos que começam com uma barra não fazem sentido; portanto, por que não usar uma barra inicial como um marcador que indica "esse caminho é absoluto, e não relativo".

Um caminho que não contém nada além de uma barra também é inválido; por que não atribuir a ela o significado "o diretório raiz"?

Esses dois significados se unem porque um caminho absoluto começa a procurar no diretório raiz. Em outras palavras, uma barra principal pode ser considerada como tendo o significado:

• navegue até o diretório raiz e consuma o caractere de barra.
• se houver mais material no caminho, processe-o como um caminho relativo; caso contrário, você estará pronto.

Em seguida, podemos também lançar uma barra final, o que pode significar "esse caminho afirma que o último componente do caminho é o nome de um diretório, em vez de um arquivo comum ou qualquer outro tipo de objeto: essa barra final indica esse diretório de maneira semelhante a a maneira como a barra principal indica o diretório raiz ".

Com tudo isso acima, ainda temos uma sintaxe com um significado não atribuído: barras duplas, barras triplas e assim por diante.

Por que não apenas introduzir outro token e fazê-lo de maneira diferente. Isso provavelmente ocorre porque os designers adotaram abordagens minimalistas em geral. (Por que o ededitor exibe apenas um ?quando você faz algo errado?) A barra é fácil de digitar, sem necessidade de mudança. Uma linguagem de caminho com apenas dois tipos de token (componente e barra) é fácil de lembrar e usar.

Outra consideração importante é que são possíveis manipulações fáceis de caminhos usando apenas representações de string. Por exemplo, podemos "re-root" caminhos absolutos para um novo diretório pai com bastante facilidade:

OLD_PATH=/old/path
NEW_HOME=/new/home

NEW_PATH="$NEW_HOME$OLD_PATH"  /new/home/old/path

Isso não funcionaria se indicássemos caminhos absolutos de alguma outra maneira, como um cifrão principal ou qualquer outra coisa:

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#^}"

Esse tipo de codificação ainda é necessário em alguns casos quando se lida com caminhos no estilo Unix, mas há menos.