slackware.bg

guide12

Capítulo 12

Errores, equivocaciones, bugs, y otras molestias

Unix nunca fue diseñado para evitar que la gente hiciera cosas estúpidas, porque esa política les habría evitado también hacer cosas inteligentes.

Doug Gwyn

12.1 Evitando errores

Muchos usuarios hablan de su frustración con el sistema operativo Unix en alguna ocasión, a menudo a causa de lo que ellos mismos han hecho. Una característica del sistema operativo Unix que muchos usuarios adoran cuando están trabajando bien, y odian después de una sesión hasta bien avanzada la noche, es que muy pocas órdenes piden confirmación. Cuando un usuario está despierto y funcionando, raramente piensa sobre ello, y esto es una ventaja, ya que le permite trabajar más eficientemente.

De todos modos, hay algunas desventajas. rm y mv no piden nunca confirmación, y esto conduce frecuentemente a problemas. Por eso, veamos una pequeña lista que puede ayudarle a evitar el desastre total:

o �Tenga copias de seguridad! Esto va dirigido especialmente a sistemas de un solo usuario, �todos los administradores de sistema deben realizar copias de seguridad de su sistema regularmente! Una vez a la semana es suficiente para salvar muchos ficheros. Para más información consulte The Linux System Administrator's Guide.

o Los usuarios individuales deben tener sus propias copias de seguridad, si es posible. Si usa más de una máquina regularmente, intente mantener copias actualizadas de todos sus ficheros en cada una de las máquinas. Si tiene acceso a una unidad de disquetes, puede hacer copias de seguridad en disquetes de su material crítico. En el peor de los casos, mantenga copias adicionales del material más importante que haya en su cuenta en un directorio separado.

o Piense sobre las órdenes, especialmente las "destructivas" como mv, rm, y cp antes de actuar. Debe ser también cuidadoso con las redirecciones (>), sobreescribirán sus ficheros cuando no esté prestando atención. Incluso el más inofensivo de los comandos puede convertirse en siniestro:

/home/larry/report$ cp report-1992 report-1993 backups

puede convertirse fácilmente en desastre:

/home/larry/report$ cp report-1992 report-1993

o El autor también recomienda, a partir de su propia experiencia personal, no hacer limpieza de ficheros a altas horas de la madrugada. �Que su estructura de directorios parece un poco desordenada a la 1:32am? Déjelo estar, un poco de desorden nunca ha dañado un ordenador.

o Sígale la pista a su directorio actual. A veces, el prompt que está usando no muestra en que directorio está usted trabajando, y el peligro acecha. �Es triste leer un mensaje en comp.unix.admin1 sobre un usuario root que estaba en / en vez de en /tmp! Por ejemplo:

mousehouse> pwd

/etc

mousehouse> ls /tmp

passwd

mousehouse> rm passwd

La anterior serie de comandos podría hacer muy infeliz al usuario, al ver como eliminaron el fichero de contraseñas de su sistema. �Sin él la gente no puede acceder!

12.2 Qué hacer cuando algo va mal

12.3 No es fallo tuyo

Por desgracia para los programadores del mundo, no todos los problemas son a causa de errores del usuario. Unix y Linux son sistemas complicados, y todas las versiones conocidas tienen errores de programación (bugs2). Algunas veces esos errores son difíciles de encontrar y sólo aparecen bajo ciertas circunstancias.

Ante todo, �qué es un error? Un ejemplo de error es si le pide al ordenador que calcule "5+3" y contesta "7". Aunque este es un ejemplo trivial de que puede ir mal, la mayoría de los errores en programas de computadoras se relacionan con la aritmética en alguna forma extremadamente extraña.

_____________________________________________

1 Un foro de discusión internacional en Usenet, que trata sobre la administración de computadoras Unix.

2 Bug: (polilla, fam. bicho). Se denomina así a los errores que aparecen en un programa. Cuenta la leyenda que cuando los ordenadores eran unos monstruos llenos de válvulas, que ocupaban habitaciones enteras, un técnico que trataba de resolver un error en el Mark II de Harvard detectó que la causa era una polilla de verdad que se había colado entre las válvulas y provocaba pequeños cortocircuitos al revolotear de un lado a otro.

12.3.1 Cuando hay un error

Si la computadora da una respuesta errónea (�compruebe que la respuesta es errónea!) o se bloquea, eso es un error. Si cualquier programa se bloquea o da un mensaje de error del sistema operativo, eso es un error.

Si un comando no finaliza nunca su ejecución, puede ser un error, pero debe asegurarse de que no le ha pedido que esté durante mucho tiempo haciendo lo que usted quería que hiciera. Pida ayuda si no sabe lo que hacía el comando.

Algunos mensajes le alertarán de la existencia de errores. Algunos mensajes no son errores. Revise la sección 3.4 y el resto de la documentación para estar seguro de que no son mensajes informativos normales. Por ejemplo, mensajes como "disk full" (disco lleno) o "lp0 on fire" (lp0 ardiendo) no son problemas de software, sino algo incorrecto en su hardware, no hay suficiente espacio libre en el disco, o la impresora está mal.

Si no puede encontrar información sobre un programa, es un error en la documentación, y debería ponerse en contacto con el autor de dicho programa y ofrecerse para escribirla usted mismo. Si algo está incorrecto en la documentación existente3, es un error en ese manual. Si algo aparece incompleto o poco claro en el manual, eso es un error.

Si no puede vencer al gnuchess al ajedrez, es un fallo de diseño en el algoritmo de ajedrez que usted usa, pero no necesariamente un error en su cerebro.

12.3.2 Notificando un error

Cuando esté seguro de haber encontrado un error, es importante asegurarse de que su información llega al lugar adecuado. Intente encontrar que programa causa el error, si no puede encontrarlo, tal vez pueda pedir ayuda en comp.os.linux.help o comp.unix.misc. Una vez encuentre el programa, intente leer la página del manual para ver quien lo escribió.

El método preferido para enviar notificaciones de errores en el mundo Linux es vía correo electrónico. Si no tiene acceso al correo electrónico puede ponerse en contacto con la persona que le suministró Linux, eventualmente, encontrará alguien que o bien tiene correo electrónico, o vende Linux comercialmente y por tanto quiere eliminar el mayor número de errores posibles. Recuerde, en todo caso que nadie está obligado a corregir ningún error a menos que tenga un contrato.

Cuando envíe una notificación de error, incluya toda la información que se le ocurra. Esto incluye:

o Una descripción de lo que usted piensa que es incorrecto. Por ejemplo, "Obtengo 5 cuando calculo 2+2" o "Dice segmentation violation -- core dumped". Es importante decir exactamente que esté sucediendo para que el responsable del mantenimiento pueda corregir su error.

o Incluya cualquier variable de entorno relevante.

o La versión de su núcleo (mire en el fichero /proc/version) y sus bibliotecas de sistema (mire en el directorio /lib, si no puede descifrarlo, envíe un listado de /lib).

o �Cómo ejecutó el programa en cuestión?, o, si era un error del núcleo, �qué estaba haciendo en ese momento?.

o Toda la información complementaria. Por ejemplo, el comando w puede no mostrar el proceso actual para ciertos usuarios. No diga simplemente, "w no funciona para cierto usuario". El error podría ocurrir debido a que el nombre del usuario tiene ocho caracteres de longitud, o cuando está accediendo a través de la red. En su lugar diga, "w no muestra el proceso actual para el usuario greenfie cuando accede a través de la red".

o Y recuerde, sea amable. La mayoría de la gente trabaja en el software libre por el gusto de hacerlo, y porque tienen un gran corazón. No los amargue, la comunidad Linux ha desilusionado ya a demasiados desarrolladores, y aún es pronto en la vida del Linux.

_____________________________________________

3 �Especialmente en ésta!