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

Question

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

    

Answer 1

A barra / é o caractere delimitador que separa os diretórios em caminhos em sistemas operacionais semelhantes ao Unix. Esse personagem parece ter sido escolhido em algum momento nos anos 70, e de acordo com anedótico fontes , as razões podem estar relacionadas a que o antecessor do Unix, o Multics sistema operacional, usava o caractere > como separador de caminho, mas os criadores do Unix já tinham reservado os caracteres > e < para significar o redirecionamento de E / S na linha de comando do shell bem antes de terem um multi- sistema de arquivos de nível. 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 de caminho.

Uma coisa a notar aqui é que no terminal Lear-Siegler ADM-3A de uso comum durante a década de 1970, do qual entre outras coisas a prática de usar o caracter ~ para representar o diretório home origina , a tecla / está ao lado da tecla > :

Quanto ao motivo pelo qual o diretório raiz é denotado por um único / , é uma convenção provavelmente influenciada pelo fato de que o diretório raiz é o diretório de nível superior da hierarquia de diretórios e enquanto outros diretórios podem estar abaixo Normalmente, não há motivo para se referir a algo fora do diretório raiz. Da mesma forma, a própria entrada de diretório não tem nome, porque é o limite da árvore de diretórios visível.

    

Answer 2

O primeiro sistema de arquivos hierárquico que conhecemos hoje foi projetado para Multics . O design é descrito em “Um sistema de arquivos de uso geral para armazenamento secundário” da R.C. Daley e P.G. Neumann Uma característica saliente desse sistema de arquivos é que um diretório é um arquivo que pode estar contido em um diretório como qualquer outro arquivo. A estrutura de arquivos forma uma árvore, na qual todos os nós não-folha são diretórios. A raiz da árvore é sempre um diretório. Cada arquivo tem um nome (o nome de entrada ) que é único dentro de seu diretório pai. O diretório raiz não tem nome, pois não está contido em outro diretório.

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

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

Combinando essas regras, foo é um arquivo no diretório de trabalho; foo>bar é um arquivo no diretório-filho foo do diretório de trabalho e assim por diante. Essas regras descrevem caminhos relativos, mas uma regra complementar é necessária para construir caminhos absolutos a partir do diretório raiz. Como a leitura de um nome de caminho da esquerda para a direita corresponde à movimentação da raiz para as folhas da árvore, a raiz deve ser indicada por um marcador especial à esquerda do nome do caminho. Como os nomes dos arquivos nunca estão vazios (porque isso muitas vezes seria confuso), nenhum nome de caminho relativo jamais começa com o caractere > , o que o torna um marcador conveniente para nomes de caminho absolutos. Portanto >foo é o arquivo chamado foo no diretório raiz, >foo>bar é o arquivo chamado bar no diretório chamado foo no 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, então ele é escrito > , que tem o benefício adicional de que um nome de caminho é absoluto se e somente se seu primeiro caractere for > .

O Unix adotou este design da Multics. Como o Unix já havia usado o caractere > para o redirecionamento de saída em seu shell de comando, seus designers escolheu um caractere diferente / para separar diretórios em nomes de caminho.

    

Answer 3

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

Assim, 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 apoiar 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 tem pai que lhe 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 uma linguagem (além da introdução de um novo token) é criar uma nova sintaxe: dar um novo significado às combinações de tokens que são sintaxes inválidas.

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

Um caminho que contém nada além de uma barra também é inválido, então por que não atribuir o significado "o diretório raiz".

Esses dois significados se unem porque um caminho absoluto começa a pesquisar 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 incluir uma barra à direita, que pode significar "esse caminho afirma que o último componente de caminho é o nome de um diretório em vez de um arquivo regular ou qualquer outro tipo de objeto: essa barra indica diretório da mesma forma que a barra inicial indica o diretório raiz. "

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

Por que não basta introduzir outro token e fazê-lo de forma diferente. Isto é provavelmente porque os designers usaram abordagens minimalistas em geral. (Por que o editor ed exibe apenas ? quando você faz algo errado?) A barra é fácil de digitar, não exigindo nenhum deslocamento. Uma linguagem de caminho com apenas dois tipos de token (componente e barra) é fácil de lembrar e usar.

Outra consideração importante é que as manipulações fáceis de caminhos são possíveis usando apenas representações de strings. 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 forma, como um símbolo de dólar 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 ao lidar com caminhos no estilo Unix, mas há menos deles.