6. El sistema de archivos como árbol: rutas absolutas y relativas

Descripción

Al terminar esta lección vas a poder ubicar cualquier archivo o carpeta de tu sistema con una ruta absoluta o con una relativa, elegir con criterio cuál de las dos conviene en cada situación, y leer sin dudar qué significan los atajos ., .., ~ y - la próxima vez que aparezcan en un comando, un tutorial o un mensaje de error.

Esto no es un tecnicismo de sistema operativo: es la causa número uno de un tipo de bug que parece imposible hasta que lo entiendes. Un proyecto funciona perfecto en tu computadora, y al subirlo a un servidor o a un pipeline de integración continua explota con No such file or directory — para un archivo que juras que existe, porque lo estás viendo ahí mismo en tu carpeta. La causa, casi siempre, es una diferencia entre cómo tu sistema y el servidor tratan las mayúsculas dentro de una ruta, algo que vas a poder diagnosticar en minutos después de esta lección.

Conexión con el módulo: la lección anterior te dejó capaz de aprender cualquier comando por tu cuenta, leyendo su manual. Hoy instalamos el mapa sobre el que se apoya todo lo demás: cómo está organizado el territorio que esos comandos recorren. Todavía no vas a hacer un uso extenso de pwd, ls ni cd —eso es exactamente el tema de la siguiente lección—; hoy los vas a usar apenas lo necesario, como herramienta de apoyo, para ver las rutas resolverse en la práctica.

Todo desciende de un mismo antepasado

Piensa en un árbol genealógico. No importa cuántas ramas tenga una familia, ni cuántos apellidos distintos aparezcan generaciones después: si sigues la línea hacia atrás, todos los descendientes se conectan en un mismo antepasado común. Para ubicar a cualquier persona en ese árbol no necesitas memorizar dónde vive — te basta con describir su descendencia exacta: hijo de, nieto de, bisnieto de, hasta llegar a esa raíz compartida.

El sistema de archivos de Linux y macOS funciona exactamente así. Existe un único punto de partida, que se escribe con una sola barra: /. Se llama la raíz (root), y absolutamente todo lo demás —cada carpeta, cada archivo, cada disco externo que conectes, cada unidad de red que montes— es descendiente de ese mismo punto. No hay una segunda raíz en paralelo. Cuando conectas una memoria USB, el sistema no le abre un árbol nuevo: la injerta como una rama más dentro del mismo árbol, en una carpeta que ya existía (/media/dev/USB en muchas distribuciones de Linux, /Volumes/USB en macOS). Esto contrasta con Windows, donde cada disco es literalmente un árbol separado con su propia letra (C:\, D:\) — la razón por la que, si alguna vez usaste Windows, la idea de "una sola raíz para todo" puede sentirse rara al principio.

De la misma manera que describes a una persona como "hijo de" o "nieto de", vas a usar ese mismo vocabulario de parentesco para describir carpetas: toda carpeta (salvo la raíz misma) tiene exactamente una carpeta padre que la contiene, y puede tener cero, una o muchas carpetas o archivos hijos dentro. Una ruta no es más que esa línea de descendencia escrita en texto, con una barra separando cada generación.

Ejemplo trabajado

pwd

Qué esperar (el valor real depende de tu usuario; aquí se usa dev como ejemplo en Linux):

/home/dev

Lee esa salida como una línea genealógica completa: partiendo de la raíz /, existe una carpeta home, y dentro de home existe una carpeta dev — tu directorio personal. Cada barra que separa un segmento marca un salto de una generación a la siguiente: / es la raíz, home es hija de la raíz, dev es hija de home. pwd (print working directory) simplemente te dice en qué punto exacto de ese árbol estás parado ahora mismo — el nombre completo del comando ya te lo dice todo: "imprime el directorio de trabajo actual".

La jerarquía típica: qué guarda cada carpeta y para qué existe

En cualquier instalación de Linux vas a encontrar, colgando directamente de la raíz, un puñado de carpetas con nombres cortos y crípticos que datan de los años setenta y que la industria entera sigue usando porque cambiar una convención tan extendida costaría más de lo que vale. Vale la pena reconocerlas de memoria, aunque nunca necesites tocar la mayoría:

• /home — los directorios personales de cada usuario del sistema. El tuyo vive en /home/tu-usuario.
• /etc — la configuración de todo el sistema: archivos de texto plano que definen cómo se comportan los servicios, los usuarios, la red. El nombre viene de "et cetera" — en los primeros Unix era, literalmente, la carpeta donde se guardaba "todo lo demás" que no encajaba en ninguna otra categoría, y con el tiempo se volvió el estándar para configuración.
• /var — datos que cambian ("variable") mientras el sistema funciona: registros de actividad (logs), colas de correo, cachés. Si algo se escribe solo, constantemente, mientras usas la máquina, probablemente vive aquí.
• /usr — la mayoría de los programas y bibliotecas del sistema, no directorios de usuario. Es una trampa de nombre clásica: en los Unix más antiguos, /usr sí guardaba los directorios personales de los usuarios de un segundo disco; cuando el sistema creció, esos directorios personales se movieron a /home y /usr quedó reservado para software — pero el nombre nunca cambió. Si alguna vez asumes que tu carpeta personal vive bajo /usr porque el nombre "suena a usuario", vas a buscar en el lugar equivocado.
• /tmp — archivos temporales. Cualquier programa puede escribir aquí datos que no necesita conservar; muchas distribuciones lo vacían automáticamente al reiniciar, así que nunca guardes algo importante ahí.
• /opt — software de terceros instalado de forma autocontenida, cada programa en su propia subcarpeta (/opt/nombre-del-programa), separado del software que trae el sistema por defecto.

Ejemplo trabajado

ls /

Qué esperar (la lista exacta varía por distribución; esta es representativa de un Linux típico):

bin  boot  dev  etc  home  lib  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

Esa es literalmente la primera generación de descendientes de la raíz: cada nombre que ves ahí es una carpeta directamente hija de /. ls (list) muestra el contenido de una carpeta — aquí lo usamos sin ninguna opción, apenas para ver esos nombres; leer esta salida columna por columna y con todas sus opciones es el trabajo de la siguiente lección.

macOS hereda esta misma base — por debajo, sigue siendo un sistema Unix — pero la capa que ves como usuario cambia dos nombres clave: tu directorio personal vive en /Users/tu-usuario, no en /home, y las aplicaciones que instalas con interfaz gráfica viven en /Applications, una carpeta que Linux ni siquiera tiene (en Linux, los programas se reparten entre /usr, /opt y otros lugares, gestionados por un manejador de paquetes en vez de vivir todos juntos en una sola carpeta de "aplicaciones"). Si escribes ls / en una Mac vas a seguir viendo etc, var, tmp y usr — están ahí, funcionando exactamente igual por debajo — pero también vas a ver Users y Applications, que no existen en un Linux estándar.

Tu home: el único lugar del árbol que es completamente tuyo

Tu directorio personal —/home/tu-usuario en Linux, /Users/tu-usuario en macOS— es la única carpeta de todo el árbol sobre la que tienes control total sin pedirle permiso a nadie. Casi todo tu trabajo diario pasa por ahí: tus proyectos, tus descargas, tus documentos. Carpetas como /etc o /usr son propiedad del sistema (técnicamente, del usuario root) y modificarlas sin autorización especial te va a topar con un Permission denied — el modelo completo de permisos y sudo es tema del módulo 4, pero por ahora basta con que sepas por qué casi ningún tutorial te pide crear un proyecto fuera de tu home: es el único terreno donde puedes escribir libremente desde el primer día.

Ruta absoluta o ruta relativa: cuál usar y cuándo

Ahora que tienes el mapa completo, hay dos lenguajes distintos para describir dónde vive un archivo dentro de ese árbol — y elegir el correcto no es cuestión de gusto, tiene una regla concreta detrás.

Una ruta absoluta describe la línea genealógica completa desde la raíz: siempre empieza con /, y es válida sin importar en qué carpeta estés parado cuando la escribes — /home/dev/projects/report.csv significa exactamente lo mismo lo escribas desde donde lo escribas.

Una ruta relativa describe el camino desde donde estás parado ahora mismo (tu directorio de trabajo actual), y por eso nunca empieza con / — projects/report.csv solo apunta al archivo correcto si tu directorio actual es /home/dev; escrita desde cualquier otro lugar, apunta a algo distinto o a nada.

La regla para elegir: usa una ruta absoluta cuando el resultado tiene que funcionar sin importar desde dónde se ejecute — un script que corre automáticamente (una tarea programada), un archivo de configuración de otro programa, un comando que copias a un chat de equipo para que otra persona lo corra en su propia máquina. Usa una ruta relativa cuando trabajas de forma interactiva dentro de un proyecto y el archivo está cerca de donde estás parado: es más corta de escribir, y —la razón que de verdad importa— sigue funcionando si mueves el proyecto entero a otra carpeta o a otra computadora, porque describe la posición de un archivo respecto a otro dentro del mismo proyecto, no respecto a la raíz del disco.

Ejemplo trabajado

pwd
cd projects/reports
pwd
cd /var/log
pwd

Qué esperar:

/home/dev
/home/dev/projects/reports
/var/log

El primer cd usa una ruta relativa (projects/reports, sin barra inicial): funciona porque, parado en /home/dev, existe una carpeta projects con una carpeta reports adentro — la misma línea escrita desde cualquier otro directorio del sistema probablemente fallaría con No such file or directory, porque ahí esa ruta relativa apunta a otro lugar o a nada. El segundo cd usa una ruta absoluta (/var/log, con barra inicial): habría funcionado exactamente igual sin importar en qué carpeta estuvieras parado antes de escribirla, porque describe el camino completo desde la raíz. Usar cd aquí es solo un vehículo para ver la diferencia en acción — el comando a fondo, con todas sus variantes, lo practicas en la siguiente lección.

Los atajos que vas a escribir cien veces al día: ., .., ~ y -

Escribir la línea genealógica completa cada vez sería agotador, así que la shell reconoce cuatro símbolos abreviados. Los primeros tres son parte del lenguaje general de rutas: puedes usarlos dentro de cualquier comando que reciba una ruta como argumento (cd, ls, cp, cat, el que sea). El cuarto es distinto, y vale la pena notar por qué.

• . significa "esta misma carpeta". Rara vez lo necesitas solo, pero aparece todo el tiempo como prefijo — ./script.sh le dice explícitamente a la shell "ejecuta el script que está aquí mismo", algo necesario porque, por razones de seguridad, la carpeta actual normalmente no forma parte del PATH que la shell revisa al buscar comandos (verás el PATH a fondo en el módulo 4).
• .. significa "la carpeta padre" — un salto hacia arriba en la línea genealógica. ../data/file.csv significa "sube un nivel desde donde estoy, y desde ahí entra a data/file.csv". Puedes encadenarlos: ../../ sube dos niveles.
• ~ es un atajo para tu directorio home completo. La shell lo expande automáticamente antes de ejecutar el comando: escribir ~/projects es exactamente lo mismo que escribir /home/dev/projects si tu usuario es dev. Es el mismo valor que guarda la variable de entorno $HOME.
• - significa "el directorio en el que estabas antes de tu último cd" — pero, a diferencia de los tres anteriores, esto no es un símbolo genérico de rutas: es una convención que reconoce específicamente el comando cd (leyendo una variable que guarda internamente, $OLDPWD), no el sistema de archivos ni la shell en general. Escribir cat - o ls - no te va a llevar a ningún lado — en la mayoría de los comandos, un guion aislado tiene un significado completamente distinto, o ninguno. Cómo usar cd - para saltar entre dos directorios de trabajo es exactamente lo que practicas en la siguiente lección.

Ejemplo trabajado

echo "Tu home según ~: $(echo ~)"
echo "Tu home según \$HOME: $HOME"

Qué esperar:

Tu home según ~: /home/dev
Tu home según $HOME: /home/dev

Ambas líneas imprimen exactamente el mismo valor, porque son dos formas distintas de llegar al mismo dato: ~ es un atajo que la shell expande por su cuenta antes de ejecutar cualquier comando, mientras que $HOME es una variable de entorno que guarda ese mismo valor de forma explícita. Esto confirma algo importante: ~ no es magia ni un caso especial oculto en el sistema de archivos — es simplemente texto que tu shell reemplaza por la ruta completa de tu home antes de que el comando siquiera se ejecute.

La trampa de las mayúsculas: por qué "en mi máquina funciona" no basta

Esta es, probablemente, la diferencia entre sistemas que más bugs reales produce y menos se enseña. Linux es sensible a mayúsculas en los nombres de archivo: Notes.txt, notes.txt y NOTES.txt son tres archivos completamente distintos y pueden coexistir en la misma carpeta sin conflicto. macOS, en su configuración de fábrica, no lo es: su formato de disco por defecto (APFS) es insensible a mayúsculas — pero preserva la que escribiste al crear el archivo. Esa combinación es la que tiende una trampa silenciosa.

Ejemplo trabajado

Supón que en tu Mac creas un archivo con mayúscula inicial y luego lo lees en minúsculas:

touch Config.yaml
cat config.yaml

Qué esperar en macOS (formato por defecto, insensible a mayúsculas):

(el contenido del archivo se muestra sin error)

Qué esperar en Linux, con exactamente los mismos dos comandos:

cat: config.yaml: No such file or directory

En tu Mac, config.yaml y Config.yaml apuntan al mismo archivo físico —el sistema de archivos ignora la diferencia de mayúsculas al comparar nombres, aunque ls te siga mostrando Config.yaml, con la mayúscula que realmente escribiste al crearlo: eso es lo que significa "preservar" la mayúscula sin ser sensible a ella. En Linux, son dos nombres distintos, y solo uno de los dos existe. Este es exactamente el escenario detrás de un bug clásico: subes un proyecto que referencia config.yaml en el código pero el archivo real en el repositorio se llama Config.yaml —o al revés—, todo corre sin problema en tu laptop Mac durante semanas, y el mismo código falla en el servidor de producción o en el pipeline de integración continua, casi siempre corriendo Linux, con un No such file or directory que no tiene ningún sentido a primera vista porque "el archivo está ahí, lo estoy viendo".

La lección práctica: nunca confíes en que tu Mac te va a avisar de un descuido de mayúsculas — trata cada nombre de archivo, en cualquier proyecto que vaya a correr en un servidor, con la misma disciplina que exigiría Linux desde el día uno.

Archivos ocultos: el punto inicial no es magia

Cualquier archivo o carpeta cuyo nombre empiece con un punto —.bashrc, .gitignore, .ssh— es un archivo oculto: ls sin opciones no lo muestra, y el explorador de archivos de tu sistema operativo tampoco, por defecto. Es tentador pensar que ese punto le da al archivo algún tipo de permiso especial o protección extra. No es así, y vale la pena tenerlo claro: un archivo oculto tiene exactamente los mismos permisos, el mismo dueño y el mismo comportamiento que cualquier otro archivo. Lo único que cambia es que un programa —ls, el explorador gráfico— decidió, por convención, no mostrarlo a menos que se lo pidas explícitamente.

El origen de esa convención es puramente práctico. Todo directorio contiene, en realidad, dos entradas internas que el sistema crea automáticamente y que ya conoces: . (la carpeta misma) y .. (su padre). Si ls las mostrara siempre, cada listado empezaría con dos líneas inútiles y repetidas. La solución que se adoptó hace décadas fue ocultar por defecto cualquier nombre que empiece con punto — y una vez que esa regla existía, la comunidad la reutilizó a propósito para sus propios archivos de configuración personal, los que no quieres viendo siempre en medio de tus documentos.

Ejemplo trabajado

touch .my-notes
ls
ls -a

Qué esperar:

(ls sin opciones no muestra .my-notes en absoluto)
.  ..  .my-notes  (el resto de tus archivos normales)

ls sin opciones filtra .my-notes por la sola razón de que empieza con punto — no porque tenga un permiso distinto ni porque esté "protegido". La opción -a (all) desactiva ese filtro y muestra absolutamente todo, incluidas las dos entradas . y .. que mencionamos arriba. El resto de las opciones de ls —y una explicación completa de qué es cada columna en ls -l— es exactamente el tema de la siguiente lección.

Errores comunes

"Un archivo oculto está protegido o es más seguro" (conceptual). Qué pasa: el estudiante guarda una contraseña o una clave dentro de un archivo con nombre .secreto y asume que, por empezar con punto, nadie más puede leerlo ni modificarlo. Por qué ocurre: el punto inicial solo afecta si ls lo muestra por defecto; no toca los permisos del archivo en absoluto — un archivo oculto con permisos abiertos es tan legible para otra cuenta del sistema como uno visible con los mismos permisos. Cómo detectarlo: corre ls -la (verás esta opción a fondo en la siguiente lección) sobre el archivo y revisa su columna de permisos, exactamente igual que harías con cualquier otro archivo — el punto no cambia nada de esa columna. Cómo corregirlo: trata cualquier archivo oculto que guarde datos sensibles con la misma disciplina de permisos que cualquier otro archivo sensible; el punto en el nombre no reemplaza esa disciplina, solo lo saca de la vista por defecto.

"/usr es donde vive mi carpeta de usuario" (conceptual). Qué pasa: guiado por el nombre, el estudiante busca su directorio personal dentro de /usr, o escribe un script que asume que el home de un usuario está bajo /usr/nombre-de-usuario. Por qué ocurre: el nombre es un resabio histórico — en los Unix más antiguos, /usr sí guardaba directorios personales en un segundo disco; hoy guarda programas y bibliotecas del sistema, no carpetas de usuario, pero el nombre nunca se actualizó para reflejar ese cambio. Cómo detectarlo: si un comando o un script asume una ruta bajo /usr para algo que "suena" a datos personales del usuario y falla con No such file or directory, sospecha primero de esta confusión de nombre. Cómo corregirlo: usa siempre ~ o $HOME para referirte al directorio personal de un usuario — nunca construyas esa ruta a mano asumiendo /usr ni ningún otro nombre que "suene" correcto.

"Funciona en mi Mac, así que el archivo está bien nombrado" (troubleshooting). Qué pasa: el estudiante nombra un archivo con una mayúscula distinta a como lo referencia en su código —Data.csv en el disco, data.csv en el script— todo corre perfecto en su Mac durante días o semanas, y al desplegar en un servidor Linux o correr una prueba en un contenedor Docker (casi siempre basado en Linux) explota con No such file or directory para un archivo que "existe, lo estoy viendo ahí mismo". Por qué ocurre: el formato de disco por defecto de macOS ignora diferencias de mayúsculas al comparar nombres; el de Linux, no — dos nombres que tu Mac trata como el mismo archivo son, para Linux, dos archivos distintos, y solo uno de los dos existe de verdad. Cómo detectarlo: si un error de No such file or directory aparece solo en el servidor o en integración continua y nunca localmente, compara mayúscula por mayúscula el nombre exacto en el código contra el nombre exacto en el disco —no confíes en que "se ven iguales" a simple vista—. Cómo corregirlo: haz coincidir la mayúscula exacta entre el nombre del archivo y cada referencia en tu código, y adopta una convención fija (por ejemplo, minúsculas siempre) para cualquier archivo que vaya a viajar a un servidor.

Ejercicios

1. Tu pwd muestra /home/dev/projects/blog. Dentro de esa carpeta existe una subcarpeta drafts, y un nivel arriba, en /home/dev/projects, existe otra carpeta llamada shared-assets. Escribe una ruta relativa y una ruta absoluta que apunten a shared-assets desde donde estás parado.

Ver solución

Ruta relativa: ../shared-assets — .. sube un nivel, de blog a projects, y desde ahí entra a shared-assets. Ruta absoluta: /home/dev/projects/shared-assets — la línea genealógica completa desde la raíz, válida sin importar en qué carpeta estés parado cuando la escribas. Esto funciona porque ambas describen exactamente el mismo destino en el árbol; la única diferencia es el punto de partida desde el que se cuenta el camino: uno desde tu ubicación actual, el otro desde /.

2. Con $HOME igual a /home/dev y tu pwd mostrando /home/dev/projects/blog/drafts, escribe la ruta absoluta completa a la que expande cada uno de estos atajos: ~, .., ../...

Ver solución

~ expande a /home/dev — tu home completo, sin importar dónde estés parado. .. expande a /home/dev/projects/blog — un nivel arriba de tu ubicación actual. ../.. expande a /home/dev/projects — dos niveles arriba, uno por cada .. encadenado. Esto funciona porque cada .. es un salto independiente hacia el padre inmediato: encadenarlos simplemente repite ese salto tantas veces como .. escribas, mientras que ~ no depende en absoluto de dónde estés parado, porque siempre apunta al mismo destino fijo.

3. Estás escribiendo dos cosas: (a) una tarea programada que se ejecuta automáticamente cada noche y necesita leer un archivo de tu proyecto, y (b) un comando que escribes ahora mismo en tu terminal, parado dentro de ese mismo proyecto, para copiar un archivo a una carpeta vecina. ¿Usarías ruta absoluta o relativa en cada caso, y por qué?

Ver solución

Para la tarea programada (a), ruta absoluta. Una tarea automática no garantiza desde qué directorio se ejecuta —depende de cómo la programó el sistema, no de dónde estabas parado tú al escribirla—, así que solo una ruta absoluta funciona de forma confiable sin importar el contexto en el que corra. Para el comando interactivo (b), ruta relativa: es más corta de escribir, y como ya sabes exactamente dónde estás parado en ese momento, no hay ambigüedad — además, si algún día mueves el proyecto completo a otra carpeta, esa ruta relativa entre archivos del mismo proyecto sigue siendo válida, mientras que una ruta absoluta escrita a mano dejaría de serlo. Esto funciona porque la regla no es "una es mejor que la otra", sino que cada una resuelve un problema distinto: la absoluta garantiza el mismo resultado sin importar el punto de partida; la relativa es portátil junto con el proyecto que describe.

4. En tu Mac tienes un archivo llamado Logo.png dentro de assets/, y tu código HTML lo referencia como assets/logo.png (minúscula). Todo se ve perfecto cuando abres la página localmente. Subes el proyecto a un servidor Linux y el logo no carga; en la consola del navegador ves un error 404 para ese archivo. ¿Por qué funciona en un lugar y no en el otro, y cómo lo corriges de forma permanente, sin depender de acordarte la próxima vez?

Ver solución

Funciona en tu Mac porque, por defecto, macOS es insensible a mayúsculas al comparar nombres de archivo: Logo.png y logo.png apuntan al mismo archivo físico para el sistema, aunque ls siga mostrando Logo.png con la mayúscula que realmente escribiste. En el servidor Linux, Logo.png y logo.png son dos nombres distintos, y solo el primero existe de verdad en el disco — el navegador pide assets/logo.png, ese archivo no existe con ese nombre exacto, y el servidor responde 404. Para corregirlo de forma permanente, no basta con renombrar el archivo una vez: conviene adoptar una convención fija para todo el proyecto —por ejemplo, minúsculas siempre para nombres de archivo— y hacer coincidir cada referencia en el código con el nombre exacto en el disco, letra por letra. Esto funciona porque el problema de fondo no es un archivo mal nombrado en particular, sino la costumbre de no tratar las mayúsculas como significativas — una costumbre que tu Mac te deja tener sin castigo, hasta que el mismo código corre en un sistema que sí las distingue.

Resumen y siguiente paso

Hoy instalaste el mapa: el sistema de archivos es un único árbol que nace en /, con una jerarquía típica (/home, /etc, /var, /usr, /tmp, /opt en Linux; /Users y /Applications como diferencias visibles de macOS) y tu home como el único terreno completamente tuyo dentro de ese árbol. Viste la diferencia entre ruta absoluta y relativa, con una regla concreta para elegir entre ambas, y qué expande cada uno de los atajos ., .., ~ y - —y por qué este último es distinto a los otros tres. Viste también dos trampas que parecen triviales y no lo son: que las mayúsculas dentro de una ruta pueden cambiar completamente el resultado entre tu Mac y un servidor Linux, y que un archivo oculto no tiene ningún permiso especial — solo está fuera de la vista por defecto.

Antes de avanzar deberías poder: explicar de memoria por qué el sistema de archivos es "un árbol con una sola raíz"; dado cualquier pwd, escribir tanto una ruta absoluta como una relativa hacia un archivo cercano; decir sin dudar qué expande cada uno de ., .., ~ y -; y explicar con tus propias palabras por qué un proyecto puede funcionar en tu Mac y romperse al desplegarse en Linux por un problema de mayúsculas.

Ya tienes el lenguaje completo para describir dónde vive cualquier cosa en el árbol. Lo que todavía te falta son los comandos que realmente te mueven por él y te muestran, con precisión, lo que hay en cada punto donde te detienes — pwd como hábito de orientarte antes de actuar, ls leído columna por columna, y cd con todas sus variantes, incluido ese cd - que hoy solo mencionamos. Eso es exactamente el tema de la siguiente lección.

Recursos

• hier(7) — Linux manual page — descripción oficial de la jerarquía de directorios de Linux: qué guarda cada carpeta de primer nivel y por qué.
• Filesystem Hierarchy Standard 3.0 — Linux Foundation — la especificación formal detrás de /etc, /var, /usr, /opt y el resto de la jerarquía.
• path_resolution(7) — Linux manual page — cómo el sistema resuelve una ruta absoluta frente a una relativa, y el papel exacto de . y ...
• About Apple File System (APFS) — Apple Support — explica los formatos de APFS, incluida la variante sensible a mayúsculas frente al comportamiento por defecto.
• ls(1) — Linux manual page — referencia completa de ls, incluida la sección sobre archivos que empiezan con punto y la opción -a.