Guía de COMANDOS para uso desde una

1
LABSO. M. Maggio. Agosto 2010 V2.2
Guía de COMANDOS para uso desde una TERMINAL
Comentarios útiles
- GNU/Linux puede acceder a particiones DOS y Windows (FAT y NTFS).
- GNU/Linux tiene interfaz gráfica y modo texto (terminal-consola). La interfaz gráfica fue llamada en un
inicio “XFree86” y el modo texto “BASH”.
- Se pueden ejecutar muchos programas de DOS y Windows mediante emuladores en GNU/Linux.
­ No existe el concepto de unidad de disco. Todas las unidades en Linux se 'montan' como si fueran un subdirectorio más. ­ No existe el concepto de extensión del nombre de un archivo. Los ficheros­archivos pueden tener nombres de hasta 256 caracteres. Los puntos están permitidos en el nombre de un fichero. Así, un fichero se podrá llamar: DOSEMU­HOWTO.espanol.tar.gz, por poner un ejemplo. ­ Los subdirectorios no se separan con el carácter \ como en DOS, sino con el carácter /
Ejemplo: /usr/src/linux­1.2.13/Makefile
­ Existe diferencia entre mayúsculas y minúsculas. Por ejemplo, no es lo mismo TP1.txt que tp1.txt : son diferentes archivos.
­ Entre un comando y sus parámetros deberemos dejar obligatoriamente un espacio en blanco. Por ejemplo cd.. no funcionará mientras que cd .. sí lo hará. ­ Un sistema Linux NUNCA se puede apagar directamente. Antes le hemos de advertir al S.O. que vamos a apagarlo (o reiniciarlo). La razón de que esto deba ser así es para que al sistema le de tiempo de escribir en disco todos los datos que tuviera pendientes de escribir, salir ordenadamente de todas las aplicaciones que tuviera arrancadas y desmontar todas las unidades que tuviera montadas. - Se puede trabajar desde línea de comandos mediante una terminal. En Linux no hay una sola terminal sino
varias, con el nombre de “consolas” que se intercambian mediante ALT+F1, F2, F3, etc., o en otros casos
mediante CTRL+ ALT+F1, F2, F3, etc.
- El PROMPT
usuario@máquina [tty0] # _
(el usuario x está en la máquina y) (Máquina es el hostname, el anfitrión). Para separar la línea de
comandos del punto indicador se usa el signo # para el usuario root -administrador- y $ para el
usuario común.
[Nota: ver en Anexo 2 una introducción al shell y el Anexo 3 para el tema del PATH, es decir,
directorios que permiten ejecutar archivos]
- Para los sistemas que no muestran la ruta o lugar donde estamos ubicados hay que usar el
comando PWD
#pwd [print working directory, directorio de trabajo vigente]
El comando nos devolverá un path, es decir una ruta. Un “path absoluto” comienza desde el símbolo
de la raiz (/), por ejemplo /home/chino/notas . Un path relativo solo nos indica el nombre del
directorio al que queremos hacer referencia (por ejemplo, notas ).
Los símbolos . y .. tienen significado. El punto refiere al directorio actual. El doble punto refiere al
directorio inmediato superior.
- Qué usuario soy [nombre de usuario]
#whoami
2
- Ayuda para BASH
#man bash
#man “comando” [da la ayuda específica del comando solicitado]
#comando --help [cuando el manual de ayuda lo tiene el propio comando]
- Para saber qué bash usamos,
#info bash
- Comandos, argumentos y opciones:
Los comandos son órdenes que se le dan a la computadora para ejecutar una acción. Muchos
comandos realizan la acción sin necesidad de aclarar ni completar con nada (ejemplo pwd o clear)
en cambio a otros les tenemos que dar un argumento de trabajo, indicarles el camino a seguir y no
sólo decirles lo que hay que hacer, sino hacia dónde (ejemplo cd directorio). Por último, las
opciones nos permiten personalizar los resultados de las acciones.
- Qué linux estamos usando, versión de kernel, distribución, etc
#uname -a
- Apagar el sistema
#shutdown -h now [halt]
#init 0
- Reiniciar el sistema
#shutdown -r now o también
#init 6
reboot
- Terminar una sesión
#logout
-¿Quiénes están conectados al equipo?
#who
- Visualizar el calendario del mes actual
#cal
#cal 2009 [muestra el calendario de ese año]
#cal 10 2009 [muestra el mes de octubre de ese año]
- Visualizar fecha y hora del sistema
#date
- Visualizar el contenido de un directorio
#ls -l [completo y con columnas]
#ls -a [muestra incluso los archivos ocultos]
si queremos tener una visualización por páginas
|more
|less
- Colores usados por el comando ls
AZUL directorios
BLANCO archivos comunes
AMARILLO dispositivos
CELESTE enlaces
VERDE archivos binarios o ejecutables
3
- Permisos de archivos y directorios
Existen de tres tipos: Lectura (R), Escritura (W) y Ejecución en el caso de los programas (X)
Los directorios tendran una d en la primer columna cuando pedimos un ls -l
-Borrar la pantalla
#clear
o usar ctrl+l
- Visualización de archivos de texto: comando CAT
#cat mitexto.txt
[simple, sin paginación]
- Visualización con LESS
permite desplazarse dentro del archivo, si es extenso
#less file1.txt
[permite volver hacia páginas anteriores]
- Visualización con MORE
#more file.txt
[muestra el contenido con pausa entre pantallas]
- Crear un archivo vacío con TOUCH
#touch file.txt
- Creación de archivos de texto: comando CAT
#cat>mitexto.txt
primera linea
segunda
tercera
ultima
CTRL+d [manda una señal END of File y lo graba]
CTRL+c [cancela]
- Editores de texto
#joe
#vi
- Estructura de directorios
Cuando se inicia una sesión bajo un sistema Linux el lugar de ubicación inicial es el propio directorio
HOME.
Estructura lógica del sistema de archivos:
/
+­­­­+­­­­­+­­­­+­­­­+­­­­­+­­­­+­­­­­+­­­­­+­­­­+­­­­+­­­­+
bin boot dev etc home lib mnt proc sbin tmp usr var
| |
+­­­+­­­+ +­­­+­­­+
us1 us2 usn bin lib sbin
|
+­­­­­+
notes labs
4
El sistema de archivos de Linux está organizado jerárquicamente desde el directorio raíz [root] representado
/
por el símbolo .Esta manera de estructurar la información es conocida como “estructura de tipo árbol”.
Qué hay en cada directorio:*
/bin - almacena programas (binarios) esenciales que necesita el sistema cuando se inicia o mientras trabaja,
/boot - allí están las imágenes del kernel para el inicio y los archivos de configuración de booteo,
/dev - archivos usados para acceder a los dispositivos hardware,
/etc - archivos de la configuración del sistema,
/home - los archivos personales de los usuarios individuales,
/lib - módulos de librería utilizados por los programas,
/mnt - punto de montaje de los dispositivos de almacenamiento de datos [este directorio lo utilizamos para
montar disquetes, cds, discos rígidos, etc]
/proc - almacena datos acerca de los procesos activos,
/sbin - almacena comandos requeridos para administrar el sistema,
/tmp - archivos temporales,
/usr - programas, librerías, documentación, etc utilizada por los usuarios comunes,
/var - datos del sistema almacenados acerca de usos y accesos frecuentes (system logs, mail and print, spool
files, etc.)
* Ver en el Anexo 1 una explicación más detallada.
- Dentro del directorio /home cada usuario tendrá su propio directorio:
/home/carlos
/home/luis
- MTOOLS
Algunas distribuciones utilizan comandos mtools, iguales que los de DOS, pero con una M delante.
Así es posible colocar letras para copiar archivos y para acceder a un disquete formateado bajo
DOS.
- Archivos importantes para la configuración del sistema
/etc/fstab → Este archivo contiene información sobre los dispositivos que se montaran automáticamente durante el
arranque del sistema.
/etc/apt/sources.list → Aquí encontramos la lista de repositorios.
/etc/passwd → Este archivo controla el uso de usuarios, en contraseñas, con permisos y grupos que pertenecen a
cada usuario, archivo muy importante si uno quiere tener un superusuario además que el ya conocido root.
/boot/grub/menu.lst → Aquí tenemos la configuración de GRUB (gestor de arranque).
/etc/X11/xorg.conf → Este archivo contiene la configuración del entorno gráfico (pantalla, teclado, ratón, tarjeta
gráfica ...).
/etc/network/interfaces → interfaces Este archivo contiene los datos de configuración de la red.
- Para iniciar en el modo gráfico hay tres comandos que pueden andar: xinit, startx, kdm
- Para buscar archivos con LOCATE
#locate nombre-archivo
En el caso de no funcionar puede que no esté creada la base de datos de los nombres de archivos.
Para crearla: #updatedb
- Buscar archivos con FIND
Del siguiente modo se puede buscar un archivo desde la raiz en adelante de modo recursivo:
#find / -name archivo
5
- Comando CHMOD
Administra el sistema de permisos sobre archivos y directorios
Los permisos son R (lectura), W (escritura) y X (ejecución, -para programas-).
Para ver los permisos usar ls –l.
Si antes de rwx aparece la letra d quiere decir que es es un directorio.
Si no hay permisos, en vez de una letra hay un guión “-”.
- ¿A quién le damos ese permiso?
U (usuario), G (grupo), O (otros usuarios), A (all, todos los usuarios).
- Ejemplo de chmod:
chmod u+x [archivo] (el usuario gana permisos de ejecución)
chmod g-w [archivo] (el grupo pierde el permiso de escritura)
- Para cambiar hacia superusuario directamente,
#su
pide la contraseña de inmediato
Para volver al usuario normal, #exit
- SUDO: En Ubuntu no es necesario pasar a superusuario, se puede usar el comando sudo cada vez
del siguiente modo
$sudo comando correspondiente
- Creación de usuarios
#adduser nombre
- Cambio de contraseña
#passwd nombre
Manipulación de directorios
#cd nombre [entra a nombre]
#cd .. [atrás]
#cd [va a tu directorio personal]
#mkdir nombre [crea un directorio]
#rmdir nombre [elimina un directorio]
Manipulación de archivos
#rm file.ext [elimina archivos] RM
#cp file.ext /dirdestino [copia archivos] CP
#mv file.ext /destino [mueve un archivo] MV
#mv file.ext file.ext [cambia el nombre de un archivo]
Manipulación de discos
- Espacio libre en cada unidad
#df [disk free space] Da el espacio libre de los dispositivos montados.
- Dispositivos en Linux: HD, Floppy, CD
Se deben montar para tener acceso a ellos. Comando mount. Es uno de los elementos más básicos
para la navegación desde línea de comandos. Se pueden crear directorios dentro de /mnt para allí
montar los dispositivos.
6
FD0 la disquetera.
HDA (primer disco)
HDA1, 2, 3, y siguientes son las particiones.
HDB (segundo disco)
HDB1 (primer partición del segundo disco)
Los discos serial ata aparecerán como SDA. Los discos flash (pendrive, etc.) aparecerán también
como SD (A, B, C, y siguientes).
- Montar un disco
A diferencia de los sistemas Micro$oft, aquí los dispositivos deben ser montados y desmontados por
el usuario en la mayoría de los casos. Cuando se hacen tareas de administración sobre un disco
montado los cambios son efectuados al desmontarlo.
# mount -t msdos /dev/fd0 /mnt/fd0 [para montar un diskette. En algunos casos habrá que crear
el directorio dentro de /mnt. Sino podemos montarlo dentro de /mnt directo, aunque es más
desprolijo]. [En lugar de msdos se puede utilizar vfat].
#mount -t iso9660 /dev/hdb /mnt/hdb
/dev/cdrom /mnt/cdrom
- Desmontar
#umount /mnt/fd0
- Formatear discos
#mke2fs -c /dev/fd0
/dev/hda1
#fdformat [formatea disketes en bajo nivel. Ver #man fdformat]
- Particionar Discos Rígidos
#cfdisk
- Para comprobar la integridad de una partición
#fsck PARTICION
Otros comandos:
- #top [muestra el uso del cpu y los procesos que se ejecutan]
- #free [muestra el uso de la memoria]
- #ps [muestra los procesos que corren en el sistema. Si utilizamos el modificador -aux nos dará un
completo listado].
- #kill PID (número de identificación del proceso, aparece en la primer columna del comando ps.
Sirve para matar un proceso que no responde).
- Midnight Commander
#mc
sirve para navegar el sistema de modo semi gráfico.
7
- Comando tar, genera un archivo a partir de varios.
#tar -cf archivo.tar arch1 arch2 arch3 ... [cf, crear archivo, y agrega todos los archivos que le
indiquemos al .tar determinado]
#tar -xvf archivo.tar [extraer el contenido de un archivo, x extrae, v muestra el contenido
detallado, f archivo]
#tar -tvf archivo.tar
[muestra el contenido del archivo tar, la t es de list]
- GZIP: comprimir y descomprimir archivos .gz
Es necesario siempre comprimir los archivos tar pues quedan con altos valores en bytes. Al final el
archivo tiene el formato .tar.gz, aunque podemos aplicar el gzip directamente en un archivo común.
#gzip -d archivo [-d decompress]
#gzip -1 archivo [-1 fast hasta -9 better compress]
8
ANEXO 1
Por Fernando Pissani
UN SOLO ÁRBOL ( / )
Cuando ustedes trabajan en DOS-Windows tienen muchas raíces: la raíz del A:, la del C: la del CD-ROM y las de
otras particiones del hd, etc. La raíz del DOS se representa con el \ y como dijimos, hay muchas, una para cada
dispositivo o partición. En Linux/Unix hay sólo una /
Nota: recuerden que la raíz y la barra de separación de directorios, al revés del DOS, en Unix/Linux se representa
con la barra común /
Todos los dispositivos, sistemas, particiones, redes, etc., etc. se cuelgan de esa única raíz, que obviamente no tiene
letras ni nada y se representa con un /
En el capítulo anterior, cuando comenzamos a usar ls, veíamos cómo se veía la estructura tradicional de la raíz de
Linux (la / atrás de un nombre indica que es un directorio)
bin/
boot/
cdrom/
dev/
etc/
floppy/
home/
lib/
media/
mnt/
proc/
root/
sbin/
tmp/
usr/
var/
vmlinuz
En el de ustedes no estará el /cdrom y el /floppy en el raíz, pues se encuentran dentro del /mnt. Así lo usaba antes
Debian, lo pongo a título de ejemplo para que vean que puede ponerse en cualquier lado, aunque hay que tender a
respetar los acuerdos que se hagan que verán que hoy tienden a guardar esos directorios en /media
Dentro de cada uno de estos directorios se guardan ciertos tipos de archivos, hay convenciones, aunque no
siempre ocurre así, de acuerdo a las distribuciones u otras versiones de Unix. Pero la tendencia es a ir respetando
cada vez más cierto tipo de ordenamiento, que es el que vamos a trabajar en este curso.
LOS DIRECTORIOS DEL RAIZ
Ahora veremos un pantallazo sobre lo que contiene cada uno, aunque lo veremos más adelante en detalle en una
futura clase
/bin
En el directorio bin se guardan los binarios (se llama binarios a los ejecutables) de uso elemental y básico por
todos los usuarios. Por ej los programas ls y man estarán allí.
Recordemos que los ejecutables no se identifican por el .exe, el .com o el .bat del DOS, sino por si tienen la x en
el atributo, cualquiera que sea el nombre. Pero veremos que no están allí todos los ejecutables, sino los
elementales del sistema operativo.
/sbin
En el directorio sbin también se guardan los binarios, pero los binarios que son de uso del administrador del
sistema, del superusuario. De esta manera pueden bloquearse fácilmente ciertos ejecutables para que no los usen
los usuarios comunes. Si sumamos los archivos que están en /bin y en /sbin tendríamos los archivos
imprescindibles para el funcionamiento y mantenimiento del sistema operativo (diríamos los que tradicionalmente
se guardaban en el subdirectorio \dos u hoy en el \windows\command)
/etc
En el directorio etc estarán casi todas las configuraciones del sistema: desde los archivos que guardan las claves y
contraseñas, hasta los nombres y números IP de las distintas computadoras de la red, aparte de la propia. Allí
estará desde el mensajes de bienvenida del login, hasta la lista de los sistemas operativos que pueden cargarse en
el momento del booteo, los sistemas de archivos que se montan al momento de prenderse la computadora, la
9
configuración de la llamada al ISP, o de los que llamarán al servidor nuestro (si ponemos ese servicio) y cientos de
cosas más. Es el subdirectorio sobre el que más trabajamos a la hora de configurar Linux
/dev
En dev estarán todos los dispositivos del sistema presentes y futuros. Los discos rígidos y posibles particiones,
diskettes, cd, SCSI, modem, mouse, impresoras, etc, etc
¿Se acuerdan que en la parte anterior de la clase dijimos que todo se ve como archivos, que todos son archivos,
desde una impresora a un modem?. Están allí, con nombres convencionales que aprenderán a reconocer.
/lib
Este directorio tiene las librerías, generalmente en "C" (un lenguaje de programación y el fundamental en el
mundo Linux/Unix ya que permite portabilidad) que usará el núcleo u otros programas para ejecutarse, o para
compartir con otros programas. Por supuesto que habrá muchos subdirectorios porque cada programa
generalmente instalará sus librerías en su propio subdirectorio. En general aquí están las librerías del sistema,
encontraremos otro subdirectorio de librerías en el subdirectorio /usr/lib
Tengamos presente que en Unix/Linux está todo ordenado, no se ensucian los subdirectorios con instalaciones de
programas de los que quedan restos cuando lo borramos ni se superponen versiones (al menos no debería ocurrir).
/usr
En este directorio estarán los programas que instalemos. Veremos que también habrá dentro de él unos
subdirectorios que se llaman bin y sbin (/usr/bin /usr/sbin) donde guardaremos los ejecutables de los programas de
los usuarios, y los ejecutables del sistema que hemos instalado nosotros.
Generalmente aquí hay un subdirectorio importante /usr/src que es el que tendrá las fuentes de Linux, donde
podremos compilar el núcleo, cambiar cosas, etc si sabemos C o perl. También uno que llamamos local
(/usr/local) donde pondremos cosas nuestras. Y adentro de él también veremos que hay un bin y un sbin
Y también hay uno que se llama /usr/share donde van la mayoría de los programas (graficadores, oficina, juegos,
etc) que instalamos, así como los documentos, imágenes, etc. Todo esto lo iremos viendo en detalle más adelante.
/home
Los subdirectorios de los usuarios están dentro de home. Cuando en la computadora de la cabaña creamos un
nuevo usuario llamado sherlock, automáticamente se creó un subdirectorio llamado sherlock dentro de home. Por
ej, hoy en mi Linux, aparte de muchos otros subdirectorios de usuarios, están dentro de /home
alero/
fjpisani/
gcaplan/
sherlock/
Y adentro de cada propio subdirectorio uno hace lo que desea.
Verán que el superusuario, el root, no está con su propio subdirectorio allí. Como es un privilegiado no le gusta
codearse con la plebe así que tiene su propia casa en /root (en realidad es entre otras una medida de seguridad)
/root
root es entonces el home del superusuario (mi subdirectorio como fjpisani es /home/fjpisani)
Si como superusuario tecleo cd sin ningún parámetro automáticamente va a su home, es decir, adentro de /root o
sea es como decir cd /root
En cambio si estoy como sherlock y escribo cd voy directamente adentro de /home/sherlock
/proc
Hay un subdirectorio misterioso. Allí está lleno de nombres de archivos raros. Cuando la primera vez quise copiar
ese subdirectorio al disco de respaldo que estaba haciendo se me cruzaron los cables, porque no entendía lo que
estaba pasando. O no me daba bolilla o cuando ponía y arrancaba desde el respaldo no estaba lo que había copiado
y aparecían otras cosas.
Finalmente, como no entendía lo que pasaba y no me daba bolilla, lo ignoré, y no hice más respaldos de ese
subdirectorio, y aparentemente todo estaba perfecto sin él. Por lo tanto, si él me ignoró a mi, yo lo ignoré a él y
quedamos en paz.
Luego, leyendo y posteriomente probando, aprendí que lo que allí ocurre no existe en el disco rígido, es decir no
es un subdirectorio grabado en el disco rígido, son cosas que están ocurriendo en la memoria, los procesos que se
desencadenan al ejecutar un programa y otras informaciones. Cuando llamo a un programa, se activan procesos,
10
que se identifican con un número. Lo veremos luego en detalle
Bueno, allí, en esos archivos que están en /proc puedo saber lo que está pasando en el sistema. Pero son archivos
del tipo que conocíamos cuando no teníamos hd y hacíamos un c: virtual para engañar a los programas que lo
necesitaban, usando el "fabuloso" pedazo que quedaba entre los 640 y el mega. Si nadie pasó por esa experiencia,
ignoren el comentario. Lo concreto es que lo que está allí es virtual, está en la memoria y desaparece cuando se
apaga la computadora y permanentemente se va modificando según lo que hagamos, archivos aparecen, otros
desaparecen, etc.
Podemos pasarnos sin él, como él se pasa sin nosotros, aunque en algún momento podemos aprovechar algo de él,
lo veremos. Concretamente allí estará la información vital de nuestro hard, las interrupciones que se usan, datos de
todo tipo, reales y en tiempo real.
/boot
[editado por razones de uso] Acá están los archivos necesarios para el arranque del sistema, núcleo y cargador de
arranque, es decir, el famoso GRUB.
/mnt
Y hablando de tradicionales, encontraremos un directorio que se llama mnt, que sería mount sin las vocales. Allí
supuestamente deberíamos montar algún dispositivo cuando queremos acceder a él. En el ejemplo que vimos
antes, supongamos que tenemos un disquete que grabamos en w98 y queremos guardar esos archivos en el hd con
Linux.
Damos la orden
mount -t vfat /dev/fd0 /mnt
y luego podemos dar la orden de cp /mnt/* /home/sherlock y todos los archivos en el disquete se grabarán en el
subdirectorio /home/sherlock. Y si por ejemplo mi disco rígido tengo en la primer partición DOS o Windows y en
las demás mi sistema Linux. Estoy en Linux y quiero leer todo el disco C:, es fácil
mount -t vfat /dev/hda1 /mnt
luego hago un cd /mnt y un ls ¿y qué veré?: todo el disco C: con sus subdirectorios, etc.
Esto lo veremos luego, ahora lo estamos comentando.
Las distribuciones Red Hat, Mandriva, Fedora, Suse, Asware y otras, crea dentro de /mnt dos subdirectorios:
floppy y CD-ROM (es decir /mnt/floppy y /mnt/cdrom) sugiriéndonos que cuando tengamos que montar algo o
crear nuevos puntos de montaje, especialmente los "removibles", los pongamos allí.
Además, vienen con una orden en el archivo /etc/fstab de manera que por ejemplo para montar el disquete o el
CD-ROM no tenemos que poner todos los parámetros que dijimos, sino simplemente:
mount /mnt/floppy
o
mount /mnt/cdrom y ya está. Y para desmontar lo mismo sólo que con umount y el nombre del subdirectorio.
Lo importante de todo esto es que en Unix/Linux hay una sola raíz, y de ella se cuelga todo lo demás. Y que
existen ciertas convenciones, para que cuando guardemos algo lo hagamos con método, lo que facilita el borrado,
la desintalación, la búsqueda.
/media
Ahora la tendencia es poner los dispositivos como los señalados anteriormente en /mnt en un subdirectorio que se
llame /media. Ubuntu y varios basados en Debian lo hacen así.
/opt
Aquí se suelen guardar o instalar algunas aplicaciones, como por ejemplo el StarOffice, a veces el Openoffice, etc
/tmp
Bueno, está también el directorio /tmp que obviamente sirve para los archivos temporales, generalmente estará
vacío y comenzarán a aparecer archivos allí a media que ejecutemos programas y se vaciará cuando cerremos
Linux (por lo que nunca guardemos nada importante allí). Puede ocurrir que sigan quedando cosas luego de
apagar la computadora. Varios días después miramos allí y vemos que hay archivos con fechas viejas. Es decir, no
fueron borrados. ¿Por qué? porque algunas distribuciones planifican sus tareas de limpieza en ciertos horarios, por
11
ejemplo a media noche. Por lo que para que ese tarea diferida (cron) se realice deberíamos dejar la computadora
prendida todo el día, o cambiarle la hora o borrar a mano. Generalmente no hay problema de borrar archivos que
están en /tmp con fecha vieja.
/var
En el directorio var va todo lo que no metimos en los otros :-)
Y en cierta manera es cierto. No obstante es un directorio muy importante con subdirectorios que usaremos
mucho.
Dentro de var hay uno que se llama spool que tiene archivos muy útiles
Por ej en /var/spool/mail estarán todas las cartas que los usuarios reciben desde otras redes o sistemas antes de
levantarla desde sus computadoras vía telefónica o por red (o antes de mandarlas a su propio subdirectorios
/home/nombre-usuario, si se usa el servidor como depósito propio).
Por allí cerca estarán también todas las cartas que se están enviando, o las que no han encontrado salida y esperan
el momento para el reintento, que están en cola de espera.
También estarán los trabajos de impresión que están esperando en cola.
Otro importante es log (/var/log), especialmente cuando estamos configurando las cosas o para la administración
del sistema o para cuando alguna cosa no está saliendo bien. Es muy importante: allí se guardan todos los
mensajes periódicos del sistema: desde el error de un programa hasta quién fue el último en entrar al sistema o
cuántas veces entró este mes, a qué hora, etc, por poner ejemplos. Ya volveremos más adelante sobre él.
Si escribo
last gcaplan, ella vive en BsAs, el servidor de InterCol está en Rosario, veré cuándo anduvo por la computadora
por última vez. Y ella hará lo mismo, tecleará last -10 fjpisani y verá lo mismo ¿por qué puso -10, porque sólo
quiere ver las últimas 10 veces, ya que está gastando comunicación telefónica con su proveedor de Internet y no le
interesa todo, sino si anduve por allí y cuándo.
Dentro de /var también hay otros subdirectorios importantísimos. Allí suele instalarse el named (var/named) que
es donde se configura el servicio de nombres de dominios para que los mensajes se enruten correctamente, uno de
los temas espinosos que veremos más adelante. (Espinoso no por lo difícil, sin por lo difícil configurarlo para que
ande bien :-) (pero por suerte ahora es cada vez más sencillo configurar esto)
También en /var algunas distribuciones (Debian por ej) guarda el directorio donde está la página web que sirve el
servidor apache (/var/www) y lo que pongamos allí aparecerá como página web del sitio
/lost-fount
directorio donde se guardan restos de sectores perdidos, encontrados y que no se sabe qué hacer con ellos, cuando
aplicamos alguna de las herramientas tipo scandisk (cada vez que se prende y carga Linux se revisan los sistemas
de archivos buscando inconsistencias y uno de los programas semejante al scandisk se llama en Linux fsck) .
ANEXO 2
Por Fernando Pissani
Introducción al concepto de shell
Como sabemos, la computadora no hace nada sin un sistema operativo. ¿Y qué es un sistema operativo?. Difícil
pregunta porque admite muchas respuestas, incluso triviales.
Podríamos decir que es el programa (o los programas) que permite que se puedan usar los recursos de la
computadora. ¿Quién?: otros programas.
Cuando guarde este capítulo, el programa que estoy usando no sabe cómo guardar los datos en el disco rígido y
sería un arbur que cada programa se encargara por sí mismo de acceder a los dispositivos. De allí que cuando le
12
doy la orden al procesador de texto de guardar, éste le pide al sistema operativo que lo guarde. El sistema
operativo, al mismo tiempo de tener que guardar esos datos, se debe encargar de proteger los datos existentes, por
ejemplo no escribir donde están los datos de otro archivo.
Por lo tanto tenemos dos funciones bastante definidas en un sistema operativo: dar servicio y proteger (si el
sistema operativo es multiusuario deberá proteger los datos de cada usuario y actividades, por ej). Así podemos
distingir los distintos sistemas operativos por la cantidad de servicios y el nivel de protección que tienen, aparte de
la rapidez, eficiencia y eficacia que lo prestan.
Y aquí aparecen dos ideas de lo que puede ser un sistema operativo. Por un lado una idea estricta, el (o los)
programa(s) que se encarga(n) de dar en última instancia esos servicios y esa seguridad. Pero también está la idea
amplia de sistema operativo, que incluye: el programa que permite que el usuario interactúe con el sistema
operativo más un conjunto de programas que ayudan al normal funcionamiento del sistema operativo.
Evidentemente si nos referimos al concepto estricto del sistema operativo, en Linux está perfectamente
identificado en un archivo, llamado kernel o núcleo. Es propiamente el "verdadero" Linux.
Si tomamos al sistema operativo en su concepto amplio (que es generalmente como se entiende) encontraremos
que está compuesto por tres niveles perfectamente diferenciados:
* el núcleo o kernel
* el interprete de comandos o shell
* los programas vinculados con la gestión/consulta de lo que maneja el núcleo o que permiten la interacción con
él y los dispositivos que maneja en núcleo.
No es una descripción muy brillante pero nos permite identificar sus componentes. Si comparamos con el DOS en
kernel sería el io.sys y el msdos.sys (en el caso del DOS de Microsoft), el shell sería el command.com y los
programas vinculados serían el format, el fdisk, el backup, el keyb, etc (entre 150 y 200 programas)
En Linux el kernel puede tener el nombre que prefiramos (ya veremos que se lo podemos decir al LILO -Linux
Loader, cargador de Linux- en su archivo lilo.conf que está en /etc), aunque generalmente se llama vmlinuz ; y
puede estar donde querramos, aunque suele ponerse en el raiz o dentro del directorio /boot
Los programas que forman parte del sistema operativo son muchos y generalmente están en /bin y en /sbin, ya
vimos varios hasta aquí y veremos más. Claro que es difícil distinguir si tal programa forma parte del sistema
operativo o no, pero es una distinción que carece de importancia. Lo que importa saber es si tal programa lo
encontraremos normalmente en cualquier distribución o no (aunque también esto es ambiguo, porque el mc
prácticamente lo vamos a encontrar en cualquier distribución pero no tiene para el sistema operativo el mismo
papel que el fdisk.)
¿Y qué nos queda?: el shell o intérprete de comandos.
Cuando nosotros pedimos un ls o ejecutamos el fdisk, en realidad lo hacemos gracias al shell. Sin shell no
podríamos interactuar gran cosa con la computadora, si es que podríamos hacerlo.
En el shell del DOS (incluyendo el DOS de Winodows 9x, existen varios comandos que están integrados a él, es
decir, que no existen como programas .exe o .com, sino que son comandos internos al shell, caso dir, cd, md, rd,
type, cls, time, date y algunos más.
Generalmente el DOS viene con su interprete de comandos y no es común cambiarlo, aunque se puede. En el caso
de Windows 95/98 /2000 el problema se complica más si quisiéramos producir alteraciones en el intérprete de
comandos o cambiarlo por otro.
¿Y qué pasa con Unix/Linux?
En Unix el papel del shell es mucho más grande porque es mucho más potente. Si bajo DOS queremos programar
algo con el interprete de comandos, sólo tenemos a los comandos de los proceso de lotes, los conocidos
archivos .bat con las sentencias cls, echo, goto, if, rem, pause, call, for y algunas pocas más. Los shell de Unix son
otra cosa.
¿Y por qué "los shell"?. Porque en Unix disponemos de gran variedad de shell, siendo muy fácil cambiar de uno a
otro (hay una orden chsh nombre, chsh= change shell y el nombre es el nombre del shell que queremos cargar) (el
cambio se hace sólo para el usuario que da la orden de cambio).
¿Y qué es lo que hace el shell?
13
Cuando por ejemplo tenemos el cursor titilando pidiendo que le demos una orden, es el shell (o la shell, como la
llaman algunos) el que nos está preguntando y esperando, el que manejará el teclado a medida que vamos
ingresando las letras y números (o retrocediendo) y el que reconocerá el listo (enter) y dará la orden de inicio de
ejecución (si reonoce el comando como válido). Naturalmente esto variará de acuerdo al sistema operativo que
estemos hablando y es muy difícil a veces hacer una distinción a partir de qué parte se encarga el núcleo, pues el
shel en realidad es como la cara visible del sistema operativo. Éste se comunicará con nosotros generalmente a
través del shell y gracias el shell nos comunicaremos nosotros con el kernel y gracias a éste con los dispositivos
físicos.
A diferencia de otros sistemas operativos, en Unix/Linux es bien marcada la división de estas capas, lo que
permite mucha mayor flexibilidad, ya que si estuvieran entremezcladas sería muy difícil de cambiar por otra
utilidad de otro fabricante, o modificarla.
En Unix los shell más conocidos son el Bourne Shell, que fue el primero más usado de los shell, seguidos luego
por el KornShell , que es el usados en System V (una de las dos variantes principales de Unix) y el C Shell. En
Linux el más usado (y el que pone por defecto la instalación) es el bash
De nuevo aquí tenemos presente el espíritu de Unix: bash significa Bourne Again Shell. "¡de nuevo el shell
Bourne!". Claro, el shell Bourne había sido abandonado por el Korn, que se basaba en él, pero era más potente; o
por el C Shell , preferido por muchos programadores por la elasticidad de su programación y su similitud en el
díalogo con el lenguaje C. (la mayor diferencia entre el C Shell (de Berkeley) y el Korn está no tanto en las
prestaciones, sino en manera que se le dan las órdenes, en la sintaxis. En el C se parece al lenguaje C y en el Korn
se parece a Bourne. El Bourne fue creado por Steve Bourne en los laboratorios Bell de la AT&T. El C shell por
Bill Joy, el mismo autor del vi .
En Linux vienen varios shell. El bourne es el /bin/sh, el C Shell es el /dev/csh, el bash es el /dev/bash, el T Shell
/dev/tcsh que es algo más completo que el C Shell y es casi un lenguaje de programación. Si quiere cambiar de
shell sin cambiarlo por defecto, puede ejecutarlo poniendo su nombre. En el caso del csh verá pronto una
diferencia porque el tradicional símbolo $ que tiene como usuario se reemplazará por el símbolo % (aunque esto
puede cambiarse a gusto). Si desea saber qué shell está ahora usando mire adentro de una variable de entorno que
se llama $SHELL, puede verla tecleando
echo $SHELL
y allí le mostrará el shell que tiene cargado. Cada usuario puede tener su propio shell (o el root) y ello se consigue
cambiando el nombre del shell en el archivo de contraseñas o con el comando chsh, lo vamos a ver después.
Existe un archivo en /etc que se llama shells que contiene los shell permitidos por el sistema (esto es porque puede
haber otros shell pero no estar permitidos). Para ver la lista sin mirar ese archivo, puede teclear chsh -l
ANEXO 3
Por Fernando Pissani
PATH
Una de la variable más importante es el path. Como saben, el path indica la ruta de búsqueda cuando queremos
ejecutar algún programa.
Generalmente cuando Linux se instala pone a los usuarios con una variable path que contiene los subdirectorios
de los programas ejecutables a los que puede acceder el usuario.
Supongamos que tenemos este path:
/usr/bin: /usr/sbin: /bin
y tomemos el ejemplo del programita que hice recién, el majo, que lo creé en mi subdirectorio personal.
Si pretendo ejecutar majo, el shell me dirá comando no reconocido. Miraré en qué subdirectorio estoy
metido, haré un ls para ver si majo está en donde yo estoy metido y veo que efectivamente estoy justo en ese
subdirectorio, por lo que reviso si lo escribí bien, tipeo de nuevo y obtengo en mismo efecto: no lo encuentra.
En el DOS, la manera de garantizar de ejectuar un programa era meterse en su subdirectorio y desde allí
ejecutarlo. Si no lo encontraba allí, recién entonces el command.com se ponía a buscarlo por los diversos
subdirectorios escritos en el path. Y si no lo encontraba allí, daba el tradicional mensaje de comando no hallado.
14
Con Linux no funciona así. Si no está en el path, no lo encuentra . La única manera de ejecutar algo que no esté
en el path es dándole la ruta completa. Para quienes han "nacido" con MSWindows este problema generalmente
no se presenta, porque sólo aprietan íconos, y bajo el ícono en realidad está la ruta completa.
Volviendo a Unix/Linux, tenemos un comodín para poder escribir la ruta completa sin escribirla, me refiero a la
ruta completa donde estamos parado, que es el punto (un sólo .), cuestión esta que también existía en el DOS ya
que fue copiado de Unix. Por lo tanto, en el caso que venimos hablando del programita majo, para no tener que
escribir todo y suponiendo que estamos donde hemos creado nuestro programa, escribiremos ./majo, donde el .
significa el subdirectorio actual.
Por eso puede ser conveniente poner al final del path que ya viene el punto . como un directorio más de búsqueda,
para que se ejecute cualquier programa que llamemos dentro del subdirectorios que estamos "parado". Y digo
puede ser conveniente, pero puede que no . Dependerá de otras consideraciones. Vayamos a ellas.
El path tiene mucha importancia por cuestiones de seguridad. Saben que en Linux prácticamente no existen virus,
casi no pueden existir porque los programas no pueden acceder directamente a la cpu, a las interrupciones y a la
memoria, deben pasar primero por el núcleo, y obvio, no se puede acceder al núcleo así como así (sólo andaría un
virus que dañase al sistema si estuviéramos como root, por eso es aconsejable no trabajar como root a menos que
sea imprescindible).
No hay casi virus, pero sí varios troyanos, es decir, programas que se supone hacen una cosa pero hacen otras.
Pongamos el caso que creo un programa que borre todo, lo llamo ls y ya se imaginan qué puede pasar si se ejecuta
ese troyano llamado ls
¿Pero cómo hacer que el usuario inadvertido, al ejecutar ls no ejecute el verdadero ls sino el troyano?
En el path hay un orden de ejecución. Si miran la variable path estando de usuario común, verán que es distinta a
la variable path estando de root (pueden mirarla con echo $PATH )
Si como root tengo el orden de ejecución /bin: /sbin, /usr/bin, etc es evidente que la orden ls que ejecutaré será la
que está en /bin, y allí un intruso sin privilegio de superusuario no puede cambiar ese programa.
Pero supongamos por un momento que tenemos un intruso que consiguió la clave de un usuario común, pepe, por
lo que puede escribir en el subdirectorio de pepe y bajar allí su troyano. ¿Qué pasaría si dicho intruso pudiera
modificar la variable de ambiente path del root (o de pepe) y pusiera /home/pepe: /bin: /sbin etc?
Obvio que cuando el root escribiera ls se leería primero el troyano, produciendo el daño que se imagina.
Conclusión, la variable path es muy importante para la seguridad. (O si lo ejecutara pepe, aunque no podría borrar
todos los datos de la computadora, al menos borraría sus propias cosas, lo que igual es no deseable)
Esto nos lleva también a otras consideraciones. Tenemos que trabajar con un cierto orden. Si yo hubiera hecho ese
programita majo y lo hubiera dejado en /home/fjpisani, realmente sería un "sucio", pues estoy haciendo las cosas
sin criterio, y el Unix/Linux las cosas hay que hacerlas bien, con criterio. Al respecto lo más apropiado es guardar
los programas que hacemos en un subdirectorio:
/usr/local/bin o /usr/local/sbin (o en todo caso, como veremos luego, en /home/fjpisani/bin)
En algunas distribuciones aquel subdirectorio se crea sólo, si no ocurre así, es conveniente crearlo y luego agregar
en el path ese subdirectorio, al principio si queremos que tengan preponderancia nuestros programas, o al final.
Otra posibilidad, si en el sistema concurren muchas personas y no queremos arriesgarnos a que pueda pasar algo
extraño con las cosas que se ponen en /usr/local/, es hacer que cada uno dentro de su propio subdirectorio cree un
subdirectorio que se llame bin (/home/fjpisani/bin), claro que aquí se nos puede complicar un poco la cosa ¿cómo
hacemos para que cuando se dé de alta un usuario en el path se agrege ese directorio, que depende de su nombre?
Decimos esto porque cuando queremos que se automaticen las cosas, como lo hace Linux y que no tengamos que
escribir el path de cada uno, directamente damos la orden general en el archivo profile que está en /etc y allí
ponemos por ej:
path /usr/local/bin, /usr/bin ... ¿pero cómo ponemos el subdirectorio bin que se ha creado o se puede crear en el
subdirectorio de cada usuario?
Aquí viene en nuestra ayuda otra variable de ambiente $HOME
15
La variable $HOME tiene nuestro directorio home
Si ingresamos como sherlock y tecleamos
echo $HOME
nos devolverá
/home/sherlock
Si ingresamos como root y tecleamos
echo $HOME
nos devolverá
/root
Por lo tanto podemos agregar al path el subdirectorio de cada uno sin problemas escribiendo
/$HOME/bin (recuerden que se separan con dos puntos, no con punto y coma como en el DOS)
Si transitoriamente queremos probar esto y agregar algún sudirectorio al path desde el prompt tenemos dos
alternativas: teclear todo el path anterior y agregarle le nuevo o directramente escribir:
PATH=$PATH: $HOME/bin
Con esto lo que estamos haciendo es redefinir la variable PATH y guardar en ella el path viejo ($PATH) más el
que le agregamos ahora, si estamos como sherlock se le agregaría /home/sherlock/bin
Con esto terminamos de ver otra cosa: para darle un valor a una variable de entorno hay que escribirla,
poner el signo igual y agregarle el valor.
Otra variable útil de saber, especialmente cuando nos estamos conectando por teléfono y queremo hacer un telnet
para trabajar en modo terminal, es la variable TERM, que define que tipo de terminal estamos trabajando. Si
tenemos problemas con el movimiento de los renglones, o vemos muy mal la salida, es probable que tengamos
mal definida la terminal. Tiene que coincidir la emulación de terminal que tiene definida el programa que estamos
usando y la que tiene definida Linux.
Muchas veces resuelvo el problema tecleando
TERM=vt100
vt100 es una muy vieja terminal, que hace mucho que no existe más, pero que se sigue usando como referencia
para definir el comportamiento de una terminal. También podemos probar con
TERM=linux
¿Y qué otras variables de ambiente hay?
Teclemos
env
y veremos la lista de variables.
Por supuesto que nada de esto es necesario saber para usar Linux. Pero al menos tener una idea de ello saca "lo
mágico" del funcionamiento y nos permite tener una visión del funcionamiento general y permitir encarar
problemas más complejos.
Estas variables son muy útiles para los programas, que con frecuencia recurren a ellas.
Por ej cuando ejecutamos un procesador de texto en DOS/Windows, este guarda sus archivos en un subdirectorio
predefinido en algún lado (opciones, preferencias, etc)
Supongamos que como política de administración hacemos que cada uno guarde sus cosas en sus subdirectorios,
por ej dentro de un subdirectorio que se llame documentos
Si le decimos que guarde las cosas en $HOME/documentos, el programa las guardará según quién lo esté usando
en cada subdirectorio propio, ya que reemplazará la variable por el nombre real.
Otra de las variables de ambientes importante es la que define el shell por defecto que puede usar ese usuario. Esta
variable toma los datos del archivo /etc/passwd, que muestra en uno de sus campos cuál es el shell que le
corresponde a cada usuario.