🚀 go-pugleaf

El dj 02 de 02 del 2006 a les 06:57 +0000, en/na David Serrano
(Hue-Bond) va escriure: 
> AnimAlf, mié20060201@22:17:25(CET):
> >
> > estoy escribiendo unos script es perl en una máquina Linux 2.6.14.3
> > con
> > la versión 5.008007 de Perl, estos scripts luego los cuelgo en una
> > Solaris 5.8 con la versión de perl 5.00503 en la que accedo vía ftp.
> 
> Ugh. 5.5 ya tiene tiempo...
> 

:))

> > utilizo los switches -T y -w
> > #/usr/bin/perl -Tw
> 
> Como ya te han dicho, 'use warnings' es mejor que '-w';
> 
> 
> > ¿puedo hacer algo con mi perl para que sea más esctricto?
> 
> Por supuesto, 'use strict'.
> 

Siempre forman parte de la cabecera O:) ya es que ni me planteo no
ponerlo.

> De todas formas, esa no es la solución a tu problema en este caso. El
> problema es que la sintaxis del operador mkdir cambió entre una versión y
> otra (o eso parece). Creo que no te queda otro remedio que empollarte los
> perldelta* relevantes y enterarte de lo que es distinto. Seguro que perlport
> también te da consejos interesantes.

Ya me estoy poniendo con ello. Uff, tienes razón. Hay muchos perldelta*
de por medio. ... je je je [jolín he empezado a leer este mail a las 9 y
son ya casi las dos] y tengo mi solución, abajo la presento :))

> Otra cosa que debes hacer siempre siempre siempre, es comprobar el valor de
> retorno de las llamadas al sistema. En este caso era un error de compilación
> así que tampoco te serviría pero, ¿qué pasaría si el mkdir se ejecutara bien
> en ambos sitios y luego fallase un posterior open?
> 
> mkdir 'dir', 0750            or die "mkdir: $!";
> open my $fd, '>', 'dir/file' or die "open: $!";
> 

utilizo los modos -X antes de cualquier operación con archivos, y veo
que también son aplicables a directorios. Así se verá el error. Pero me
mata cuando veo el mensaje de error del servidor sin que pueda acceder
realmente a lo que ocurrio.

> > debo quizás recompilarlo con alguna opción especial para poder tener los
> > errores de este tipo localmente.
> 
> Si quieres ver los errores en el navegata, me temo que debes redirigir
> stderr a stdout en el momento en que se llama al script.

Eso sería ideal. ¿no pone pegas el servidor?

>  Quizá también se
> puede hacer desde el propio programa, dentro de un bloque BEGIN, pero ahora
> mismo me tengo que marchar a la ofi pitando y no me acuerdo exactamente de
> lo que hay que poner en el segundo parámetro de open.
> 

Que tengas un buen día.

voy a ver si consigo redirigir la salida de error.

---------------------
he hecho lo siguiente
---------------------
#!/usr/bin/perl -w
# visor.cgi
use CGI qw(:standard);
use IPC::Open3;
my @args;
print header();
print "<html><head><title>VisorRemoto</title></head><body>\n";
$script=param("f");
die "No hay nada que probar" unless (-x $script);

local(*PARA_ENTRARLE, *LASALIDASTD, *LASALIDAERROR);

$procesohijo = open3(*PARA_ENTRARLE, *LASALIDASTD, *LASALIDAERROR,
$script, @args);
@salidaStr = <LASALIDASTD>;    # Leer la salida standar.
@salidaErr = <LASALIDAERROR>;    # Leer si aparece algún error
print "<h2>La Salida Standar:</h2><br>:\n", @salidaStr, "\n";
print "<h2>La Salida de Errores:</h2><br>\n", @salidaErr, "\n";
close LASALIDASTD;
close LASALIDAERROR;
waitpid($procesohijo, 0);
if ($?) {
    print "No lo he dejado zombie por ahí.Terminó con: $?\n";
}
print"</body></html>";
--------------------------
para llamarlo con 
http://domain/cgi-bin/visor.cgi?f=./archivo.cgi
y por fin veo los errores. Si ocurren.
Gracias por las referencias

Atentamente
-- 
AnimAlf AnimAlf@engendro.sytes.net 
http://www.fut.es/~acl/AnimAlf 
Personal Experimental WebServer: http://www.engendro.sytes.net 
LiNUX ReGiSteRED UseR #91326 
PublicPGPkeyID 0xB3B41215 
Is the truth out there? 

Coalición europea contra el correo comercial no solicitado: 
http://www.euro.cauce.org/es