path: root/documentation/content/es/books/handbook/basics/_index.adoc

---
title: Capítulo 3. Conceptos básicos de Unix
part: Parte I. Primeros pasos
prev: books/handbook/install
next: books/handbook/ports
showBookMenu: true
weight: 5
path: "/books/handbook/basics/"
---

[[basics]]
= Conceptos básicos de Unix
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 3
:partnums:
:source-highlighter: rouge
:experimental:
:images-path: books/handbook/basics/

ifdef::env-beastie[]
ifdef::backend-html5[]
:imagesdir: ../../../../images/{images-path}
endif::[]
ifndef::book[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
toc::[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

[[basics-synopsis]]
== Sinopsis

El siguiente capítulo comprende la funcionalidad y órdenes básicas del sistema operativo FreeBSD. Gran parte de este material es relevante para cualquier sistema operativo tipo UNIX(R). Puede saltarse este capítulo si considera que ya conoce el funcionamiento de UNIX(R). Si no tiene experiencia previa con FreeBSD debería leer este capítulo con mucha atención.

Después de leer este capítulo, usted sabrá:

* Cómo usar las «consolas virtuales» de FreeBSD.
* Cómo funcionan los permisos de fichero UNIX(R) en relación con las banderas de fichero en FreeBSD.
* La disposición de sistemas de ficheros por omisión en FreeBSD.
* La organización de disco de FreeBSD.
* Cómo montar y desmontar sistemas de ficheros.
* Qué son los procesos, dæmons y señales.
* Qué es una shell, cómo modificar sus variables de entorno por omisión.
* Cómo utilizar editores de texto básicos.
* Qué son los dispositivos y nodos de dispositivos.
* Qué formato binario se usa en FreeBSD.
* Cómo buscar información en las páginas de manual.

[[consoles]]
== Consolas virtuales y terminales

FreeBSD puede utilizarse de muchas maneras. Una de ellas es tecleando órdenes en una terminal de texto. De este modo, mucha de la flexibilidad y poder de un sistema operativo UNIX(R) está inmediatamente en sus manos cuando usa FreeBSD. Esta sección describe qué son «terminales» y «consolas» y cómo puede usarlas en FreeBSD.

[[consoles-intro]]
=== La consola

Si no ha configurado FreeBSD para ejecutar automáticamente un entorno gráfico en el arranque, el sistema le presentará un «prompt» de entrada después del arranque, inmediatamente después de que los «scripts» de inicio terminen de ejecutarse. Verá algo similar a esto:

[source,shell]
....
Additional ABI support:.
Local package initialization:.
Additional TCP options:.

Fri Sep 20 13:01:06 EEST 2002

FreeBSD/i386 (pc3.ejemplo.org) (ttyv0)

login:
....

Los mensajes pueden ser un poco diferentes en su sistema, pero verá algo similar. Las últimas dos líneas son las que nos interesan por el momento. La penúltima línea dice:

[.programlisting]
....
FreeBSD/i386 (pc3.ejemplo.org) (ttyv0)
....

Esta línea contiene información acerca del sistema que acaba de arrancar. Esta usted ante una consola «FreeBSD» que se ejecuta en un procesador Intel o compatible de la arquitectura x86. El nombre de esta máquina (todas las máquinas UNIX(R) tiene un nombre) es `pc3.ejemplo.org`, y usted está ahora ante su consola de sistema (la terminal [.filename]#ttyv0#).

Para acabar, la última línea siempre es:

[.programlisting]
....
login:
....

Este es el lugar donde se usted tecleará su «nombre de usuario» para entrar en FreeBSD. La siguiente sección describe cómo hacerlo.

[[consoles-login]]
=== La entrada a FreeBSD

FreeBSD es un sistema multiusuario multiprocesador. Esta es la descripción formal que se suele dar a un sistema que puede ser utilizado por muchas personas diferentes, que simultáneamente ejecutan muchos programas en un sola máquina.

Cada sistema multiusuario necesita algún modo de distinguir a un «usuario» del resto. En FreeBSD (y en todos los sistemas operativos de tipo UNIX(R)) esto se logra requiriendo que cada usuario «acceda» al sistema antes de poder ejecutar programas. Cada usuario tiene un nombre único (el «nombre de usuario») y una clave secreta, personal (la «contraseña»). FreeBSD preguntará por ambos antes de permitirle a un usuario ejecutar cualquier programa.

Justo después de que FreeBSD arranque y termine de ejecutar sus «scripts» de inicio , le presentará un «prompt» y solicitará un nombre válido de usuario:

[source,shell]
....
login:
....

En este ejemplo vamos a asumir que su nombre de usuario es `john`. Teclée `john` en el «prompt» y pulse kbd:[Intro]. Debería presentársele un «prompt» donde introducir una «contraseña»:

[source,shell]
....
login: john
Password:
....

Teclée ahora la contraseña de `john` y pulse kbd:[Enter]. La contraseña _no se muestra en pantalla_, pero no debe preocuparse por ello. Esto se hace así por motivos de seguridad.

Si ha tecleado su contraseña correctamente ya está usted en un sistema FreeBSD, listo para probar todas las órdenes disponibles.

Verá el MOTD (mensaje del día) seguido por un «prompt» (un caracter `#`, `$` o `%`). Esto confirma que ha validado con éxito su usuario en FreeBSD.

[[consoles-virtual]]
=== Consolas múltiples

Ejecutar órdenes UNIX(R) en una consola está bien, pero FreeBSD puede ejecutar muchos programas a la vez. Tener una consola donde se pueden teclear órdenes puede ser un desperdicio cuando un sistema operativo como FreeBSD puede ejecutar docenas de programas al mismo tiempo. Aquí es donde las «consolas virtuales» muestran su potencial.

FreeBSD puede configurarse para presentarle diferentes consolas virtuales. Puede cambiar de una de ellas a cualquier otra consola virtual pulsando un par de teclas en su teclado. Cada consola tiene su propio canal de salida, y FreeBSD se ocupa de redirigir correctamente la entrada del teclado y la salida al monitor cuando cambia de una consola virtual a la siguiente.

Se han reservado ciertas combinaciones especiales de teclas para pasar de unas consolas virtuales a otras en FreeBSD . Puede utilizar kbd:[Alt+F1], kbd:[Alt+F2] y así sucesivamente hasta kbd:[Alt+F8] para cambiar a una consola virtual diferente en FreeBSD.

Mientras está cambiando de una consola a la siguiente, FreeBSD se ocupa de guardar y restaurar la salida de pantalla. El resultado es la «ilusión» de tener varias pantallas y teclados «virtuales» que puede utilizar para teclear órdenes para que FreeBSD los ejecute. El programa que usted lanza en una consola virtual no deja de ejecutarse cuando la consola no está visible. Continúan ejecutándose cuando se cambia a una consola virtual diferente.

[[consoles-ttys]]
=== El fichero [.filename]#/etc/ttys#

La configuración por omisión de FreeBSD iniciará con ocho consolas virtuales. No es una configuración estática por hardware, así que puede personalizar fácilmente su sistema para arrancar con más o menos consolas virtuales. El número y propiedades de las consolas virtuales están detallados en [.filename]#/etc/ttys#.

En [.filename]#/etc/ttys# es donde se configuran las consolas virtuales de FreeBSD. Cada línea no comentada de este fichero (líneas que no comienzan con un caracter `#`) contiene propiedades para una sola terminal o consola virtual. La versión por omisión de este fichero en FreeBSD configura nueve consolas virtuales y habilita ocho de ellas. Son las líneas que comienzan con `ttyv`:

[.programlisting]
....
# name  getty                           type    status          comments
#
ttyv0   "/usr/libexec/getty Pc"         cons25  on  secure
# Virtual terminals
ttyv1   "/usr/libexec/getty Pc"         cons25  on  secure
ttyv2   "/usr/libexec/getty Pc"         cons25  on  secure
ttyv3   "/usr/libexec/getty Pc"         cons25  on  secure
ttyv4   "/usr/libexec/getty Pc"         cons25  on  secure
ttyv5   "/usr/libexec/getty Pc"         cons25  on  secure
ttyv6   "/usr/libexec/getty Pc"         cons25  on  secure
ttyv7   "/usr/libexec/getty Pc"         cons25  on  secure
ttyv8   "/usr/X11R6/bin/xdm -nodaemon"  xterm   off secure
....

Consulte man:ttys[5] si quiere una descripción detallada de cada columna en este fichero y todas las opciones que puede usar para configurar las consolas virtuales.

[[consoles-singleuser]]
=== Consola en modo monousuario

En la crossref:boot[boot-singleuser,Modo monousuario] encontrará una descripción detallada de lo que es «modo monousuario». No importa que sólo exista una consola cuando ejecuta FreeBSD en modo monousuario. No hay otra consola virtual disponible. Las configuraciones de la consola en modo monousuario se pueden encontrar también en [.filename]#/etc/ttys#. Busque la línea que comienza por `console`:

[.programlisting]
....
# name  getty                           type    status          comments
#
# Si la consola está marcada como "insecure", entonces init
# le pedirá la contraseña de root al entrar a modo monousuario.
console none                            unknown off secure
....

[NOTE]
====
Tal y como indican los comentarios por encima de la línea `console`, puede editar esta línea y cambiar `secure` por `insecure`. Si lo hace, cuando FreeBSD arranque en modo monousuario el sistema le pedirá la contraseña de `root`.

_Tenga cuidado si cambia esto a ``insecure``_. Si olvida la contraseña de `root` arrancar en modo monousuario será con seguridad más complicado. Sigue siendo posible, pero será un poco difícil para alguien que no esté familiarizado con le proceso de arranque de FreeBSD y los programas involucrados en dicho proceso.
====

[[consoles-vidcontrol]]
=== Cambio del modo de video de la consola

La consola FreeBSD por omisión tiene un modo de video que puede ajustarse a 1024x768, 1280x1024 o cualquier otra resolución que admita su chip gráfico y su monitor. Si quiere utilizar uno diferente tendrá que recompilar su kernel con estas dos opciones añadidas:

[.programlisting]
....
options VESA
options SC_PIXEL_MODE
....

Una vez recompilado el kernel con esas dos opciones en él determine qué modos de video admite su hardware; para ello use man:vidcontrol[1]. Con lo siguiente le mostrará una lista de modos de video soportados:

[source,shell]
....
# vidcontrol -i mode
....

La salida de esta orden es una lista de los modos de que admite su tarjeta. Para elegir uno de ellos tendrá que ejecutar man:vidcontrol[1] en una consola como `root`:

[source,shell]
....
# vidcontrol MODE_279
....

Si el modo de video que ha elegido le parece adecuado puede configurarlo de forma permanente haciendo que funcione desde el momento del arranque; para ello debe editar [.filename]#/etc/rc.conf# file:

[.programlisting]
....
allscreens_flags="MODE_279"
....

[[permissions]]
== Permisos

FreeBSD, cuya raíz histórica es el UNIX(R) BSD, se fundamenta en varios conceptos clave de UNIX. El primero y más importante es que FreeBSD es un sistema operativo multi-usuario. El sistema puede gestionar múltiples usuarios trabajando simultáneamente y en tareas que no guarden relación entre sí. El sistema se encarga de compartir y administrar peticiones de dispositivos de hardware, periféricos, memoria y tiempo de CPU de manera equitativa para cada usuario.

Debido a que el sistema es capaz de soportar múltiples usuarios, todo lo que el sistema administra tiene un conjunto de permisos que usa para decidir quién puede leer, escribir y ejecutar un recurso. Estos permisos se guardan como octetos divididos en tres partes: una para el propietario del fichero, otra para el grupo al que el fichero pertenece, y otra para todos los demás grupos y usuarios. Veamos una representación numérica de esto:

[.informaltable]
[cols="1,1,1", frame="none", options="header"]
|===
| Valor
| Permiso
| Listado de directorio

|0
|No leer, no escribir, no ejecutar
|`---`

|1
|No leer, no escribir, ejecutar
|`--x`

|2
|No leer, escribir, no ejecutar
|`-w-`

|3
|No leer, escribir, ejecutar
|`-wx`

|4
|Leer, no escribir, no ejecutar
|`r--`

|5
|Leer, no escribir, ejecutar
|`r-x`

|6
|Leer, escribir, no ejecutar
|`rw-`

|7
|Leer, escribir, ejecutar
|`rwx`
|===

Puede utilizar el parámetro de línea de órdenes `-l` de man:ls[1] para ver un listado largo que incluya una columna con información acerca de los permisos de fichero para el propietario, grupo y los demás. Por ejemplo, un `ls -l` en un directorio puede mostrar algo como esto:

[source,shell]
....
% ls -l
total 530
-rw-r--r--  1 root  wheel     512 Sep  5 12:31 mifichero
-rw-r--r--  1 root  wheel     512 Sep  5 12:31 otrofichero
-rw-r--r--  1 root  wheel    7680 Sep  5 12:31 email.txt
...
....

Aquí está como se divide la primera columna de `ls -l`:

[source,shell]
....
-rw-r--r--
....

El primer caracter (más a la izquierda) indica si este fichero es un fichero regular, un directorio, un dispositivo especial de caracter, un socket o cualquier otro dispositivo especial pseudo-ficheroa . En este caso, el `-` un fichero regular. Los siguientes tres caracteres, `rw-` en este ejemplo, dan los permisos para el propietario del fichero. Los siguientes tres caracteres, `r--`, dan los permisos para el grupo al que el fichero pertenece. Los últimos tres caracteres, `r--`, dan los permisos para el resto del mundo. Un guión indica que el permiso está desactivado. En el caso de este fichero, los permisos están asignados de tal manera que el propietario puede leer y escribir en el fichero, el grupo puede leer el fichero, y el resto del mundo sólo puede leer el fichero. De acuerdo con la tabla de arriba, los permisos para este fichero serían `644`, donde cada dígito representa las tres partes de los permisos del fichero.

Todo ésto está muy bien, pero ?cómo controla el sistema los permisos de los dispositivos? FreeBSD en realidad trata la mayoría de los dispositivos hardware como un fichero que los programas pueden abrir, leer y en los que pueden escribir datos como si de cualquier otro fichero se tratara. Estos ficheros especiales de dispositivo se encuentran en el directorio [.filename]#/dev#.

Los directorios también son tratados como ficheros. Tienen permisos de lectura, escritura y ejecución. El bit de ejecución en un directorio tiene un significado ligeramente distinto que para los ficheros. Cuando un directorio está marcado como ejecutable significa que se puede mirar dentro, se puede hacer un «cd» (cambiar directorio) a él. Esto también significa que dentro del directorio es posible acceder a ficheros cuyos nombres son conocidos (sujeto, claro está, a los permisos de los ficheros mismos).

En particular, para poder realizar un listado de directorio, el permiso de lectura debe ser activado en el directorio, mientras que para borrar un fichero del que se conoce el nombre es necesario tener permisos de escritura _y_ ejecución en el directorio que contiene el fichero.

Existen más permisos, pero se usan principalmente en circunstancias especiales como los binarios ejecutables de tipo setuid y los los directorios de tipo «sticky». Si desea más información acerca de los permisos de ficheros y cómo establecerlos, consulte man:chmod[1]. 

=== Permisos simbólicos

Los permisos simbólicos, también conocidos como expresiones simbólicas, utilizan caracteres en lugar de valores octales para asignar permisos a ficheros o directorios. Las expresiones simbólicas utilizan la sintaxis de (quién) (acción) (permisos) mediante los siguientes valores:

[.informaltable]
[cols="1,1,1", frame="none", options="header"]
|===
| Opción
| Letra
| Representa

|(quién)
|u
|Usuario

|(quién)
|g
|Grupo propietario

|(quién)
|o
|Otro

|(quién)
|a
|Todos («todo el mundo»)

|(acción)
|+
|Añadir permisos

|(acción)
|-
|Quitar permisos

|(acción)
|=
|Activar permisos explícitamente

|(permisos)
|r
|Lectura

|(permisos)
|w
|Escritura

|(permisos)
|x
|Ejecución

|(permisos)
|t
|Bit Sticky («pegajoso»)

|(permisos)
|s
|Activar UID o GID
|===

Estos valores se aplican con man:chmod[1] de la misma manera que los anteriores, pero con letras. Por ejemplo, podría usar la siguiente orden para bloquear a otros usuarios el acceso a _FICHERO_:

[source,shell]
....
% chmod go= FICHERO
....

Puede usarse una lista separada por comas cuando se quiera aplicar más de un conjunto de cambios a un fichero. Por ejemplo la siguiente orden eliminará los permisos de escritura de grupo y «mundo» a _FICHERO_, y añade permisos de ejecución para todos:

[source,shell]
....
% chmod go-w,a+x FILE
....

=== Banderas de fichero en FreeBSD

Además de los permisos de fichero previamente expuestos, FreeBSD permite el uso de «banderas de fichero». Estas banderas añaden un nivel de seguridad y control adicional a los ficheros, pero no a los directorios.

Las banderas de fichero añaden un nivel adicional de control sobre los ficheros ayudando a asegurar que en algunos casos ni siquiera `root` pueda eliminar o alterar ficheros.

Las banderas de fichero se modifican mediante man:chflags[1], gracias a una interfaz muy sencilla. Por ejemplo, para habilitar la bandera imborrable de sistema en [.filename]#fichero1#, escriba lo siguiente:

[source,shell]
....
# chflags sunlink fichero1
....

Y para dehabilitar la bandera imborrable de sistema, simplemente escriba la orden previa con «no» antes de `sunlink`. Observe:

[source,shell]
....
# chflags nosunlink fichero1
....

Para ver las banderas de este fichero, utilice man:ls[1] con las opciones `-lo`:

[source,shell]
....
# ls -lo fichero1
....

La salida debería ser como esta:

[.programlisting]
....
-rw-r--r--  1 trhodes  trhodes  sunlnk 0 Mar  1 05:54 fichero1
....

Varias banderas solo pueden ser añadidas o retiradas de ficheros por el usuario `root`. En otros casos, el propietario del fichero puede activar estas banderas. Se recomienda que para más información la persona encargada de la administración del sistema consulte las páginas de manual man:chflags[1] y man:chflags[2].

=== Los permisos `setuid`, `setgid` y `sticky`

Además de los permisos que se han explicado hay más, hay tres tipos más que todos los administradores deberían conocer. Son los permisos `setuid`, `setgid` y `sticky`.

Estos permisos juegan un papel clave en ciertas operaciones UNIX(R) puesto que facilitan funcionalidades que no se suelen permitir a los usuarios normales. Para comprenderlas totalmente hay que comprender la diferencia entre el ID real del usuario y el ID efectivo.

El ID del usuario real es el UID que arranca (y el propietario) del proceso. El UID efectivo es el ID bajo el que se ejecuta el proceso. Veamos un ejemplo; el programa man:passwd[1] se ejecuta con el ID real del usuario puesto que el usuario está cambiando su contraseña. Pero para poder manipular la base de datos de contraseñas debe ejecutarse con el ID efectivo del usuario `root`. De este modo es posible que los usuarios cambien su contraseña sin llegar a ver un error de `Permission Denied` (permiso denegado).

[NOTE]
====
La opción `nosuid` de man:mount[8] hace que estos binarios den errores silenciosos, es decir, fallarán pero el usuario no recibirá ningún mensaje de error por ello. Esta opción no funciona siempre, pues, según la página man de man:mount[8], un «wrapper» `nosuid` puede sortear esta limitación.
====

El permiso setuid puede asignarse colocando un número cuatro (4) antes de los permisos. Se ve mejor con un ejemplo:

[source,shell]
....
# chmod 4755 ejemplosuid.sh
....

Los permisos de [.filename]#ejemplosuid.sh# deberían ser así:

[.programlisting]
....
-rwsr-xr-x   1 trhodes  trhodes    63 Aug 29 06:36 ejemplosuid.sh
....

Fíjese atentamente en la `s` que ha aparecido en los permisos del fichero, en la parte de los permisos del propietario; esa `s` está en donde estaría el bit de ejecución. Gracias a esto el funcionamiento de aplicaciones que necesitan permisos elevados, como `passwd`, pueden funcionar.

Si quiere ver un ejemplo con sus propios ojos abra dos terminales. En una arranque un proceso (ejecute) `passwd` con un usuario normal. Mientras la aplicación espera a que le de una nueva contraseña busque la información de usuario del proceso `passwd` en la tabla de procesos.

En la terminal A:

[source,shell]
....
Changing local password for trhodes
Old Password:
....

En la terminal B:

[source,shell]
....
# ps aux | grep passwd
....

[source,shell]
....
trhodes  5232  0.0  0.2  3420  1608   0  R+    2:10AM   0:00.00 grep passwd
root     5211  0.0  0.2  3620  1724   2  I+    2:09AM   0:00.01 passwd
....

Tal y como se ha dicho, un usuario normal puede ejecutar `passwd`, pero en realidad está utilizando el UID efectivo de `root`.

El permiso `setgid` actúa del mismo modo que el `setuid`, pero afecta a los permisos del grupo. Cuando una aplicación funciona con esta configuración lo hace con los permisos del grupo al que pertenece el fichero, no los del usuario que ha arrancado el proceso.

Si quiere utilizar el permiso `setgid` debe situar un núnmero dos (2) al principio de los permisos que vaya a asignar mediante `chmod`.

[source,shell]
....
# chmod 2755 ejemplosuid.sh
....

La nueva configuración tiene un aspecto muy similar a la que tenía antes, pero observe que la `s` de antes está ahora en el campo de los permisos de grupo:

[source,shell]
....
-rwxr-sr-x   1 trhodes  trhodes    44 Aug 31 01:49 ejemplosuid.sh
....

[NOTE]
====
En ambos ejemplos, incluso si el «script» en cuestión es ejecutable, no se va a ejecutar con un EUID distinto o un ID efectivo de usuario porque los «scripts» de shell no pueden acceder a la llama del sistema man:setuid[2].
====

Los dos permisos que acabamos de mostrar los bits de permisos (`setuid` y `setgid`) pueden reducir el nivel de seguridad haciendo que se escalen los permisos. Pero hay un tercer bit especial de permisos que puede ser de mucha ayuda para reforzar la seguridad del sistema: el `sticky bit`.

El `sticky bit`( que podríamos traducir como «bit pegajoso») aplicado a un directorio hace que solamente el propietario de un fichero pueda borrarlo. Esto evita el borrado de ficheros ajenos en directorios públicos como [.filename]#/tmp#. Si quiere usarlo coloque un uno (1) antes de los permisos. Veamos un ejemplo:

[source,shell]
....
# chmod 1777 /tmp
....

Para ver el `;sticky bit` en acción usamos `ls`:

[source,shell]
....
# ls -al / | grep tmp
....

[source,shell]
....
drwxrwxrwt  10 root  wheel         512 Aug 31 01:49 tmp
....

El `sticky bit` es la letra `t` al final de los permisos.

[[dirstructure]]
== Estructura de directorios

La jerarquía del sistema de ficheros de FreeBSD es fundamental para obtener una compresión completa del sistema. El concepto más importante a entender es el del directorio raíz, «/». Este directorio es el primero en ser montado en el arranque y contiene el sistema básico necesario para preparar el sistema operativo para su funcionamiento en modo multiusuario. El directorio raíz también contiene puntos de montaje para cualquier otro sistema de ficheros que se pretenda montar.

Un punto de montaje es un directorio del que se pueden colgar sistemas de ficheros adicionales en un sistema padre (que suele ser el directorio raíz). Esto se explica con detalle en la <<disk-organization>>. Los puntos de montaje estándar son, por ejemplo, [.filename]#/usr#, [.filename]#/var#, [.filename]#/tmp#, [.filename]#/mnt# y [.filename]#/cdrom#. Estos directorios suelen corresponderse con entradas en [.filename]#/etc/fstab#. [.filename]#/etc/fstab# es una tabla que sirve de referencia al sistema y contiene los diferentes sistemas de ficheros y sus respectivos puntos de montaje. La mayoría de los sistemas de ficheros en [.filename]#/etc/fstab# se montan automáticamente en el arranque gracias al «script» man:rc[8], a menos que contengan la opción `noauto`. Si quiere más información consulte la <<disks-fstab>>.

Veremos ahora una descripción de los directorios más comunes. Si desea información más completa consulte man:hier[7].

[.informaltable]
[cols="1,1", frame="none", options="header"]
|===
| Directorio
| Descripción

|[.filename]#/#
|Directorio raíz del sistema de ficheros.

|[.filename]#/bin/#
|Utilidades de usuario fundamentales tanto para el ambiente monousuario como para el multiusuario.

|[.filename]#/boot/#
|Programas y ficheros de configuración necesarios durante el arranque del sistema operativo.

|[.filename]#/boot/defaults/#
|Ficheros de configuración por omisión del arranque; ver man:loader.conf[5].

|[.filename]#/dev/#
|Nodos de dispositivo; ver man:intro[4].

|[.filename]#/etc/#
|Ficheros de configuración y «scripts» del sistema.

|[.filename]#/etc/defaults/#
|Ficheros de configuración por omisión del sistema; ver man:rc[8].

|[.filename]#/etc/mail/#
|Ficheros de configuración para agentes de transporte de correo como man:sendmail[8].

|[.filename]#/etc/namedb/#
|Ficheros de configuración de `named`; ver man:named[8].

|[.filename]#/etc/periodic/#
|«Scripts» que se ejecutan diariamente, semanalmente y mensualmente mediante man:cron[8]; ver man:periodic[8].

|[.filename]#/etc/ppp/#
|Ficheros de configuración de `ppp`; ver man:ppp[8].

|[.filename]#/mnt/#
|Directorio vacío utilizado de forma habitual por administradores de sistemas como punto de montaje temporal.

|[.filename]#/proc/#
|Sistema de ficheros de procesos; ver man:procfs[5], man:mount_procfs[8].

|[.filename]#/rescue/#
|Programas enlazados estáticamente para restauraciones de emergencia; ver man:rescue[8].

|[.filename]#/root/#
|Directorio local para la cuenta `root`.

|[.filename]#/sbin/#
|Programas del sistema y utilidades fundamentales de administración para ambientes monousuario y multiusuario.

|[.filename]#/tmp/#
|Ficheros temporales. El contenido de [.filename]#/tmp#_NO_ suelen conservarse después de un reinicio del sistema. Los sistemas de ficheros basados en memoria suelen montarse en [.filename]#/tmp# Puede automatizarse mediante variables de tmpmfs en man:rc.conf[5] (o con una entrada en [.filename]#/etc/fstab#; ver man:mdmfs[8], o para FreeBSD 4.X, man:mfs[8]).

|[.filename]#/usr/#
|La mayoría de utilidades y aplicaciones de usuario.

|[.filename]#/usr/bin/#
|Aplicaciones comunes, herramientas de programación y otras aplicaciones.

|[.filename]#/usr/include/#
|Ficheros «include» estándar de C.

|[.filename]#/usr/lib/#
|Bibliotecas.

|[.filename]#/usr/libdata/#
|Ficheros de datos con diversas funciones.

|[.filename]#/usr/libexec/#
|Dæmons del sistema y utilidades del sistema (ejecutados por otros programas).

|[.filename]#/usr/local/#
|Ejecutables locales, bibliotecas, etc. también se usa como destino por omisión de la infraestructura de ports de FreeBSD. Dentro de [.filename]#/usr/local# debe seguirse el esquema general definido en man:hier[7] para [.filename]#/usr#. Las excepciones son el directorio man, que está directamente bajo [.filename]#/usr/local# en lugar de debajo de [.filename]#/usr/local/share#, y la documentación de los ports está en [.filename]#share/doc/port#. 

|[.filename]#/usr/obj/#
|Arbol destino dependiente de arquitectura fruto de la compilación del árbol [.filename]#/usr/src#.

|[.filename]#/usr/ports#
|La colección de Ports de FreeBSD (opcional).

|[.filename]#/usr/sbin/#
|Dæmons del sistema y utilidades del sistema (ejecutados por usuarios del sistema).

|[.filename]#/usr/shared/#
|Ficheros independientes de arquitectura.

|[.filename]#/usr/src/#
|Ficheros fuente BSD y/o local.

|[.filename]#/usr/X11R6/#
|Ejecutables de la distribución X11R6, bibliotecas, etc (opcional).

|[.filename]#/var/#
|Ficheros multipropósito de log, temporales, en tránsito y de «spool». En ocasiones se monta en [.filename]#/var# un sistema de ficheros basado en memoria.

|[.filename]#/var/log/#
|Diversos ficheros de log del sistema.

|[.filename]#/var/mail/#
|Ficheros de buzones de correo de usuarios.

|[.filename]#/var/spool/#
|Directorios diversos del sistema de spool de impresora y correo.

|[.filename]#/var/tmp/#
|Ficheros temporales. Suelen conservarse tras el Estos ficheros suelen conservarse tras el reinicio del sistema, a menos que [.filename]#/var# sea un sistema de ficheros basado en memoria.

|[.filename]#/var/yp#
|Mapas NIS.
|===

[[disk-organization]]
== Organización de disco

La unidad más pequeña que FreeBSD utiliza para ubicar ficheros es el nombre de fichero. Los nombres de fichero son sensibles a las mayúsculas, lo que significa que [.filename]#readme.txt# y [.filename]#README.TXT# son dos ficheros distintos. FreeBSD no utiliza la extensión ([.filename]#.txt#) de un fichero para determinar si es un programa, o un documento o alguna otra forma de datos.

Los ficheros se almacenan en directorios. Un directorio puede estar vacío, o puede contener cientos de ficheros. Un directorio también puede contener otros directorios, permitiéndole contruir una jerarquía de directorios dentro de otro. Esto hace mucho más fácil la organización de sus datos.

Para referirse a ficheros o directorios se usa el nombre de archivo o de directorio, seguido por una barra, `/`, seguido por cualquier otro nombre de directorio que sea necesario. Si tiene un directorio [.filename]#tal#, el cual contiene el directorio [.filename]#cual#, el cual contiene el fichero [.filename]#readme.txt#, entonces el nombre completo o _ruta_ al fichero es [.filename]#tal/cual/readme.txt#.

Los directorios y ficheros se almacenan en un sistema de ficheros. Cada sistema de ficheros contiene un sólo directorio en el nivel más elevado, que es el _directorio raíz_ de ese sistema de ficheros. Este directorio raíz puede contener otros directorios.

Lo visto hasta ahora probablemente sea similar a cualquier otro sistema operativo que pueda haber utilizado, pero hay unas cuantas diferencias; por ejemplo, MS-DOS(R) utiliza `\` para separar nombres de fichero y directorio, mientras que Mac OS(R) usa `:`.

FreeBSD no utiliza letras de unidades, u otro nombre de unidad en la ruta. Por tanto, no podrá escribir [.filename]#c:/tal/cual/readme.txt# en FreeBSD.

En FreeBSD, en cambio, un sistema de ficheros recibe el nombre de _sistema de ficheros raíz_. El directorio raíz del sistema de ficheros raíz se representa como `/`. Cualquier otro sistema de ficheros, por tanto, se _monta_ bajo el sistema de ficheros raíz. No importa cuántos discos tenga en su sistema FreeBSD, cada directorio parecerá ser parte del mismo disco.

Suponga que tiene tres sistemas de ficheros, denominados `A`, `B` y `C`. Cada sistema de ficheros tiene un directorio raíz, el cual contiene otros dos directorios, llamados `A1`, `A2` (y de la misma manera `B1`, `B2` y `C1`, `C2`).

Usaremos `A` como sistema de ficheros raíz. Si usara `ls` para ver el contenido de este directorio vería dos subdirectorios, `A1` y `A2`. El árbol de directorios sería como este:

image::example-dir1.png[]

Un sistema de ficheros debe montarse en un directorio de otro sistema de ficheros. Ahora suponga que monta el sistema de ficheros `B` en el directorio `A1`. El directorio raíz de `B` reemplaza a `A1`, y los directorios en `B` aparecen de esta manera:

image::example-dir2.png[]

Cualquier fichero que esté en el directorio `B1` o `B2` puede encontrarse con la ruta [.filename]#/A1/B1# o [.filename]#/A1/B2# según sea necesario. Cualquier fichero que esté en [.filename]#/A1# ha desaparecido temporalmente. Aparecerán de nuevo si `B` se _desmonta_ de A.

Si `B` se monta en `A2` entonces el diagrama se vería así:

image::example-dir3.png[]

y las rutas serían [.filename]#/A2/B1# y [.filename]#/A2/B2# respectivamente.

Pueden montarse sistemas de ficheros uno sobre otro. Continuando con el ejemplo anterior, el sistema de ficheros `C` podría montarse en el directorio `B1` en el sistema de ficheros `B`, lo que nos llevaría a esto:

image::example-dir4.png[]

O `C` podría montarse directamente en el sistema de ficheros `A`, bajo el directorio `A1`:

image::example-dir5.png[]

Si está familiarizado con MS-DOS(R) esto es similar, aunque no idéntico, a utilizar `join`.

Esto no es algo a lo deba usted dedicar tiempo de forma habitual. Normalmente creará sistemas de ficheros al instalar FreeBSD y decidirá dónde montarlos; lo más habitual es que no los cambie de sitio a menos que agregue un disco nuevo.

Es perfectamente posible tener un sistema de ficheros raíz extenso y no necesitar crear otros. Este esquema tiene unos cuantos inconvenientes y una ventaja: 

.Ventajas de disponer de múltiples sistemas de ficheros
* Si dispone de varios sistemas de ficheros puede optar por usar distintas _opciones de montaje_. Por ejemplo, gracias a una planificación cuidadosa, el sistema de ficheros raíz puede montarse como sólo-lectura, haciendo imposible borrar sin querer o editar un fichero crítico. Al mantener separados sistemas de ficheros en los que los usuarios pueden escribir, como [.filename]#/home#, de otros sistemas de ficheros también le permite montar con la opción _nosuid_; dicha opción previene que los bits _suid_/_guid_ en los ejecutables almacenados en el sistema de ficheros tengan efecto, mejorando en cierto modo la seguridad.
* FreeBSD optimiza automáticamente el esquema de ficheros en un sistema de ficheros, dependiendo de cómo el sistema de ficheros esté siendo utilizado. Uno que contenga muchos ficheros pequeños tendrá una optimización distinta de uno que contenga menos ficheros y más grandes. Si sólo tiene un gran sistema de ficheros no hay manera de aplicar esta optimización.
* Los sistemas de ficheros de FreeBSD son muy robustos en caso de sufrir un caída eléctrica. De todas maneras, un fallo eléctrico en un momento crítico puede dañar la estructura del sistema de ficheros. Si reparte sus datos en múltiples sistemas de ficheros hará que sea más probable que el sistema arranque después de uno de esos fallos, haciéndole además más fácil la tarea de restaurarlo desde un respaldo si fuera necesario.

.Ventajas de un sólo sistema de ficheros
* Los sistemas de ficheros son de un tamaño fijo. Si crea un sistema de ficheros cuando instala FreeBSD y le da un tamaño específico, tal vez descubra más tarde que necesita hacer la partición más grande. Esto no es fácil de realizar sin hacer una copia de seguridad, crear de nuevo el sistema de ficheros con el nuevo tamaño y entonces restaurar los datos respaldados.
+
[IMPORTANT]
====
FreeBSD dispone de man:growfs[8], que permite incrementar el tamanño de un sistema de ficheros «al vuelo», eliminando esta limitación.
====

Los sistemas de ficheros están alojados en particiones. Este es un detalle muy importante, puesto que el término _partición_ no significa aquí lo mismo que en otros entornos (por ejemplo, en MS-DOS(R)) debido a la herencia UNIX(R) de FreeBSD. Cada partición se identifica con una letra desde `a` hasta `h`. Cada partición puede contener solamente un sistema de ficheros, lo que significa que los sistemas de ficheros suelen definirse mediante su punto de montaje en la jerarquía del sistema de ficheros o por la letra de la partición en la que están alojados.

FreeBSD también utiliza espacio de disco como _espacio de intercambio (swap)_. El espacio de intercambio le brinda a FreeBSD _memoria virtual_. Esto permite al su sistema comportarse como si tuviera más memoria de la que realmente tiene. Cuando a FreeBSD se le agota la memoria mueve algunos de los datos que no está utilizando en ese momento al espacio de intercambio, y los vuelve a poner donde estaban (desplazando alguna otra cosa) cuando los necesita.

Algunas particiones tienen ciertas convenciones heredadas.

[.informaltable]
[cols="1,1", frame="none", options="header"]
|===
| Partición
| Representación

|`a`
|Normalmente contiene el sistema de ficheros raíz

|`b`
|Normalmente contiene el espacio de intercambio (swap)

|`c`
|Suele tener el mismo tamaño de la «slice» que la encierra. Esto permite a las utilidades que necesitan trabajar en toda la «slice» entera (por ejemplo durante una búsqueda de bloques dañados) trabajar en la partición `c`. Normalmente no debería usted crear un sistema de ficheros en esta partición.

|`d`
|La partición `d` solía tuvo un significado especial asociado pero ya no lo tiene.
|===

Cada partición que contiene un sistema de ficheros se almacena en lo que FreeBSD llama una «slice». «slice» es en FreeBSD lo que en otros ámbitos se denomina partición; es un hecho que deriva de los orígenes de FreeBSD como ya sabemos basado en UNIX(R).

Los números de «slice» muestran el nombre de dispositivo, al que precede una `s` y un número que puede ser un 1 u otro número mayor. Por lo tanto «da0__s1__» es la primera slice en la primera unidad SCSI. Sólo puede haber cuatro «slice» físicas en un disco, pero puede haber «slice» lógicas dentro «slice» físicas del tipo apropiado. Estas «slice»extendidas se numeran a partir de 5, así que «ad0__s5__» es la primera «slice» extendida en el primer disco IDE. Estos dispositivos se usan en sistemas de ficheros que se preve que ocupen una slice.

Tanto las «slice» y las unidades físicas «peligrosamente dedicadas», como otras unidades contienen _particiones_, que se designan mediante letras desde la `a` hasta `h`. Esta letra se añade al nombre del dispositivo. Se verá mucho mejor mediante ejemplos: «da0__a__» es la partición a en la primera unidad da y es una de esas a las que llamamos «peligrosamente dedicada». «ad1s3__e__» es la quinta partición en la tercera slice de la segunda unidad de disco IDE.

Para terminar, cada disco en el sistema tiene también su designación. El nombre de disco comienza por un código que indica el tipo de disco, luego un número, que indica qué disco es. A diferencia de las «slice», la numeración de discos comienza desde 0. Puede las numeraciones más comunes en el <<basics-dev-codes>>.

Cuando se hace referencia a una partición, FreeBSD necesita que también se nombre la «slice» y el disco que contiene la partició. Esto se hace con el nombre de disco, `s`, el número «slice» y por último la letra de la partición. Tiene varios casos en el <<basics-disk-slice-part>>.

En el <<basics-concept-disk-model>> muestra un modelo conceptual del esquema de un disco que debería ayudarle a aclarar las cosas.

Antes de instalar FreeBSD tendrá que configurar las «slice» de disco, después crear particiones dentro de las «slice» que vaya a usar en FreeBSD y luego crear un sistema de ficheros (o swap) en cada partición y luego decidir cuál va a ser el punto de montaje del sistema de ficheros.

[[basics-dev-codes]]
.Códigos de dispositivos de disco
[cols="1,1", frame="none", options="header"]
|===
| Código
| Significado

|[.filename]#ad#
|Disco ATAPI (IDE)

|[.filename]#da#
|Disco de acceso directo SCSI

|[.filename]#acd#
|CDROM ATAPI (IDE)

|[.filename]#cd#
|CDROM SCSI

|[.filename]#fd#
|Disquete (floppy)
|===

[[basics-disk-slice-part]]
.Ejemplo de nombres de disco, «slice» y partición
[example]
====
[.informaltable]
[cols="1,1", frame="none", options="header"]
|===
| Nombre
| Significado

|`ad0s1a`
|La primera partición (`a`) en la primera slice (`s1`) en el primer disco IDE (`ad0`).

|`da1s2e`
|La quinta partición (`e`) en la segunda slice (`s2`) en el segundo disco SCSI (`da1`).
|===
====

[[basics-concept-disk-model]]
.Modelo conceptual de un disco
[example]
====
Este diagrama muestra cómo ve FreeBSD el primer disco IDE en el sistema. Se asume que el disco es de 4 GB, y contiene dos «slices» de 2 GB (particiones MS-DOS(R)). La primera partición contiene un disco MS-DOS(R), [.filename]#C:#, y la segunda partición contiene una instalación de FreeBSD. Esta instalación de ejemplo tiene tres particiones, y una partición swap.

Cada una de las tres particiones tiene un sistema de ficheros. La partición `a` se utilizará para el sistema de ficheros raíz, `e` para la jerarquía del directorio [.filename]#/var#, y `f` para la jerarquía del directorio [.filename]#/usr#.

image::disk-layout.png[]

====

[[mount-unmount]]
== Montaje y desmontaje de sistemas de ficheros

El sistema de ficheros se visualiza mejor como un árbol enraizado, tal y como esá, en [.filename]#/#. [.filename]#/dev#, [.filename]#/usr# y todos los demás directorios en el directorio raíz son raamas, las cuales pueden tener sus propias ramas, como [.filename]#/usr/local# y así sucesivamente.

Existen varias razones para albergar algunos de estos directorios en sistemas de ficheros separados. [.filename]#/var# contiene los directorios [.filename]#log/#, [.filename]#spool/# y varios tipos de ficheros temporales y pueden llegar a desbordarse. Agotar el espacio del sistema de ficheros raíz no es nada bueno desde cualquier punto de vista, así que separar [.filename]#/var# de de [.filename]#/# es algo que debería hacerse siempre que sea posible.

Otra razón para meter ciertos árboles de directorios en otros sistemas de ficheros es si van a estar albergados en discos físicos separados, o si son discos virtuales separados, como un montaje por crossref:advanced-networking[network-nfs,NFS] en el caso de unidades de CDROM.

[[disks-fstab]]
=== El fichero [.filename]#fstab#

Durante el crossref:boot[boot,proceso de arranque] los sistemas de ficheros listados en [.filename]#/etc/fstab# se montan automáticamente (a menos que estén listados con la opción `noauto`).

[.filename]#/etc/fstab# contiene una lista de líneas con el siguiente formato:

[.programlisting]
....
dispositivo       /punto-de-montaje punto de montaje     opciones      dumpfreq     passno
....

`dispositivo`::
Un nombre de dispositivo (_debe existir_).

`punto-de-montaje`::
Un directorio (que debe existir) en el que montar el sistema de ficheros.

`tipo de sistema ficheros`::
El tipo de sistema de ficheros es un parámetro que interpretará man:mount[8]. El sistema de ficheros por omisión de FreeBSD es `ufs`.

`opciones`::
Ya sea `rw` para sistemas de ficheros de lectura-escritura, o `ro` para sistemas de ficheros de sólo lectura, seguido de cualquier otra opción que sea necesaria. Una opción muy habitual es `noauto`, que se suele usar en sistemas de ficheros que no se deben montar durante la secuencia de arranque. Tiene otras opciones en la página de manual de man:mount[8].

`dumpfreq`::
man:dump[8] la usa para determinar qué sistema de ficheros requieren volcado. Si el campo no está declarado se asume un valor de cero.

`passno`::
Determina el orden en el cual los sistemas de ficheros deben revisarse. Los sistemas de ficheros que hayan de saltarse deben tener su `passno` a cero. El sistema de ficheros raíz (que obviamente debe ser revisado antes que cualquier otro) debe tener su `passno` puesto a uno, y los demás sistemas de ficheros deben tener valores mayores que uno. Si más de un sistema de ficheros tiene el mismo `passno` man:fsck[8] tratará de revisarlos en paralelo en caso de ser posible. 

Consulte la página de manual de man:fstab[5] para mayor información sobre el formato del fichero [.filename]#/etc/fstab# y las opciones que contiene.

[[disks-mount]]
=== La orden `mount`

man:mount[8] es al fin y al cabo quien monta los sistemas de ficheros.

En su forma más básica se usa lo siguiente:

[source,shell]
....
# mount dispositivo punto-de-montaje
....

Existe una gran cantidad de opciones (las encontrará todas en man:mount[8]) pero las más comunes son:

.Opciones de montaje
`-a`::
Montar todos los sistemas de ficheros que aparezcan en [.filename]#/etc/fstab#, excepto aquellos marcados como «noauto», excluidos por el parámetro `-t` o aquellos que ya estén montados.

`-d`::
Realizar todo excepto la llamada real de montaje del sistema. Esta opción es muy útil en caso de problemas si se combina con la opción `-v` para determinar qué es lo que man:mount[8] está haciendo realmente.

`-f`::
Forzar el montaje de un sistema de ficheros inestable (por ejemplo uno que da errores tras un reinicio súbito, algo que es bastante _peligroso_), o forzar la revocación de accesos de escritura cuando se cambia el estado de un sistema de ficheros de lectura-escritura a solo lectura.

`-r`::
Montar el sistema de ficheros como sólo lectura. Esto es idéntico a utilizar el argumento `ro` (`rdonly` para versiones anteriores a FreeBSD 5.2) en la opción `-o`.

`-t` _tipo de sistema de ficheros_::
Montar un sistema de ficheros dado con el tipo de sistema de ficheros, o montar solamente sistemas de ficheros del tipo dado si se proporciona la opción `-a`.
+
«ufs» es el sistema de ficheros por omisión.

`-u`::
Actualizar puntos de montaje en el sistema de ficheros.

`-v`::
Mostrar mayor información.

`-w`::
Montar el sistema de ficheros como lectura-escritura.

La opción `-o` toma una lista las siguientes opciones separada por comas:

nodev::
No interpretar dispositivos especiales en el sistema ficheros. Es una opción de seguridad que puede ser muy útil.

noexec::
No permitir la ejecución de binarios en este sistema de ficheros. Esta también es una opción de seguridad útil.

nosuid::
No interpretar bits setuid o setgid en el sistema de ficheros. Esta también es una opción de seguridad útil.

[[disks-umount]]
=== La orden `umount`

man:umount[8] toma como parámetro un punto de montaje, un nombre de dispositivo, o la opción `-a` o `-A`.

Todas las formas toman `-f` para forzar el desmontaje y `-v` para mostrar más información. Tenga muy en cuenta que usar `-f` no suele ser una forma recomendable de proceder. Desmontar a la fuerza los sistemas de ficheros puede acarrear el congelar la máquina o dañar los datos en el sistema de ficheros.

`-a` y `-A` se usan para desmontar todos los sistemas de ficheros montados, con la ventaja de poder elegir el tipo de sistema de ficheros que se use tras `-t`. De todas maneras `-A` no trata de desmontar el sistema de ficheros raíz.

[[basics-processes]]
== Procesos

FreeBSD es un sistema operativo multitarea. Esto significa que parece como si más de un programa se estuviera ejecutando al mismo tiempo. Cada programa uno de esos programas que se está ejecutando en un momento dado se denomina _proceso_. Cada orden que ejecuta iniciará al menos un proceso nuevo, y hay muchos procesos que se están que se están ejecutando en todo momento, manteniendo el sistema en funcionamiento.

Cada proceso tiene un identificador individual consistente en un número llamado _ID del proceso_, o _PID_, y al igual que sucede con los ficheros, cada proceso tiene un propietario y un grupo. La información de propietario y grupo se usa para determinar qué ficheros y dispositivos puede abrir el proceso mediante los permisos de fichero explicados anteriormente. La mayoría de los procesos también tiene un proceso padre. El proceso padre es el proceso que los inició. Por ejemplo, si está tecleando órdenes en la shell, la shell es un proceso, y cualquier orden que usted ejecute también lo será. De este modo cada proceso que ejecute tendrá como proceso padre a su shell. La excepción es un proceso especial llamado man:init[8]. `init` es siempre el primer proceso, así que su PID siempre es 1. El kernel arranca automáticamente `init` en el arranque de FreeBSD.

Hay dos órdenes particularmente útiles para ver los procesos en el sistema, man:ps[1] y man:top[1]. `ps` se usa para mostrar una lista estática de los procesos que se ejecutan en el sistema en es momento, y puede mostrar sus PID, cuánta memoria está usando, la línea de órdenes con la que fueron iniciados y muchas más cosas. `top` despliega todos los procesos que se están ejecutando y actualiza la pantalla cada pocos segundos para que pueda ver lo que está haciendo su sistema.

Por omisión `ps` solo le muestra las órdenes que están ejecutando _y_ que sean propiedad de su usuario. Por ejemplo:

[source,shell]
....
% ps
  PID  TT  STAT      TIME COMMAND
  298  p0  Ss     0:01.10 tcsh
 7078  p0  S      2:40.88 xemacs mdoc.xsl (xemacs-21.1.14)
37393  p0  I      0:03.11 xemacs freebsd.dsl (xemacs-21.1.14)
48630  p0  S      2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi
48730  p0  IW     0:00.00 (dns helper) (navigator-linux-)
72210  p0  R+     0:00.00 ps
  390  p1  Is     0:01.14 tcsh
 7059  p2  Is+    1:36.18 /usr/local/bin/mutt -y
 6688  p3  IWs    0:00.00 tcsh
10735  p4  IWs    0:00.00 tcsh
20256  p5  IWs    0:00.00 tcsh
  262  v0  IWs    0:00.00 -tcsh (tcsh)
  270  v0  IW+    0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16
  280  v0  IW+    0:00.00 xinit /home/nik/.xinitrc -- -bpp 16
  284  v0  IW     0:00.00 /bin/sh /home/nik/.xinitrc
  285  v0  S      0:38.45 /usr/X11R6/bin/sawfish
....

Como puede ver en este ejemplo la salida de man:ps[1] está organizada en columnas. `PID` es el ID de proceso anteriormente expuesto. Los PIDs se asignan a partir del 1 y hasta 99999, y vuelven a comenzar desde el 1 otra cuando se terminan los números. La columna `TT` muestra la tty en la que el programa se está ejecutando; podemos ignorarla tranquilamente por el momento. `STAT` muestra el estado del programa; de momento también podemos ignorarlo. `TIME` es la cantidad de tiempo que el programa ha se ha estado ejecutando en la CPU (generalmente no es el tiempo transcurrido desde que se inició el programa, ya que la mayoría de los programas pasan mucho tiempo esperando antes de que necesiten gastar tiempo en la CPU. Finalmente, `COMMAND` es la línea de órdenes que se empleó para ejecutar el programa.

man:ps[1] admite muchas opciones sobre la información que se desea ver. Uno de los conjuntos más útiles es `auxww`. `a` muestra información acerca de todos los procesos ejecutándose, no solamente los suyos. `u` despliega el nombre de usuario del propietario del proceso, así como el uso de memoria. `x` despliega información acerca de los procesos dæmon y `ww` hace que man:ps[1] despliegue la línea de órdenes completa, en lugar de truncarla cuando es demasiado larga para caber en la pantalla.

La salida de man:top[1] es similar. Veamos un ejemplo: 

[source,shell]
....
% top
last pid: 72257;  load averages:  0.13,  0.09,  0.03    up 0+13:38:33  22:39:10
47 processes:  1 running, 46 sleeping
CPU states: 12.6% user,  0.0% nice,  7.8% system,  0.0% interrupt, 79.7% idle
Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free
Swap: 256M Total, 38M Used, 217M Free, 15% Inuse

  PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
72257 nik       28   0  1960K  1044K RUN      0:00 14.86%  1.42% top
 7078 nik        2   0 15280K 10960K select   2:54  0.88%  0.88% xemacs-21.1.14
  281 nik        2   0 18636K  7112K select   5:36  0.73%  0.73% XF86_SVGA
  296 nik        2   0  3240K  1644K select   0:12  0.05%  0.05% xterm
48630 nik        2   0 29816K  9148K select   3:18  0.00%  0.00% navigator-linu
  175 root       2   0   924K   252K select   1:41  0.00%  0.00% syslogd
 7059 nik        2   0  7260K  4644K poll     1:38  0.00%  0.00% mutt
...
....

La salida está dividida en dos secciones. La cabecera (las primeras cinco líneas) muestra el PID del último proceso en ejecutarse, la carga promedio del sistema (una medida de la carga del sistema), el «uptime» del sistema (tiempo desde el último reinicio) y la hora actual. Las otras cifras en la cabecera se relacionan con cuántos procesos hay en ejecución en el sistema (47 en este caso), cuánta memoria y espacio de intercambio (swap) está en uso, y cuánto tiempo está el sistema en diferentes estados de CPU.

Más abajo hay una serie de columnas con información similar a la salida de man:ps[1]. Igual que antes, puede usted ver el PID, el nombre de usuario, la cantidad de tiempo de CPU en uso y la orden que se ejecutó. man:top[1] también mostrará por omisión la cantidad de espacio de memoria que emplea cada proceso. Está dividido en dos columnas, una para el tamaño total y otra para el tamaño residente (el tamaño total es cuánta memoria ha necesitado la aplicación y el tamaño residente es cuánta se está usando en ese momento concreto). En este ejemplo puede verse que man:getenv[3] requerido casi 30 MB de RAM, pero actualmente solo está usando 9 MB.

man:top[1] actualiza automáticamente el listado cada dos segundos, pero este lapso puede cambiarse mediante la opción `s`.

[[basics-daemons]]
== Dæmons, señales y cómo matar procesos

cuando ejecuta un editor es fácil controlarlo, decirle que cargue ficheros y demás. Puede hacerse porque el editor permite ese control y porque el editor depende de una _terminal_. Algunos programas no están diseñados para ejecutarse entradas continuas por parte del usuario, así que se desconectan de la terminal a la primera oportunidad. Por ejemplo, un servidor web pasa todo el dia respondiendo peticiones web y normalmente no necesita que usted le haga caso. Los programas que transportan correo electrónico de un sitio a otro son otro ejemplo de esta clase de aplicación.

Llamamos a estos programas _dæmons_. Los Dæmons eran personajes de la mitología griega; no eran ni buenos ni malos, eran pequeños espíritus sirvientes que, en gran medida, hacían cosas útiles por la humanidad. Algo muy parecido a cómo los servidores web y los servidores de correo hacen hoy día tantas cosas útiles para nosotros. Por eso, desde hace mucho tiempo la mascota de BSD es ese dæmon de aspecto tan ufano con su tridente y su cómodo calzado deportivo.

Hay una norma según la cual se da nombre a los programas que suelen ejecutarse como dæmons con una «d» final. BIND es el dæmon de nombres de Berkeley (y el programa que en realidad se ejecuta se llama `named`); el servidor web Apache se llama `httpd`, el dæmon de «spool» de impresora de línea es `lpd` y así sucesivamente. Se trata de un acuerdo, no una ley férrea; por ejemplo el dæmon principal de correo de Sendmail se llama `sendmail`, y no `maild`, como podría suponerse visto lo precedente.

Algunas veces necesitará comunicarse con un dæmon. Estas comunicaciones se denominan _señales_; es posible comunicarse con un dæmon (o con cualquier otro proceso ejecutándose) mandándole una señal. Existen diversos tipos de señales diferentes que puede mandar: algunas tienen un significado especial, otras son interpretadas por la aplicación y la documentación de la aplicación le dirá cómo interpreta la señal esa aplicación). Solamente puede enviar una señal a un del que sea usted propietario. Si manda una señal a un proceso de otro usuario con man:kill[1] o man:kill[2] verá un mensaje del sistema en el que se le comunica que no tiene permiso para hacer tal cosa. La excepción a esto es el usuario `root`, que puede mandar señales a los procesos de cualquier usuario del sistema.

FreeBSD también enviará señales de aplicación en determinados casos. Si una aplicación está mal escrita y trata de acceder a memoria a la que no está previsto que acceda FreeBSD manda al proceso la señal _Violación de segmento_ (`SIGSEGV`). Si una aplicación ha utilizado la llamada de sistema man:alarm[3] para ser avisada después de que un periodo de tiempo haya transcurrido se le mandará la señal de alarma (`SIGALRM`), y así sucesivamente.

Hay dos señales que pueden usarse para detener un proceso, `SIGTERM` y `SIGKILL`. `SIGTERM` es la manera amable de matar un proceso; el proceso puede _recibir_ la señal, darse cuenta que usted quiere que se apague, cerrar cualquier fichero de log que pueda tener abierto y generalmente terminar cualquier tarea que esté realizando en ese momento antes de apagarse. En algunos casos un proceso puede incluso ignorar `SIGTERM` si se encuentra inmerso en una tarea que no puede ser interrumpida.

Por el contrario, un proceso no puede ignorar una señal `SIGKILL`. Esta es la señal «No me importa lo que estás haciendo, detente ahora mismo». Si manda un `SIGKILL` a un proceso FreeBSD detendrá ese proceso inmediatamente..

Otras señales que puede usar: `SIGHUP`, `SIGUSR1` y `SIGUSR2`. Son señales de propósito general, y aplicaciones diferentes pueden hacer cosas diferentes cuando se utilicen.

Suponga que ha cambiado el fichero de configuración de su servidor web; es un buen momento para decirle al servidor web que lea y aplique la configuración. Podría detener y reiniciar `httpd`, pero esto implicaría un período breve de suspensión del servicio de su servidor web, lo cual puede no ser asumible. La mayoría de los dæmons fueron creados pensando en que fueran capaces de responder a la señal `SIGHUP` releyendo su fichero de configuración. En lugar de matar y reiniciar `httpd` le podría mandar la señal `SIGHUP`. Dado que no hay una manera estándar para responder a estas señales, diferentes dæmons tendrán diferente comportamiento, así que asegúrese de leer la documentación del dæmon en cuestión.

Las señales se envian mediante man:kill[1], como puede verse en el siguiente ejemplo.

[.procedure]
====
*Procedure: Envío de una señal a un proceso*

Este ejemplo muestra como enviar una señal a man:inetd[8]. El fichero de configuración de `inetd` es [.filename]#/etc/inetd.conf# e `inetd` releerá dicho fichero de configuración cuando se le envíe un `SIGHUP`.

. Identifique el ID de proceso del proceso al que quiere enviarle la señal mediante man:ps[1] y man:grep[1]. man:grep[1] se usa para buscar cadenas de texto de su elección en la salida estándar. Puede ejecutarse como un usuario normal, mientras que man:inetd[8] se ejecuta como `root`, así que debe pasarle los parámetros `ax` a man:ps[1].
+
[source,shell]
....
% ps -ax | grep inetd
198  ??  IWs    0:00.00 inetd -wW
....
+
Vemos que el PID de man:inetd[8] es 198. En algunos casos `grep inetd` también puede aparecer en esta salida. Esto se debe a la manera en que man:ps[1] tiene que encontrar la lista de procesos ejecutándose.
+
. Utilice man:kill[1] para enviar la señal. Debido a que man:inetd[8] está siendo ejecutado po `root` tendrá que usar primero man:su[1] para volverse `root`.
+
[source,shell]
....
% su

# /bin/kill -s HUP 198
....
+
Del mismo modo que la mayoría de órdenes UNIX(R) man:kill[1] no imprimirá ninguna salida si ha funcionado bien. Si envía una señal a un proceso del que no es el propietario verá lo siguiente: `kill: _PID_: Operation not permitted`. Si no teclea bien el PID puede enviar la señal a un proceso equivocado, lo cual puede ser malo, o si tiene suerte, habrá enviado la señal a un proceso que no está en uso y verá el sistema le dirá `kill: _PID_: No such process`.

[NOTE]
.¿Por qué utilizar `/bin/kill`?
======
Muchas shells incorporan su propio `kill`; esto es, el shell mandará la señal directamente, en lugar de ejecutar [.filename]#/bin/kill#. Esto puede ser útil pero las diferentes shells tienen diferentes sintaxis para especificar el nombre de la señal que envían. En lugar de tratar de aprederse todas ellas, es más fácil simplemente usar `/bin/kill ...` sea la que sea la shell que prefiera usar.
======
====

El envío de otras señales es muy similar; sustituya `TERM` o `KILL` en la línea de órdenes según sea necesario.

[IMPORTANT]
====
Matar procesos aleatorios en el sistema es una mala idea. En particular, man:init[8], ID de proceso 1, es muy especial. Ejecutar `/bin/kill -s KILL 1` es una manera rápida de apagar su sistema. _Siempre_ revise dos veces los argumentos con los que ejecuta man:kill[1] _antes_ de pulsar kbd:[Intro].
====

[[shells]]
== Shells

En FreeBSD gran parte del trabajo diario se hace en una interfaz de línea de órdenes llamada shell. El trabajo principal de la shell es ir recibiendo órdenes mediante un canal de entrada y ejecutarlos. Muchas shells también tienen funciones integradas para ayudar ayudar con las tareas diarias como manipulación de ficheros, gestión de archivos con expresiones regulares, edición en la propia línea de órdenes, macros de órdenes y variables de entorno. FreeBSD incluye diversas shells, como `sh`, el shell Bourne y `tcsh`, el shell C mejorado. Hay muchas otras shells disponibles en la colección de ports de FreeBSD, como `zsh` y `bash`.

?Qué shell usar? es una cuestión de gustos. Si va a programar en C puede preferir usar una shell tipo C, como `tcsh`. Si viene del mundo Linux o si es nuevo en la interfaz de línea de órdenes de UNIX(R) puede probar con `bash`. Tenga en cuenta que cada shell posee unas propiedades únicas que pueden o no funcionar con su entorno de trabajo preferido y que puede usted elegir qué shell usar.

Una de las propiedades comunes de las shell es que completan los nombres de fichero. Una vez que ha introducido las primeras letras de una orden o del nombre de un fichero, se puede hacer que la shell complete automáticamente el resto de la orden o nombre de fichero pulsando la tecla kbd:[Tab]. Veamos un ejemplo. Suponga que tiene dos ficheros llamados [.filename]#talcual# y [.filename]#tal.cual#. Usted quiere borrar [.filename]#tal.cual#. Lo que habría que teclear es: `rm ta[tabulador].[tabulador]`.

La shell mostraría en pantalla `rm ta[BIP].cual`.

El [BIP] es la campana de la consola, es decir, la shell está diciéndome que no pudo completar totalmente el nombre de fichero porque hay más de una coincidencia. Tanto [.filename]#talcual# como [.filename]#tal.cual# comienzan por `ta`, pero solo se pudo completar hasta `tal`. Si se teclea `.`, y de nuevo kbd:[tabulador] la shell es capaz de añadir el resto del nombre de fichero.

Otra función de la shell son las variables de entorno. Las variables de entorno son parejas de valores clave almacenados en el espacio de entorno del shell. Este espacio puede ser leído por cualquier programa invocado por la shell y por lo tanto contiene mucha configuración de programas. Esta es una lista de las variables de entorno más comunes y su significado:

[.informaltable]
[cols="1,1", frame="none", options="header"]
|===
| Variable
| Descripción

|`USER`
|Nombre de usuario en el sistema.

|`PATH`
|Lista de directorios, separados por punto y coma, en los que se buscan ejecutables.

|`DISPLAY`
|Nombre de red de la pantalla X11 a la que conectarse, si está disponible.

|`SHELL`
|La shell actual.

|`TERM`
|El nombre de la terminal del usuario. Se usa para determinar las características de la terminal.

|`TERMCAP`
|Base de datos donde encontrar los códigos de escape necesarios para realizar diferentes funciones en la terminal.

|`OSTYPE`
|Tipo de sistema operativo. Por ejemplo, FreeBSD.

|`MACHTYPE`
|Arquitectura de CPU en la que se está ejecutando el sistema.

|`EDITOR`
|El editor de texto preferido por el usuario.

|`PAGER`
|El paginador de texto preferido por el usuario.

|`MANPATH`
|Lista de directorios separados por punto y coma en los que se buscan páginas de manual.
|===

Establecer una variable de entorno difiere ligeramente de shell a shell. Por ejemplo, en las shells al estilo C como `tcsh` y `csh`, se usa `setenv` para establecer las variables de entorno. Bajo shells Bourne como `sh` y `bash`, se usa `export` para establecer las variables de entorno actuales. Por ejemplo, para establecer o modificar la variable de entorno `EDITOR` (bajo `csh` o `tcsh`) la siguiente orden establece `EDITOR` como [.filename]#/usr/local/bin/emacs#:

[source,shell]
....
% setenv EDITOR /usr/local/bin/emacs
....

Bajo shells Bourne:

[source,shell]
....
% export EDITOR="/usr/local/bin/emacs"
....

También se puede hacer que la mayoría de las shells muestren el contenido de una variable de entorno situando el carácter `$` delante del nombre de la variable en la línea de órdenes. Por ejemplo, `echo $TERM` mostrará cualquiera que sea el valor que haya establecido para `$TERM`, porque la shell expande el valor de `$TERM` y se lo pasa al programa `echo`.

Las shells manejan muchos caracteres especiales, llamados metacaracteres, como representaciones especiales de datos. El más común es el caracter `\*`, que representa cualquier número de caracteres en un nombre de fichero. Estos metacaracteres especiales se pueden usar para la expansión de nombres de fichero. Por ejemplo, teclear `echo *` es casi lo mismo que introducir `ls` porque la shell toma todos los ficheros que coinciden con `*` y se los pone en la línea de órdenes para que `echo` los vea.

Para evitar que la shell interprete estos caracteres especiales pueden escamotearse anteponiéndoles una contrabarra (`\`). `echo $TERM` imprime el nombre de terminal que esté usando. `echo \$TERM` imprime `$TERM`, literalmente.

[[changing-shells]]
=== Cómo cambiar su shell

La manera más fácil de cambiar de shell es mediante `chsh`. `chsh` le colocará dentro del editor que esté configurado en la variable de entorno `EDITOR`; si no la ha modificado, el sistema ejecutará `vi`, el editor por omisión. Cambie la línea «Shell:» según sus gustos.

También se le puede suministrar a `chsh` la opción `-s`; ésto establecerá la shell sin necesidad de entrar en el editor de texto. Si por ejemplo quiere que `bash` sea su shell por omisión puede configurarlo del siguiente modo:

[source,shell]
....
% chsh -s /usr/local/bin/bash
....

Ejecutar `chsh` sin parámetros y editar la shell desde ahí también funciona.

[NOTE]
====
La shell que se desee usar _debe_ estar incluida en [.filename]#/etc/shells#. Si se ha instalado una shell desde la crossref:ports[ports,colección de ports] esto deberí estar hecho automáticamente. Si ha instalado la shell manualmente, tendrá usted que realizar el cambio oportuno en [.filename]#/etc/shells#.

Por ejemplo, si instaló manualmente `bash` y lo ubicó en [.filename]#/usr/local/bin# debería hacer lo siguiente:

[source,shell]
....
# echo /usr/local/bin/bash  /etc/shells
....

Hecho esto vuelva a ejecutar `chsh`.
====

[[editors]]
== Editores de texto

Gran parte de la configuración de FreeBSD se realiza modificando ficheros de texto, así que le conviene familiarizarse con alguno de ellos. FreeBSD viene con unos cuantos como parte del sistema base y encontrará muchos más en la colección de ports.

El editor de textos más sencillo y fácil de aprender es uno llamado ee, cuyo nombre proviene del inglés «easy editor» (editor fácil). Para iniciar ee se debe teclear en la línea de órdenes `ee nombre-de-fichero`, donde _nombre-de-fichero_ es el nombre del fichero que se quiere editar. Por ejemplo, para editar [.filename]#/etc/rc.conf# teclée `ee /etc/rc.conf`. Una vez dentro de `ee` todas las órdenes para manipular las funciones del editor están listadas en la parte superior de la pantalla. El caracter `^` representa la tecla kbd:[Ctrl] del teclado, por lo tanto `^e` significa la combinación de teclas kbd:[Ctrl+e]. Para salir de ee pulse la tecla kbd:[Esc] y elija abandonar («leave») el editor. El editor preguntará entonces si quiere conservar los cambios si el fichero hubiera sido modificado.

FreeBSD viene también con editores de texto mucho más potentes, como vi, como parte del sistema base, mientras que otros editores, como Emacs y vim son parte de la colección de ports de FreeBSD (package:editors/emacs[] y package:editors/vim[]). Estos editores son muchísimo más poderosos, pero tienen la desventaja de ser un poco más complicados de aprender a manejar. De cualquier manera si planea hacer mucho trabajo de edición de texto, aprender a usar un editor de texto más poderoso como vim o Emacs le ahorrará muchísimo más tiempo a la larga.

[[basics-devices]]
== Dispositivos y nodos de dispositivos

Dispositivo es un término utilizado la mayoría de las veces para actividades relacionadas con hardware del sistema, como discos, impresoras, tarjetas gráficas y teclados. Cuando FreeBSD arranca, la mayoría de lo que FreeBSD despliega son dispositivos en el momento de ser detectados. Si lo desea, puede volver a ver todos los mensajes que el sistema emite durante el arranque consultando [.filename]#/var/run/dmesg.boot#.

Por ejemplo, [.filename]#acd0# es la primera unidad CDROM IDE, mientras que [.filename]#kbd0# representa el teclado.

En un sistema operativo UNIX(R) debe accederse a la mayoría de estos dispositivos a través de ficheros especiales llamados nodos de dispositivo, que se encuentran en el directorio [.filename]#/dev#.

=== Creación de nodos de dispositivo

Cuando agregue un nuevo dispositivo a su sistema, o compile soporte para dispositivos adicionales, puede que necesite crear uno o más nodos de dispositivo. 

==== `DEVFS` Dispositivo de sistema de ficheros (DEVice File System)

El dispositivo de sistema de ficheros, o `DEVFS`, ofrece acceso a dispositivos del espacio de nombres del kernel en el espacio de nombres del sistema de ficheros global. En lugar de tener que crear y modificar nodos de dispositivo, `DEVFS` se encarga del mantenimiento dinámico de este sistema de fichero.

Consulte man:devfs[5] si quiere más información.

[[binary-formats]]
== Formatos binarios

Para poder entender por qué FreeBSD utiliza el formato man:elf[5] primero debe saber ciertas cosas sobre los tres formatos de ejecutables «dominantes» en UNIX(R):

* man:a.out[5]
+ 
El formato objeto de UNIX(R) más antiguo y «clásico». Utiliza una cabecera corta y compacta con un número mágico al inicio que se usa frecuentemente para identificar el formato (vea man:a.out[5] para más información). Contiene tres segmentos cargados: .text, .data, y .bss además de una tabla de símbolos y una tabla de cadena («strings»).
* COFF
+ 
El formato objeto de SVR3. La cabecera consiste en una tabla de sección, para que pueda tener más contenido además de las secciones .text, .data, y .bss.
* man:elf[5]
+ 
Es el sucesor de COFF; dispone de secciones múltiples y valores posibles de 32-bits o 64-bits. Una gran desventaja: ELF fué también diseñado asumiendo que solamente existiría una ABI por cada arquitectura de sistema. Esa suposición es en realidad bastante incorrecta y ni siquiera en el mundo comercial SYSV (el cual tiene al menos tres ABIs: SVR4, Solaris y SCO) se puede dar por buena.
+ 
FreeBSD trata de solucionar este problema de alguna manera ofreciendo una herramienta para _marcar_ un ejecutable ELF conocido con información acerca de la ABI con la que funciona. Si quiere más información consulte la página de manual de man:brandelf[1]. 

FreeBSD viene del campo «clásico» y ha utilizado el formato man:a.out[5], una tecnología usada y probada en muchas de muchas generaciones de versiones de BSD hasta el inicio de la rama 3.X. Aunque era posible compilar y ejecutar binarios nativos ELF (y kernels) en un sistema FreeBSD desde algún tiempo antes de esto, FreeBSD al principio se mantuvo «contra corriente» y no cambió a ELF como formato por defecto. ?Por qué? Bueno, cuando el mundo Linux efectuó su dolorosa transición a ELF no fué tanto por huir del formato [.filename]#a.out# como por su inflexible mecanismo de bibliotecas compartidas basado en tablas de saltos, que hacía igual de difícil la construcción de bibliotecas compartidas tanto para los desarrolladores como para los proveedores. Ya que las herramientas ELF disponibles ofrecían una solución al problema de las bibliotecas compartidas y eran vistas por mucha gente como «la manera de avanzar», el costo de migración fué aceptado como necesario y se realizó la transición. El mecanismo de bibliotecas compartidas de FreeBSD está diseñado de manera más cercana al estilo del sistema de bibliotecas compartidas de SunOS(TM) de Sun y, como tal, es muy sencillo de utilizar.

Entonces, ?por qué existen tantos formatos diferentes?

En un tiempo muy, muy lejano, existía hardware simple. Este hardware tan simple soportaba un sistema pequeño, simple. [.filename]#a.out# era idóneo para el trabajo de representar binarios en este sistema tan simple (un PDP-11). A medida que la gente portaba UNIX(R) desde este sistema simple, retuvieron el formato [.filename]#a.out# debido a que era suficiente para los primeros portes de UNIX(R) a arquitecturas como 68k de Motorola, VAXen, etc.

Entonces algún brillante ingeniero de hardware decidió que si podía forzar al software a hacer algunos trucos sucios podría sortear ciertos obstáculos del diseño y permitir al núcleo de su CPU correr más rápidamente. Aunque estaba hecho para trabajar con este nuevo tipo de hardware (conocido entonces como RISC), [.filename]#a.out# no estaba bien adaptado para este hardware, así que varios formatos fueron desarrollados para obtener un rendimiento mayor de este hardware que el podía extraerse del limitado y simple formato [.filename]#a.out#. Así fué cómo COFF, ECOFF y algunos otros formatos más extraños fueron inventados y sus limitaciones exploradas hasta que se fué llegando a la elección de ELF.

Además, el tamaño de los programas estaba volviendose gigante y los discos (y la memoria física) eran relativamente pequeños, así que el concepto de una biblioteca compartida nació. El sistema VM también se volvió más sofisticado. A pesar de que todos estos avances se hicieron utilizando el formato [.filename]#a.out#, su utilidad se iba reduciendo paulatinamente con cada nueva opción. Además, la gente quería cargar cosas dinámicamente en el momento de ejecución, o descartar partes de su programa después de que el código de inicio se ejecutara para ahorrar memoria principal y espacio de swap. Al volverse más sofisticados los lenguajes, la gente empezó a ver la necesidad de introducir código antes del inicio del programa de forma automática. Se hicieron muchos hacks al formato [.filename]#a.out# para permitir que todas estas cosas sucedieran y lo cierto es que por un tiempo funcionaron. Pero [.filename]#a.out# no estaba para solucionar todos estos problemas sin incrementar la carga y complejidad del código. Aunque ELF resolvía muchos de estos problemas, en ese momento hubiera sido terrible dejar de lado un sistema que funcionaba, así que ELF tuvo que esperar hasta que fué más doloroso permanecer con [.filename]#a.out# que migrar a ELF.

De todas maneras, con el paso del tiempo las herramientas de compilación de las que FreeBSD derivó las suyas (en especial el ensamblador y el cargador) evolucionaron en dos árboles paralelos. El árbol FreeBSD FreeBSD añadió bibliotecas compartidas y corrigió algunos errores. La gente de GNU (que fueron quienes escribieron estos programas) los reescribió y añadieron una forma más simple de disponer de compiladores cruzados («cross compilers»), el uso de diferentes formatos, etc. Aunque mucha gente quería compiladores cruzados con FreeBSD como «blanco» no hubo suerte, porque los fuentes que que FreeBSD tenía para as y ld no estaban listos para cumplir esa tarea. La nueva cadena de herramientas GNU (binutils) soporta compilación cruzada, ELF, bibliotecas compartidas, extensiones C++, etc. Además, muchos proveedores están liberando binarios ELF y es algo muy bueno que FreeBSD los pueda ejecutar.

ELF es más expresivo que [.filename]#a.out# y permite un sistema base más extensible. Las herramientas ELF están mejor mantenidas y ofrecen soporte de compilación cruzada, muy importante para mucha gente. ELF puede ser un poco más lento que [.filename]#a.out#, pero tratar de medirlo puede ser difícil. También existen numerosos detalles que son diferentes entre los dos en cómo gestionan páginas, cómo gestionan código de inicio, etc. Ninguna es muy importante, pero las diferencias existen. Con el tiempo, el soporte para [.filename]#a.out# será eliminado del kernel [.filename]#GENERIC# y es muy posible que se elimine del kernel la posibilidad de ejecutar tales binarios una vez que la necesidad de usar programas [.filename]#a.out# haya pasado.

[[basics-more-information]]
== Más información

[[basics-man]]
=== Páginas de manual

La documentación más exhaustiva de FreeBSD está en las páginas de manual. Casi todos los programas del sistema vienen con un breve manual de referencia explicando el funcionamiento básico y sus diferentes argumentos. Estos manuales pueden revisarse mediante `man`. El uso de `man` es simple:

[source,shell]
....
% man orden
....

`orden` es el nombre de la orden sobre la que que desea saber más. Por ejemplo, para más información sobre `ls` escriba:

[source,shell]
....
% man ls
....

El manual en línea está dividido en secciones numeradas:

. Comandos de usuario.
. Llamadas al sistema y números de error.
. Funciones en las bibliotecas de C.
. Controladores de dispositivo.
. Formatos de fichero.
. Juegos y demás pasatiempos.
. Información sobre temas diversos.
. Comandos relacionados con el mantenimiento del sistema y su funcionamiento.
. Desarrolladores del Kernel.

En algunos casos, el mismo tema puede aparecer en más de una sección del manual en línea. Por ejemplo, existe una orden de usuario `chmod` y una llamada del sistema `chmod()`. En este caso se le puede decir a `man` cuál desea consultar especificando la sección:

[source,shell]
....
% man 1 chmod
....

Esto desplegará la página de manual de la orden de usuario `chmod`. Las referencias a una sección concreta del manual en línea tradicionalmente suelen colocarse entre paréntesis en la documentación escrita, por lo tanto man:chmod[1] se refiere a la orden de usuario `chmod` y man:chmod[2] se refiere a la llamada de sistema.

Esto está muy bien si se conoce el nombre del programa y simplemente se quiere saber como usarlo. Pero ?y si no puede recordar el nombre de la orden? Se puede usar man para que realice una búsqueda mediante palabras clave en las descripciones de programas utilizando el argumento `-k`:

[source,shell]
....
% man -k mail
....

Dicha orden mostrará una lista de órdenes que contengan la palabra clave «mail» en sus descripciones. Esto es funcionalmente equivalente a usar `apropos`.

Así que, ¿está viendo todos esos programas tan atractivos en [.filename]#/usr/bin# pero no tiene ni la menor idea de lo que la mayoría de ellos hace? Haga lo siguiente:

[source,shell]
....
% cd /usr/bin
% man -f *
....

o

[source,shell]
....
% cd /usr/bin
% whatis *
....

que hace exactamente lo mismo.

[[basics-info]]
=== Ficheros de información GNU: info

FreeBSD incluye muchas aplicaciones y utilidades producidas por la FSF (Free Software Foundation). Además de con las correspondientes páginas de manual, estos programas vienen con documentos de hipertexto más detallados, llamados ficheros `info`, los cuales pueden ser visualizados con `info`, o si tiene instalado emacs, con el modo info de emacs.

Si quiere utilizar la orden man:info[1] teclée:

[source,shell]
....
% info
....

Para una breve introducción teclée `h`. Cuando necesite una referencia rápida, teclée `?`.