Investigué un poco sobre esto en Google, pero los resultados fueron confusos. ¿Por qué se /
usa el signo para denotar el directorio raíz? ¿Hay alguna razón sólida detrás de esto?
linux
directory-structure
history
Ruban Savvy
fuente
fuente
cd /home
es equivalente acd /home/
agregar/
al final del nombre vacío proporciona acceso a ese directorio.chroot()
llamada, pero cuando se ve desde adentro, esto se abstrae./some/dir
SIEMPRE significa que(root)/some/dir
whilesome/dir
siempre es relativo al directorio de trabajo actual. Este principio también es transferible al uso de URL web.Respuestas:
La barra diagonal
/
es el carácter delimitador que separa directorios en rutas en sistemas operativos tipo Unix. Este personaje parece haber sido elegido en algún momento de la década de 1970, y según fuentes anecdóticas , las razones podrían estar relacionadas con que el predecesor de Unix, el sistema operativo Multics , usó el>
personaje como separador de ruta, pero los diseñadores de Unix ya habían reservado los caracteres>
y<
para indicar la redirección de E / S en la línea de comandos de shell mucho antes de que tuvieran un sistema de archivos de varios niveles. Entonces, cuando llegó el momento de diseñar el sistema de archivos, tuvieron que encontrar otro carácter para indicar la separación del elemento del nombre de ruta.Una cosa a tener en cuenta aquí es que en el terminal Lear-Siegler ADM-3A de uso común durante la década de 1970, de donde se origina , entre otras cosas, la práctica de usar el
~
carácter para representar el directorio de inicio , la /clave está al lado de la >clave:En cuanto a por qué el directorio raíz se denota por un solo
/
, es una convención muy probablemente influenciada por el hecho de que el directorio raíz es el directorio de nivel superior de la jerarquía de directorios, y aunque otros directorios pueden estar debajo de él, generalmente no hay ' Es una razón para referirse a cualquier cosa fuera del directorio raíz. Del mismo modo, la entrada del directorio en sí no tiene nombre, porque es el límite del árbol del directorio visible.fuente
/
. Los sistemas de archivos Unix son un solo árbol, con puntos de montaje para las distintas unidades.chroot
y tal: no puede acceder a nada fuera de la nueva raíz, pero eso no significa que no estén allí.chroot()
se introdujo, no tenía ninguna propiedad similar a la cárcel , simplemente afectaba la resolución del nombre de ruta. Incluso hoy, los procesos privilegiados pueden salir de un chroot por diseño . También lo mencionéchroot()
en un comentario anterior .>
como separador de directorio, sino también<
para referirse al directorio padre:<
por sí solo era equivalente a..
, mientras que<foo
era equivalente a../foo
. Siempre me pareció estéticamente agradable.El primer sistema de archivos jerárquico como lo conocemos hoy fue diseñado para Multics . El diseño se describe en "Un sistema de archivos de uso general para almacenamiento secundario" por RC Daley y PG Neumann. Una característica destacada de este sistema de archivos es que un directorio es un archivo que puede estar contenido en un directorio como cualquier otro archivo. La estructura del archivo forma un árbol, en el que todos los nodos no hoja son directorios. La raíz del árbol es siempre un directorio. Cada archivo tiene un nombre (el nombre de la entrada ) que es único dentro de su directorio padre. El directorio raíz no tiene un nombre ya que no está contenido en otro directorio.
Para designar un archivo, debe describir la ruta desde la raíz del árbol. Multics adoptó una sintaxis natural para los nombres de ruta donde si
P
es la ruta a un directorio yF
es el nombre de un archivo, entonces es la sintaxis para el archivo llamado dentro del directorio cuya ruta es .P>F
F
P
Para aquellos momentos en los que no desea cargarse con directorios, Multics tenía la noción de directorio de trabajo . Un nombre de archivo simple sin indicación de directorio se interpreta como un archivo en el directorio de trabajo.
Combinando estas reglas,
foo
es un archivo en el directorio de trabajo;foo>bar
es un archivo en el directorio secundario del directoriofoo
de trabajo, y así sucesivamente. Estas reglas describen rutas relativas, pero se necesita una regla suplementaria para construir rutas absolutas a partir del directorio raíz. Dado que leer un nombre de ruta de izquierda a derecha corresponde a moverse de la raíz a las hojas del árbol, la raíz debe indicarse con un marcador especial a la izquierda del nombre de la ruta. Dado que los nombres de archivo nunca están vacíos (porque eso a menudo sería confuso), ningún nombre de ruta relativa comienza con el carácter>
, lo que lo convierte en un marcador conveniente para nombres de ruta absolutos. Así>foo
es el archivo llamadofoo
en el directorio raíz,>foo>bar
es el archivo llamadobar
en el directorio llamadofoo
en el directorio raíz, y así sucesivamente. Esto deja el directorio raíz, que podría ser la cadena vacía; sin embargo, a menudo no es conveniente usar la cadena vacía como un nombre de ruta, por lo que se escribe>
, lo que tiene el beneficio adicional de que un nombre de ruta es absoluto si y solo si su primer carácter lo es>
.Unix adoptó este diseño de Multics. Como Unix ya había usado el carácter
>
para la redirección de salida en su shell de comandos, sus diseñadores eligieron un carácter diferente/
para separar directorios en nombres de ruta.fuente
En los componentes de nombre de ruta en Unix, solo no se pueden usar dos caracteres: el carácter nulo, que termina las cadenas en C (el lenguaje del núcleo) y la barra diagonal, que está reservada como el separador de ruta. Además, los componentes de ruta no pueden ser cadenas vacías.
Entonces, en un nombre de ruta, solo tenemos dos tipos de tokens: una barra diagonal y un componente.
Supongamos que, sin agregar ningún token nuevo , nos gustaría admitir la compatibilidad con dos tipos de rutas, relativas y absolutas. Además, nos gustaría poder referirnos al directorio raíz, que no tiene nombre (no tiene padre que le dé un nombre).
¿Cómo podemos representar rutas relativas, rutas absolutas y referirnos al directorio raíz, usando solo la barra diagonal?
La forma más obvia de extender un lenguaje (que no sea la introducción de un nuevo token) es crear una nueva sintaxis: dar un nuevo significado a las combinaciones de tokens que son sintaxis no válida.
Las rutas que comienzan con una barra oblicua no tienen sentido, entonces, ¿por qué no utilizar una barra inclinada como marcador que indica "esta ruta es absoluta, en lugar de relativa"?
Una ruta que no contiene nada más que una barra también es inválida, entonces, ¿por qué no asignarle el significado "directorio raíz"?
Estos dos significados se unen porque una ruta absoluta comienza a buscar en el directorio raíz. En otras palabras, se puede considerar que una barra diagonal tiene el significado:
Entonces, también podríamos incluir una barra diagonal final, lo que puede significar "esta ruta afirma que el último componente de la ruta es el nombre de un directorio en lugar de un archivo normal o cualquier otro tipo de objeto: esa barra diagonal indica ese directorio de manera similar a la forma en que la barra inclinada indica el directorio raíz ".
Con toda esta sintaxis anterior, todavía tenemos una sintaxis con un significado no asignado: barras dobles, barras triples, etc.
¿Por qué no simplemente presentar otro token y hacerlo de manera diferente? Esto probablemente se deba a que los diseñadores adoptaron enfoques minimalistas en general. (¿Por qué el
ed
editor solo muestra un mensaje?
cuando haces algo mal?) La barra diagonal es fácil de escribir y no requiere desplazamiento. Un lenguaje de ruta con solo dos tipos de token (componente y barra inclinada) es fácil de recordar y usar.Otra consideración importante es que es posible manipular fácilmente las rutas utilizando solo representaciones de cadenas. Por ejemplo, podemos "volver a enraizar" las rutas absolutas a un nuevo directorio padre con bastante facilidad:
Esto no funcionaría si indicáramos rutas absolutas de alguna otra manera, como un signo de dólar principal o cualquier otra cosa:
Este tipo de codificación todavía es necesaria en algunos casos cuando se trata de rutas de estilo Unix, pero hay menos.
fuente
/
con el pie derecho. Como tocar un piano.