%***********************************************************************
%
%       Spanish Translation by:  Enrique Zanardi,
%                                ezanardi@molec1.dfis.ull.es
%
%       Revisado (cballard)      Jun 19, 1997
%
%***********************************************************************
\chapter{Errores, equivocaciones, bugs, y otras molestias}\label{error-chapter}

\begin{quote}
  \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.\\ \raggedleft Doug Gwyn
\end{quote}

\section{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. \cmdnm{rm} y \cmdnm{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:

\begin{itemize}
\item ¡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 \ldpsa.
\item 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 {\em en un directorio
    separado}.
\item Piense sobre las órdenes, especialmente las ``destructivas''
  como \cmdnm{mv}, \cmdnm{rm}, y \cmdnm{cp} antes de actuar.  Debe ser
  también cuidadoso con las redirecciones ({\tt >}) ---sobreescribirán
  sus ficheros cuando no esté prestando atención.  Incluso el más
  inofensivo de los comandos puede convertirse en siniestro:
\begin{screen}\begin{verbatim}
/home/larry/report$ cp report-1992 report-1993 backups
\end{verbatim}\end{screen}
% $ para equilibrar al font-lock-mode de emacs
puede convertirse fácilmente en desastre:
\begin{screen}\begin{verbatim}
/home/larry/report$ cp report-1992 report-1993
\end{verbatim}\end{screen}
% $ para equilibrar el font-lock-mode de emacs
  \item 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.
  \item 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
    {\tt comp.unix.admin}\footnote{Un foro de discusión internacional
      en Usenet, que trata sobre la administración de computadoras
      \unix.}  sobre un usuario {\tt root} que estaba en \file{/} en
    vez de en \file{ /tmp}! Por ejemplo:
\begin{screen}\begin{verbatim}
mousehouse> pwd
/etc
mousehouse> ls /tmp
passwd
mousehouse> rm passwd
\end{verbatim}\end{screen}
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!
\end{itemize}

\section{Qué hacer cuando algo va mal}


\section{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 (bugs\footnote{Bug: (polilla, {\em 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.}).  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.

\subsection{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~\ref{kernel-messages} 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 existente\footnote{¡Especialmente en
  ésta!}, 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 \cmdnm{gnuchess}\ttindex{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.

\subsection{Notificando un error}\label{error-reporting}

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 {\tt comp.os.linux.help} o {\tt
  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:
\begin{itemize}
\item Una descripción de lo que usted piensa que es incorrecto.  Por
  ejemplo, ``Obtengo 5 cuando calculo 2+2'' o ``Dice {\tt segmentation
    violation -- core dumped}''.  Es importante decir exactamente que
  esté sucediendo para que el responsable del mantenimiento pueda
  corregir {\em su\/} error.
\item Incluya cualquier variable de entorno relevante.
\item La versión de su núcleo (mire en el fichero {\tt /proc/version})
  y sus bibliotecas de sistema (mire en el directorio \file{/lib}---si
  no puede descifrarlo, envíe un listado de \file{/lib}).
\item ¿Cómo ejecutó el programa en cuestión?, o, si era un error del
  núcleo, ¿qué estaba haciendo en ese momento?.
\item {\bf Toda} la información complementaria.  Por ejemplo, el
  comando \cmdnm{w}\ttindex{w} puede no mostrar el proceso actual para
  ciertos usuarios.  No diga simplemente, ``{\tt 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, ``{\tt w} no
  muestra el proceso actual para el usuario {\tt greenfie} cuando
  accede a través de la red''.
\item 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.
\end{itemize}

% Local Variables: 
% mode: latex
% TeX-master: "guide"
% End:
