Perl Script Portability y Future Proofing

Question

Debido a la presión externa a nuestro grupo, tenemos que exportar más de cien scripts Perl de Sparc a x86. Esto significa cambiar docenas de líneas de shebang de #!/home/Perl/bin/perl -w a otra cosa, lo cual es un verdadero dolor. ¿Cuál es la buena manera de hacer esto (no puedo encontrar nada en Lycos)?

¿Qué sucede cuando nos vemos obligados a pasar de x86 a otra cosa (como Cray, supongo)? ¿Hay alguna manera de "a prueba de futuro"?

Answer 1

Cambio de las líneas shebang en masa no es tan malo:

#! /usr/bin/perl 

use warnings; 
use strict; 

use File::Find; 

sub usage { "Usage: $0 dir ..\n" } 

my @todo; 
sub has_perl_shebang { 
    return unless -f; 
    open my $fh, "<", $_ or warn "$0: open $File::Find::name: $!", return; 
    push @todo => $File::Find::name 
    if (scalar(<$fh>) || "") =~ /\A#!.*\bperl/i; 
} 

die usage unless @ARGV; 
find \&has_perl_shebang => @ARGV; 

local($^I,@ARGV) = ("",@todo); 
while (<>) { 
    s[^(\#!.*) $ ][#! /usr/bin/env perl]x 
    if $. == 1; 
    print; 
} 
continue { 
    close ARGV if eof; 
} 

Dependiendo de lo que tienes, la s/// puede necesitar ser un poco más inteligente para manejar switches como -T que deben estar en la línea shebang.

añadir una opción de funcionamiento en seco con algunos cambios, además de un uso interesante de redo:

my $dryrun; 
{ 
    die usage unless @ARGV; 
    $dryrun = shift @ARGV, redo if $ARGV[0] eq "-n"; 
} 

find \&has_perl_shebang => @ARGV; 
if ($dryrun) { 
    warn "$0: $_\n" for @todo; 
    exit 1; 
} 

Answer 2

Perl es multiplataforma. A menos que su código haga uso del código compilado XS o rutas, instalaciones, etc., específicos del sistema, debería estar bien.

tiene dos opciones:

1. No utilice líneas shebang (perl yourscript.pl).
2. find . -name '*pl' | xargs sed 's/#!\/home\/Perl\/bin\/perl -w/#!\/usr\/bin\/env perl/

En cualquier caso, la línea tinglado no tiene nada que ver con la plataforma de hardware que se está ejecutando, y todo ello con la cáscara se está ejecutando en.

Answer 3

Esta es una razón por la que muchas personas defienden el uso #!/usr/bin/env perl en lugar de #!/usr/bin/perl:

Answer 4

Otra alternativa (podría ser más simple aunque yo dudaría en decir "mejor") es, por supuesto, para vincular /home/Perl/bin/perl al lugar donde esté el binario real de Perl en los nuevos sistemas ... solo es factible si tiene herramientas eficientes de administración de sistemas a granel que la mayoría de las empresas normales deberían.