viernes, 3 de febrero de 2017

Mantener los scripts ejecutándose

Mientras que desarrollamos nuestro programa, es útil mantener el programa en estado ejecutable. Haciendo esto, y probándolo frecuentemente, podemos detectar errores pronto en el proceso de desarrollo. Esto hará que los problemas de depuración sean mucho más fáciles. Por ejemplo, si ejecutamos el programa, hacemos un pequeño cambio, luego ejecutamos el programa nuevamente y encontramos un problema, es muy probable que el cambio más reciente sea el origen del problema. Añadiendo las funciones vacías, llamadas stubs en la jerga de los programadores, podemos verificar el flujo lógico de nuestro programa en una fase temprana. Cuando construimos un stub, es una buena idea incluir algo que proporcione retroalimentación al programador, que muestre que el flujo lógico se está realizando. Si miramos la salida de nuestro script ahora:

[me@linuxbox ~]$ sys_info_page
<HTML>
   <HEAD>
       <TITLE>System Information Report For twin2</TITLE>
   </HEAD>
   <BODY>
       <H1>System Information Report For linuxbox</H1>
       <P>Generated 03/19/2009 04:02:10 PM EDT, by me</P>



   </BODY>
</HTML>

vemos que hay algunas líneas en blanco en nuestra salida tras la marca de tiempo, pero no podemos estar seguros de cual es la causa. Si cambiamos las funciones para incluir algo de retroalimentación:

report_uptime () {
        echo "Function report_uptime executed."
        return
}

report_disk_space () {
        echo "Function report_disk_space executed."
        return
}

report_home_space () {
        echo "Function report_home_space executed."
        return
}

y ejecutamos el script de nuevo:

[me@linuxbox ~]$ sys_info_page
<HTML>
   <HEAD>
      <TITLE>System Information Report For linuxbox</TITLE>
   </HEAD>
   <BODY>
      <H1>System Information Report For linuxbox</H1>
      <P>Generated 03/20/2009 05:17:26 AM EDT, by me</P>
      Function report_uptime executed.
      Function report_disk_space executed.
      Function report_home_space executed.
   </BODY>
</HTML>

ahora vemos, de hecho, que nuestras tres funciones se están ejecutando.

Con nuestra estrucutra de funciones en su sitio y funcionando, es hora de desarrollar el código de nuestras funciones. Primero, la función report_uptime:

report_uptime () {
     cat <<- _EOF_
          <H2>System Uptime</H2>
          <PRE>$(uptime)</PRE>
          _EOF_
     return
}

Es bastante sencilla. Usamos un documento-aquí para mostrar un encabezado de sección y la salida del comando uptime, rodeándolo de etiquetas <PRE> para preservar el formato del comando. La función report_disk_space es similar:

report_disk_space () {
     cat <<- _EOF_
          <H2>Disk Space Utilization</H2>
          <PRE>$(df -h)</PRE>
          _EOF_
     return
}

Esta función usa el comando df -h para determinar la cantidad de espacio en disco. Finalmente, construiremos la función report_home_space:

report_home_space () {
     cat <<- _EOF_
          <H2>Home Space Utilization</H2>
          <PRE>$(du -sh /home/*)</PRE>
          _EOF_
     return
}

Usamos el comando du con las opciones -sh para realizar esta tarea. Esto, sin embargo, no es una solución completa al problema. Aunque funcionará en algunos sitemas (Ubuntu, por ejemplo), no funcionará en otros. La razón es que muchos sistemas establecen los permisos de los directorios home para prevenir que sean legibles por todo el mundo, lo que es una medida de seguridad razonable. En estos sistemas, la función report_home_space, tal como está escrita, sólo funcionará si nuestro script se ejecuta con privilegios de superusuario. Un solución mejor sería hacer que el script ajuste su comportamiento según los privilegios del usuario. Lo veremos en el próximo capítulo.

No hay comentarios:

Publicar un comentario