Foro - Perl en Español

¡Buenas!
El problema que tengo es que al ejecutar desde el cliente un cgi me sale esto en el error.log de apache:



He observado que en un servidor con Apache2 se 'traga' el error anterior y hace lo que debe, y en cambio en otro servidor con Monkey HTTP Daemon el servidor hace cosas raras (no escribe a fichero cuando debe) a pesar de no sacar nada en el fichero de log.

Paso a pegar el código (me centraré en las líneas alrededor del error que indica el log):




Sé que es difícil así con tan poco código, pero tengo un monstruo de 600 líneas y el error debería estar por ahí cerca.

¡Si me podéis ayudar os estaré agradecido!

Buenas.

No estoy muy seguro, y quizás no debería responder.
Pero creo que es un error de cadena



Creo que sería :



No entiendo bien por qué pusiste "<<", sé que hay modificadores para la salida de los valores de las variables, pero ese aún no lo vi.

Saludos

Cambia las " de FIN por ', en el caso de que en ese trozo de código HTML NO existan variables Perl que quieras que sean interpoladas.

Así:

ubuntu escribiste:No entiendo bien por qué pusiste "<<", sé que hay modificadores para la salida de los valores de las variables, pero ese aún no lo vi.

Ubuntu, adrolmar está usando un "here-document" (busca por la subsección <<EOF).

explorer escribiste:Cambia las " de FIN por ', en el caso de que en ese trozo de código HTML NO existan variables Perl que quieras que sean interpoladas.

Así:

Sintáxis: [ Descargar ] [ Ocultar ]

Sintáxis: [ Descargar ] [ Mostrar ]

Using perl Syntax Highlighting

print <<'FIN';

Coloreado en 0.001 segundos, usando GeSHi 1.0.8.4

Buenas, el caso es que sí, más abajo, incluye en el código HTML un campo llamado $html que contiene objetos HTML dinámicos (creo tantos textboxes como cadenas que cumplen cierto patrón encuentro en un fichero). De todas maneras mañana pruebo a cambiar comillas dobles por simples. La verdad que ando algo desesperado porque no tengo ni idea de qué puede ser y tampoco si realmente influye en el comportamiento anómalo cuando corre bajo monkey http daemon. Por si fuera de utilidad, también decir que en la máquina que falla tengo una versión de Perl 5.4 mientras que en la máquina del Apache2 la versión 5.8. Quizá la 5.8 pase por alto dicho error y la 5.4 no.

¡Gracias nuevamente!

Si tienes variables que quieres interpolar dentro del here-doc, entonces NO pongas comillas simples. Deben ser dobles o sin comillas.

Entonces, el error que sale te indica que alguna de esas variables que están interpolando dentro del here-doc están sin inicializar.

Ese mensaje sale por tener activo el sistema de warnings, bien sea por haber puesto el use warnings; o por poner el -W en la primera línea (la del shebang).

Y, sí, la versión de Perl también influye. Con los años, las versiones de Perl dan mucha más información de avisos y errores, para evitar errores mayores.

Eso significa que hay un error de lógica en tu programa, a la hora de rellenar esas variables.

¡¡Buenas!!

Gracias en primer lugar por responder.

En segundo lugar... sí, exacto, tengo unos textboxes rellenos con valores de un hash que actualizo al empezar el CGI con datos de un fichero. En caso de que el fichero a cargar esté vacío o no exista, el CGI lo que hace es mostrar un formulario "por defecto" sin valores (¡¡como hacía lo que tenía que hacer me olvide por completo de inicializar el hash!!). El caso es que no son muchos campos a inicializar, como unos 17, pero no se me ocurre ni he encontrado una manera eficiente de inicializar todos los campos del hash a algún valor por defecto, a no ser que la única manera seguramente sea declarar la estructura al principio del programa y rellenar los campos con un bucle y haciendo uso de la función keys(%hash).

Podría hacerlo con valores explicativos del tipo de dato permitido en cada textbox: "solo nombres de usuario sin 'ñ', acentos o espacios", o algo así.

Voy a probar de nuevo, muchísimas gracias ubuntu, explorer.

EDITO:

Buenas de nuevo...
Probé a inicializar el hash... y ahora no saca ningún warning ni nada

Pero lo que no entiendo es lo que me he dado cuenta que pasa con el servidor de monkey...

Mi CGI está programado para que al entrar lea de un fichero, cargue datos y los muestre en un formulario. Cuando se modifica algún campo se guarda de nuevo sobreescribiendo el mismo fichero.

Pues bien, con el servidor Apache2 todo va de perlas, pero con el de Monkey no sobreescribe a pesar de no sacar ningún error ni en el navegador ni en el fichero log de errores. En cambio, si cambio la ruta, de manera que lea del fichero original pero guarde cambios en otro fichero distinto... ¡todo va bien! (¿?)

¿¿Alguien le ha pasado alguna cosa parecida antes??

NOTA: me instalé tanto el servidor Apache como el Monkey en la misma máquina virtual con Perl v5.8, para así tener la misma versión para ambos. El problema aun así persiste.

¡Gracias de antemano!

Saludos

Yo tenía esos problemas con los permisos de los ficheros.

Hay que tener en cuenta que el programa servidor web, bien sea Apache o Monkey, se ejecuta bajo un usuario del sistema. Lo puedes ver si haces un ps o un top. Bueno, pues según quien sea ese usuario, y a qué grupo de usuarios pertenezca, podrá entrar o no en ciertos directorios, además de poder modificar los ficheros que haya dentro.

Un ejemplo.

En mis máquinas, el servidor web es Apache y se ejecuta bajo el usuario www-data, que pertenece a un grupo del mismo nombre.

Si quiero que acceda a las páginas web de un directorio cualquiera, debo elegir una de estas opciones:
1.- el directorio tiene permisos de acceso a todo el mundo, por lo que el Apache puede entrar y ver el contenido:
Fíjate que la carpeta, cuyo propietario es cooptransfp, del grupo users, permite el acceso a su interior a todo el mundo (el r-x de la derecha de la primera columna de la línea).
Además, los ficheros dentro de este directorio también tienen permiso de acceso a todo el mundo:
Como el archivo tiene permiso de lectura para todos (última 'r' de la primera columna), entonces el servidor web la puede leer y sacar fuera.

2.- el directorio tiene permiso de acceso (y escritura) para el grupo al que pertenece el servidor web:

Eso significa que el servidor web, como pertenece al mismo grupo, puede hacer lo indicado en la segunda tripleta de la primera columna. En el ejemplo (rwx), puede entrar, ver sus contenidos y modificarlos o crear nuevos ficheros.

3.- tanto el directorio como los ficheros son propiedad del usuario web.

El servidor web tiene dominio completo sobre todo lo que pasé ahí. El problema es que entonces le será difícil de manejar al usuario humano, si quiere modificar los ficheros por FTP, por ejemplo.

4.- el directorio tiene permiso de acceso y escritura para todos. Esto no es nada aconsejable, porque eso quiere decir que cualquier usuario del sistema puede modificar y/o borrar tus archivos.

En el caso de Perl, con el manejo de ficheros siempre uso die():


Fíjate que pongo la variable especial $!, que guarda el mensaje de error del sistema, que provocó el fallo del open(). Si ocurre alguna incidencia, estas líneas saldrán en el fichero de log de errores de actividad del servidor. Y si uso el módulo CGI::Carp así: use CGI::Carp qw(fatalsToBrowser); entonces saldrán en la página web directamente (ver un ejemplo en mi CGI mínimo).

¡Buenas!

explorer, intenté hacer lo que me indicaste con los permisos... pero el servidor Monkey crea los ficheros como usuario "nobody" y grupo "nogroup" :s

Últimamente ya ni me abre los ficheros y como esta operación de lectura de fichero es la que precede a mostrar el formulario... tampoco me lo muestra y ni saca error por el navegador (puse lo de CGI::Carp...), ni en el fichero de error.log (también puse lo de open (FICH, "$ruta") or die "ERROR: No pude abrir el fichero: $!\n";).

¿Existe la manera de crear ficheros con una máscara determinada desde Perl, o es necesario hacerlo mediante comandos de terminal desde system() o `` ?

¡Es una locura!

Gracias nuevamente.

Tu puedes cambiar la personalidad del Monkey, cambiándoselo en el fichero /etc/passwd y /etc/groups.

Con umask() puedes indicar los permisos que usará el proceso actual. También existe como comando en el sistema.