¿Cómo puedo ignorar el tinglado Perl en Windows con Apache 2?

Question

He creado un entorno web local Perl en mi máquina de Windows. La aplicación que estoy trabajando es originalmente de un servidor Linux, por lo que el tinglado para los archivos de origen .pl parezca así:

#!/usr/bin/perl

Esto hace que el siguiente error en mi máquina dev de Windows:

(OS 2)The system cannot find the file specified.

¿Es posible cambiar mi configuración del Apache 2 para que el tinglado se ignora en mi máquina de Windows? Por supuesto que podría establecer el tinglado a #!c:\perl\bin\perl.exe, eso es obvio; pero el problema viene a desplegar los archivos actualizados. Es evidente que sería muy inconveniente para cambiar esta de nuevo en cada despliegue. Estoy utilizando ActivePerl en Windows 7.

Actualización:

Debería haber mencionado que tengo que mantener el tinglado para que los guiones funcionarán en nuestro servidor de producción Linux alojamiento compartido. Si no lo tienen esta limitación y no tener que utilizar el tinglado, la respuesta obvia sería la de no utilizarlo.

Answer 1

Yo uso #!/usr/bin/perl en mis guiones y configurar Apache en Windows hacer caso omiso de la línea tinglado. Añadir

 ScriptInterpreterSource Registry-Strict

a su httpd.conf y establecer la clave de registro de Windows, como se explica en el rel="noreferrer"> .

Esto es lo que me pasa cuando exportar la clave:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command]
@="c:\\opt\\perl\\bin\\perl.exe"

He estado usando esta configuración con Apache y ActiveState Perl en mi portátil Windows y las distribuciones de Apache y Perl que vienen con Arch Linux en mi servidor.

Los docs Apache (a la que me vinculado anteriormente) Estado:

  

La opción de registro estricto que es nuevo en Apache 2.0 hace lo mismo que el Registro, pero sólo utiliza la Shell\ExecCGI\Command subclave. La clave ExecCGI no es muy común. Se debe configurar manualmente en el registro de Windows y por tanto evita que las llamadas accidentales del programa en su sistema . (Énfasis)

Answer 2

No hay una línea tinglado portátil. Perl, incluso en la misma plataforma y arquitectura, alguien podría haber instalado es un lugar diferente.

El truco es no instalar módulos y secuencias de comandos con la mano. Al empaquetar todo como distribuciones y el uso de la cadena de herramientas del módulo, las líneas shebang se modifican automáticamente para apuntar a la perl que utilizó para instalar todo. Usted no debería tener que pensar en estos detalles. :)

Answer 3

Yo uso #! /usr/bin/env perl como el tinglado en toda mi Perl, ya sea en * nix o Windows. Ventanas simplemente lo ignora, y el Unices sigue env a la disto Perl elegido.

Answer 4

La forma Tenía este trabajo era copiar perl.exe a c: / usr / bin / y cambie su nombre a perl (tira el .exe)

Answer 5

En Win7 y hasta también se puede hacer esto con el "dos" MKLINK comandos.

Iniciar un shell cmd como administrador y hacer algo como lo siguiente:

mklink /d c:\usr c:\Perl       # Activestate perl in c:\Perl\bin\perl.exe
mklink /d c:\usr c:\xampp\perl # Xampp perl in c:\xampp\perl\bin\perl.exe

Answer 6

No tengo de Windows útil, pero perlcritic dice:

my $desc = q{Found platform-specific perl shebang line};
my $expl = q{Perl source in parrot should use the platform-independent shebang line: #! perl};

Así que, supongo #! perl debería funcionar.

Edit: no funciona en Linux; al parecer trabaja en parrot, aunque no veo cómo logran eso.

Answer 7

1. Instalar cualquier sabor de Windows Bash (como Cygwin, MSYS2 o GnuWin32);

2. Crea una secuencia de comandos shell redireccionamiento trivial:

   exec "@"
   

3. Crea una entrada de registro:

   Windows Registry Editor Version 5.00
   
   [HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command]
   @="<path-to-sh> <path-to-script>"
   
   [HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command]
   @="<path-to-sh> <path-to-script>"
   
   [HKEY_CLASSES_ROOT\.py\Shell\ExecCGI\Command]
   @="<path-to-sh> <path-to-script>"
   

   (... y así sucesivamente.)

4. Jot en su archivo httpd.conf:

   ScriptInterpreterSource Registry
   

Apache ahora resolverá Unix shebangs relativa a la interpretación dada por su sabor elegido Bash. Esto da más más flexibilidad que hardcoding caminos del intérprete en el registro.