Capítulo 3. Conceptos básicos de Unix

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®. Puede saltarse este capítulo si considera que ya conoce el funcionamiento de UNIX®. 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á:

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® está inmediatamente en sus manos cuando usa FreeBSD. Esta sección describe qué son «terminales» y «consolas» y cómo puede usarlas en FreeBSD.

FreeBSD, cuya raíz histórica es el UNIX® 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:

Puede utilizar el parámetro de línea de órdenes -l de 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:

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

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 /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 chmod(1).

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 Organización de disco. Los puntos de montaje estándar son, por ejemplo, /usr, /var, /tmp, /mnt y /cdrom. Estos directorios suelen corresponderse con entradas en /etc/fstab. /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 /etc/fstab se montan automáticamente en el arranque gracias al «script» rc(8), a menos que contengan la opción noauto. Si quiere más información consulte la El fichero fstab.

Veremos ahora una descripción de los directorios más comunes. Si desea información más completa consulte hier(7).

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 readme.txt y README.TXT son dos ficheros distintos. FreeBSD no utiliza la extensión (.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 tal, el cual contiene el directorio cual, el cual contiene el fichero readme.txt, entonces el nombre completo o ruta al fichero es 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® utiliza \ para separar nombres de fichero y directorio, mientras que Mac OS® usa :.

FreeBSD no utiliza letras de unidades, u otro nombre de unidad en la ruta. Por tanto, no podrá escribir 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:

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:

Cualquier fichero que esté en el directorio B1 o B2 puede encontrarse con la ruta /A1/B1 o /A1/B2 según sea necesario. Cualquier fichero que esté en /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í:

y las rutas serían /A2/B1 y /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:

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

Si está familiarizado con MS-DOS® 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:

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®) debido a la herencia UNIX® 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.

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®.

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 «da0s1» 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 «ad0s5» 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: «da0a» es la partición a en la primera unidad da y es una de esas a las que llamamos «peligrosamente dedicada». «ad1s3e» 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 Códigos de dispositivos de disco.

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 Ejemplo de nombres de disco, «slice» y partición.

En el Modelo conceptual de un disco 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.

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

Existen varias razones para albergar algunos de estos directorios en sistemas de ficheros separados. /var contiene los directorios log/, 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 /var de de / 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 NFS en el caso de unidades de CDROM.

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 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, ps(1) y 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:

Como puede ver en este ejemplo la salida de 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.

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 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 top(1) es similar. Veamos un ejemplo:

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 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ó. 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 getenv(3) requerido casi 30 MB de RAM, pero actualmente solo está usando 9 MB.

top(1) actualiza automáticamente el listado cada dos segundos, pero este lapso puede cambiarse mediante la opción s.

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 kill(1) o 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 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 kill(1), como puede verse en el siguiente ejemplo.

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

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® 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 Tab. Veamos un ejemplo. Suponga que tiene dos ficheros llamados talcual y tal.cual. Usted quiere borrar 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 talcual como tal.cual comienzan por ta, pero solo se pudo completar hasta tal. Si se teclea ., y de nuevo 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:

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 /usr/local/bin/emacs:

Bajo shells Bourne:

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.

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 /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 Ctrl del teclado, por lo tanto ^e significa la combinación de teclas Ctrl+e. Para salir de ee pulse la tecla 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 (editors/emacs y 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.

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 /var/run/dmesg.boot.

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

En un sistema operativo UNIX® 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 /dev.

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

FreeBSD viene del campo «clásico» y ha utilizado el formato 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 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™ 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. 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® desde este sistema simple, retuvieron el formato a.out debido a que era suficiente para los primeros portes de UNIX® 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), 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 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 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 a.out para permitir que todas estas cosas sucedieran y lo cierto es que por un tiempo funcionaron. Pero 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 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 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 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 a.out será eliminado del kernel GENERIC y es muy posible que se elimine del kernel la posibilidad de ejecutar tales binarios una vez que la necesidad de usar programas a.out haya pasado.