sistema linea ejecutar comandos comando perl scripting winapi cmd

linea - perl ejecutar comando del sistema



¿Cómo hago que los scripts de Perl reconozcan parámetros en la consola cmd de Win32? (7)

Descubrí cuál era el problema. Aunque los valores ftype y assoc se establecieron según lo sugerido, el comportamiento real en mi sistema parece estar determinado por la clave de registro

HKEY_CLASSES_ROOT/Applications/perl.exe/shell/open/command

Debe tener un valor de cadena (Default) de "C:/Perl/bin/perl.exe" "%1" %*

Cuando encontré esta entrada, se configuró en "C:/Perl/bin/perl.exe" "%1" . Cambiarlo solucionó el problema de inmediato.

¿Por qué fue establecido de esa manera en primer lugar? No lo sé. Tal vez de una instalación anterior?

De todos modos, gracias por las sugerencias, y espero que esta respuesta también ayude a alguien más.

Cuando invoco mis scripts de Perl en el entorno de Windows sin invocar perl primero, los parámetros no se pasan a mi script.

Por ejemplo,

C:/> C:/my-perl-scripts/foo.pl bar

invoca foo.pl pero no reconoce la bar como parámetro ( @ARGV está vacío). Sin embargo,

C:/> perl C:/my-perl-scripts/foo.pl bar

funciona como se esperaba

¿Es esto un problema de configuración?

Idealmente, me gustaría poder distribuir algunos scripts Perl, hacer que el usuario agregue C:/my-perl-scripts/ a la ruta y luego solo invocar foo.pl desde cualquier lugar mientras ejecuta cmd.

Si primero tienen que especificar perl, entonces siempre tendrán que dar una ruta completa.

¿Alguna idea o recomendación?

Editar: para mostrar que la asociación y el tipo son correctos en mi sistema, ejecuté los siguientes comandos.

C:/>assoc .pl .pl=Perl C:/>ftype Perl Perl="C:/Perl/bin/perl.exe" "%1" %* C:/>more t.pl print "''$_''/n" for @ARGV; C:/>t a b C:/>perl t.pl a b ''a'' ''b'' C:/>t.pl a b C:/>

Incluí tanto la salida de t como t.pl para mostrar que no es un problema% PATHEXT%. Ambos no dieron salida a nada como se describió originalmente, mientras que la invocación de perl primero dio la respuesta esperada.

No estoy seguro de dónde mirar después, pero gracias por las sugerencias hasta ahora. Han sido de gran ayuda.

Editar 2: el problema parece estar en mi caja de negocios de Vista. En mi cuadro xp pro, funciona como se esperaba. Ambos tienen ActivePerl 5.8.9. Tengo otra caja casera vista que todavía no he probado. Volveré a publicar si descubro algo.

Editar 3: Encontré la respuesta (publicada a continuación). Lo encontré ejecutando un limpiador de registro, eliminando Perl, ejecutando el limpiador de registro nuevamente. En la segunda limpieza, solo quedó una entrada inválida, la que causaba el problema (probablemente sobrante de una instalación anterior).


Actualización: Dado que lo siguiente es correcto, lo único que queda por asegurarse es que las extensiones de comando no estén desactivadas. Tratar:

cmd /e:on

en la línea de comando antes de ejecutar tus pruebas. Consulte también la documentación del cmd de Windows XP :

Habilitar y deshabilitar extensiones de comando

Las extensiones de comando están habilitadas por defecto en Windows XP. Puede deshabilitarlos para un proceso en particular usando / e: off. Puede habilitar o deshabilitar extensiones para todas las opciones de línea de comandos cmd en una computadora o sesión de usuario estableciendo los siguientes valores REG_DWORD :

HKEY_LOCAL_MACHINE/Software/Microsoft/Command Processor/EnableExtensions/REG_DWORD

HKEY_CURRENT_USER/Software/Microsoft/Command Processor/EnableExtensions/REG_DWORD

Establezca el valor REG_DWORD a 0x1 (es decir, habilitado) o 0x0 (es decir, deshabilitado) en el registro mediante Regedit.exe. La configuración especificada por el usuario tiene prioridad sobre la configuración de la computadora, y las opciones de línea de comando tienen prioridad sobre la configuración del registro.

E:/Temp> assoc .pl .pl=Perl

E:/Temp> ftype Perl Perl="C:/opt/Perl/bin/perl.exe" "%1" %*

E:/Temp> @echo %PATHEXT% .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PL;.PLX;.WPL;.py;.pyw

E:/Temp> cat t.pl print "''$_''/n" for @ARGV;

E:/Temp> t a b c d e f g h j ''a'' ''b'' ''c'' ''d'' ''e'' ''f'' ''g'' ''h'' ''j''

He utilizado casi todas las distribuciones de ActiveState Perl desde 2004. Estas configuraciones son suficientes para que funcionen.


Hmmm ... parece que la asociación de archivos para * .pl está mal de alguna manera. No estoy en una caja de Windows, así que no puedo probar esto. Puede verificar la asociación de archivos con el ASSOC o FTYPE en la línea de comandos. IIRC, " ASSOC .pl " debería decirle cuál es el tipo de archivo y " FTYPE command " le dice al shell qué hacer con un script de Perl. Pruebe algo como:

C:/> ASSOC .pl=perlscript C:/> FTYPE perlscript=C:/Perl/bin/perl.exe %1 %*

Desde el aspecto de una de las referencias de comando que debería hacer el truco. Supongo que la asociación actual no está pasando los parámetros junto con el guión. Debería poder verificarlo utilizando ASSOC .pl para descubrir cuál es el nombre de la asociación de archivos y luego usar FTYPE para imprimir el comando que el shell va a ejecutar.

Actualizar

Encontré algo interesante que quiero señalar para la posteridad. Empecé a ver exactamente este problema en una máquina de amigos en el trabajo con respecto a algunos scripts de Python. ASSOC y FTYPE dieron FTYPE resultado el resultado esperado, pero los parámetros aún no se transmitieron, exactamente lo que se informó originalmente .

Después de investigar un poco, descubrí que la configuración del registro se creó en algún lugar de la línea como valores REG_SZ . Los borré y los re-creé usando ASSOC y FTYPE y todo comenzó a funcionar ... al mirar el registro me dio la respuesta: ¡ los nuevos valores se crearon como REG_EXPAND_SZ ! Estos funcionaron exactamente como se esperaba.


Para resumir.

ftype es viejo y a cmd.exe no le importa lo que diga.

El verdadero problema es HKEY_CLASSES_ROOT / Applications / perl.exe / shell / open / command.

Simplemente ejecute: reg add HKEY_CLASSES_ROOT/Applications/perl.exe/shell/open/command /ve /d "C:/strawberry/perl/bin/perl.exe /"%1/" %*" /f

y todo estará bien. (* dado que "C: / strawberry / perl / bin / perl.exe" es la ruta exacta a su instalación perl. *)

/ ve está diseñado para trabajar en "(Predeterminado)" REG_SZ valor / d es asignar "datos" al "valor" / f para forzar la sustitución (o sobreescritura) del valor preexistente

De hecho, si assoc .pl=Whatever y ftype Whatever que no existe (nunca le asigne un valor, o haga ftype Whatever= para ftype Whatever= asignación), los scripts podrían invocarse sin perl.exe .

Por lo tanto, si usa Windows> = 6.0 (Vista, 2008, 7, etc.) simplemente olvide que existen los comandos assoc y ftype. No te molestes ¡Vaya reg.exe!


Traté de actualizar y asociar .pl con las diferentes entradas de PERL en el registro que otros han probado ( .pl , Perl , PerlScript , pl_auto_file , Applications/perl.exe ) y ninguno de estos funcionó. Estoy ejecutando AS Perl 5.14.2 en Windows 7. Luego noté que había una entrada para /Applications/perl5.14.2.exe en el registro y estaba configurada para:

"C:/Perl/bin/perl5.14.2.exe" "%1"

Agregué el %* a esto y luego pude ver los datos en @ARGV .

También noté que en algunas de estas entradas tenía una entrada de ruta de comando de "C"/Perl64/..." de un PERL de 64 bits anterior que había instalado anteriormente y desinstalado cuando descubrí que PERL de 64 bits no es '' Es tan bueno con IIS 7 como PERL de 32 bits. Por lo tanto, hay restos de instalación colgantes que probablemente también estén afectando a las cosas.

Así que la respuesta aquí probablemente no es breve y está en palabras simples ... "Depende ..." (en su sistema e instalación).


Después de solucionar el problema de asociación de archivos no pudo pasar los parámetros. Un usuario que admita la extensión de archivo .pl erróneamente asociada con el bloc de notas después de intentar ejecutar un script desde la línea de comandos (Windows 7 Professional) por primera vez. Probé todos los trucos de asociación de archivos y las correcciones de variables de entorno en vano. Desinstalado y reinstalado e intentado instalaciones de 32 bit y 64 bit. El problema solo estaba presente en el perfil de los usuarios.

Finalmente entró en el registro y simplemente eliminó la clave de

HKEY_CLASSES_ROOT / Applications / perl.exe / shell / open / command

y agregado de nuevo a través de

reg add HKEY_CLASSES_ROOT / Applications / perl.exe / shell / open / command / ve / d "C: / strawberry / perl / bin / perl.exe /"% 1 / "% *" / f

comenzó a pasar parámetros de nuevo Gracias "lucretius"


Encontré esta ubicación adicional en el registro que tenía que actualizarse antes de que funcionara para mí. Nota: El nombre después de HKEY_USERS puede ser diferente en su máquina.

Agregar% * a la cadena predeterminada:

HKEY_USERS / S-1-5-21-1399284159-2775065347-350672949-4058_Classes / pl_auto_file / shell / open / command "D: / Perl / bin / perl.exe" "% 1"% *