Foro - Perl en Español

Le explico lo que quiero hacer... La verdad le he dado vuelta a la cabeza con lo poco que sé de Perl y no lo he podido lograr. Me preguntaran que por qué no lo hago con shell y la respuesta es que no sé programar en shell.

Mi caso es el siguiente: en crontab tengo una entrada como esta:

Éste se ejecuta a cada minuto.

El contenido de "reinicia_squid.sh" es el siguiente:


Y por último, mi código en Perl "reinicia_squid.pl":


La cuestión es que no reinicia la configuración squid... He intentado y nada. ¿Qué estoy haciendo mal? ¿Es necesario que lo haga en bash?

No es obligatorio hacerlo en shell. Para el sistema, será un proceso más, y le dará igual si lo tiene que ejecutar en bash o en perl.

Hay varios errores y detalles que tienes que cambiar.

Lo primero: no es necesario hacer un programa bash que contenga una sola línea y que llame al código Perl. Te vale con llamar directamente al código Perl. Cambia la entrada del crontab:
Eso sí, reinicia_squid.pl debe tener los permisos de ejecución necesarios (ponerlos con el comando chmod a 755 o 750 o 0700, según quién sea el propietario del programa). O poner 'perl' delante:


Luego, en el programa hay una serie de cambios que hay que hacer.
* Línea 11. ¿Seguro que hay que iniciar el servicio squid cada minuto?

* Línea 25. El operador '!=' es para hacer comparaciones numéricas. $lectura_new sí que es un número, ya que contiene el tamaño del fichero l_publica, pero, $lectura_ant no contiene el tamaño del fichero, sino el contenido del fichero lectura_anterior.txt. Si lo que contiene es un número, entonces sí que funcionará la línea 25. En ese caso, la lectura la puedes simplificar, pasando las líneas 15 a 20 así:
Eso sí: debemos estar seguros que debe existir el fichero lectura_anterior.txt y que debe contener un número. Si no, el programa terminará en la línea 15, por no poder abrirlo.

Recuerda que quien ejecuta el programa suele ser el usuario root, ya que es él el que ejecutó el dæmon cron:
así que según eso, deberás dar permisos de ejecución a reinicia_squid.pl. Con 755 todo el mundo lo podrá ejecutar, así que es la opción más segura. O poner como propietario del programa a root.

Muchas gracias por tu respuesta. Me sirvió de mucho. Mejoré el código. Pero igual no ejecutaba system (squid -k reconfigure);

Pero el error era que tenía que colocar la dirección completa para que lo pudiera ejecutar: system (/usr/sbin/squid -k reconfigure);

No soy partidario de reinventar la rueda, aunque no está mal tener una solución en Perl lo propio es tirar de bash aquí. Bastaría con dejar el siguiente script al alcance de crontab:

pvaldes escribiste:lo propio es tirar de bash aquí

¿Por qué razón? (tengo curiosidad)

Cuando usas system() estás haciendo una llamada a bash desde perl, y luego bash ejecuta el comando. El script de Perl de fjmn2001 tiene dos llamadas a bash, de hecho. Debería ser más eficiente utilizar un sólo programa para todo, especialmente en algo que va a lanzarse cada minuto.

Usar Perl tendría sentido si la comparación con Perl fuera mucho más rápida que con diff y por ahí ganaramos algo de eficacia (supongamos que hubiera que comparar dos archivos muy grandes y pesados). Si no, no veo ventajas añadidas en abrir un proceso cuya principal misión es llamar a dos terminales para correr sendos procesos de terminal y luego tener que volver a recuperar la salida de dichos terminales para hacer algo.

De todos modos no conozco en profundidad los entresijos de squid pero no me sorprendería que ya hubiera solucionado eso con una opción. Algo similar al comando watchdog que ya estuviera implementado para squid.

Ten en cuenta que en tu versión en bash estás ejecutando dos programas externos: diff y cp. El ejecutar programas externos es costoso, para el sistema operativo

De todas maneras, este ejemplo no nos vale para el caso de decidir si es mejor un lenguaje que otro: es tan pequeño que las diferencias son muy pequeñas.

Si sumamos lo que ocupan en recursos, los comandos bash, diff y cp, son comparables a la de solo el intérprete perl (sumando además el tiempo de carga de esos dos comandos externos). Otro tema sería medir la memoria ocupada y el tiempo de ejecución. Pero... lo dicho: la tarea es tan pequeña que no merece la pena.