2012-08-06 18 views
5

Tradicionalmente, sólo tendría C:\perl\bin en mi variable PATH, pero debido a conflictos de versión me gustaría mantener diferentes versiones de Perl en lugares C:\Perl-versionXY\bin y sólo hay que ejecutar mis scripts de Perl a través de la invocación directa de C:\Perl-...\bin\perl.exe theScript.pl.¿Necesito el directorio Perl bin en la RUTA para ejecutar programas perl (en Windows)?

Esto se debe ejecutar en realidad bajo un sistema automatizado, donde ya invocamos directamenteC:\perl\bin\perl.exe para todos los scripts Perl. (Pero es C:\perl\bin también en el PATH.)

para facilitar diferentes versiones de Perl de lado a lado, me gustaría quitar C-perl-bin desde el PATH para asegurarse de que no lo hacemos alguna vez vea efectos secundarios de cualquier configuración de PATH relacionada con Perl.

¿Se supone que esto funciona? ¿Qué pasa con los módulos que requieren archivos DLL adicionales (como LibXML, que requiere LibXML.dll en el directorio bin de perl)?

Voy a utilizar Strawberry Perl portátil para las versiones una al lado de la otra. (¿Quién es el archivo Léame menciona algunas configuraciones de RUTA, pero no menciona cuál se utiliza para qué?)

+0

quiso decir 'C: \ bin \ perl', porque eso tendría mucho más sentido –

+1

@johncorbett: ¿por qué tendría más sentido? Windows no es unix, por lo que no tiene c: \ bin. C: \ perl \ bin tiene mucho sentido, en mi humilde opinión – pavel

+0

Jaja, supongo que Unix está tan perforado en mi cabeza, incluso en Windows uso cygwin –

Respuesta

1

Siempre que todas las DLL estén en el mismo directorio que el ejecutable, debería funcionar normalmente. Si solo hay una entrada para Perl en la ruta, entonces las DLL deben estar en el mismo directorio que el ejecutable (o se están encontrando usando alguna lógica explícita) por lo que debería estar bien. Cuando un archivo ejecutable carga un archivo DLL, el primer lugar que se busca es el directorio que contiene el archivo ejecutable.

Si tiene problemas, una opción sería crear un archivo de comando para cada versión. Puede dar estos nombres diferentes, como perl58.cmd, perl514.cmd, etc., ponerlos todos en un único directorio y poner ese directorio en la ruta. En cada archivo de comandos, agregue el directorio Perl correspondiente a la trayectoria y luego lanzar Perl con los argumentos de línea de comandos:

setlocal 
PATH=c:\perl58\bin;%PATH% 
perl %* 

Nota uso del comando setlocal de modo que el cambio en el camino no se exporta de nuevo a la ventana de línea de comandos desde la que ejecuta el archivo de comando.

0

Me gustaría advertir que si no tiene el directorio Perl bin en la RUTA, y todo lo que ejecuta intenta invocar programa que vive en el directorio bin sin proporcionar una ruta explícita (mala práctica, pero eso no impide que ocurra), entonces obtienes un error y, dependiendo de cómo se maneje esa falla, podría manifestarse en problemas que son sutiles y difíciles de depurar.

Así que digo que, a menos que tenga una razón muy convincente para no agregarla (por ejemplo, una política de TI que lo haga prohibitivo y molesto para agregar a PATH), agréguela.

+0

Bueno, si tengo dos versiones diferentes, una dice 5.8 y una 5.14, solo puedo agregar significativamente una de ellas a la ruta (global). Sería el camino equivocado para la otra versión. Por lo tanto, no parece tener ningún sentido agregarlo a la ruta (global) y sería mucho más fácil no tenerlo en la ruta de acceso que tener que configurarlo en función del contexto. –

+1

Es una práctica común en los sistemas Unix para envolver ejecutables con scripts de shell que configuran el entorno en el que se ejecutará el ejecutable. ¿Hay alguna razón por la que no pueda envolver las invocaciones de sus programas perl en scripts por lotes o powerShell? –

Cuestiones relacionadas