2009-07-22 11 views
5

Estoy en el proceso de responder a una licitación de un contrato que requiere una buena cantidad de procesamiento de texto. El problema principal es que el cliente desea poder ejecutar esto en cualquier plataforma UNIX (HPUX, Solaris, AIX, FreeBSD) o Linux (SLES, RHEL), lo que puede limitar lo que uso para hacerlo. No quieren que la instalación de herramientas adicionales sea un requisito previo.¿Hay plataformas Unix donde Perl no está instalado por defecto?

Estoy dividido entre Perl y awk. Sé que Perl es una herramienta ideal para procesar texto (y soy bastante adepto) pero, antes de presentar la respuesta RFT que se requerirá de Perl, me gustaría saber si alguien se está ejecutando en una plataforma. donde Perl no está instalado por defecto.

Sería útil enumerar esas plataformas en el RFT y dar al cliente la opción de qué camino desea. Recuerdo vagamente que no está en FreeBSD en la instalación predeterminada y que las plataformas que no son Linux tampoco lo tienen.

Se pueden sugerir otras herramientas pero, dada mi familiaridad con Perl y awk, probablemente sean las únicas en la lista restringida.

Respuesta

13

Puede obtener una versión de Perl compilada para casi cualquier variante de Unix. Perl no tiene que estar 'instalado', pero puede ejecutarse dentro del directorio de su aplicación. Adjuntaría a Perl con mi distribución, para que pueda asegurarse de que está ejecutando la misma versión.

Es muy difícil escribir una secuencia de comandos de shell completamente cruzada, sin probar en el sistema operativo de destino. Si desarrolla un script awk, probablemente desarrolle usando la variante GNU en Linux, que es un superconjunto del POSIX awk. A menudo configuro la fuente de apertura packages on Solaris, y constantemente encuentro problemas donde la gente asume que ejecuta una versión moderna de una herramienta. Por ejemplo, en Solaris bash no es el shell estándar de bourne (/ bin/sh), y echo no toma ningún parámetro. Si intenta codificar con POSIX awk, puede encontrarse limitado por la biblioteca de expresiones regulares o las convenciones desactualizadas.

Perl's artistic licens e le permite agruparlo con su programa, siempre y cuando siga un par de cosas simples como mantener intactos los derechos de autor.

+0

En realidad, esa es una buena idea (empaquetar en un subdirectorio) ya que me permite controlar la versión también, aunque tendré que enviar varios paquetes (o un paquete con muchos subdirectorios perl seleccionados en el tiempo de ejecución, uno por plataforma). Veré la licencia. +1. – paxdiablo

3

Casi todos * nix (excepto algunos para espacio de disco muy limitado) tienen instalado Perl. AFAIK, incluso FreeBSD. En caso de que no lo sea, puede transformar el programa Perl en un ejecutable que no necesitará perl con PAR::Packer.

+1

¿Por qué * incluso * FreeBSD? –

+0

@Sinan, supongo que "incluso BSD" ya que tenía una vaga idea de que no lo enviaban como estándar, sino a través de los puertos. – paxdiablo

+2

@Pax Duh! Su respuesta tiene sentido entonces. He usado FreeBSD desde la versión 5 y todos ellos tenían Perl instalado por defecto. El sistema Perl tendía a ser más antiguo que los puertos Perl, pero hay un script de shell que permite que root seleccione qué Perl será el predeterminado. –

2

incluso si Perl puede estar instalado en casi todas las plataformas * nix, es posible que no sean la misma versión, así que tenga en cuenta esto. Con el requisito de que necesita funcionar en la mayoría de * nix, puede simplemente codificar con utilidades shell +. Para analizar archivos, awk + shell también puede hacer el trabajo. solo tienes que escribirlo en un formato "portátil". check this fuera para más información

+1

uno de los objetivos de Perl (a diferencia de muchos otros idiomas) es ser muy compatible entre lanzamientos, por lo que solo es necesario escribir para la versión mínima. –

+1

Supongo que esto sería Perl 5.6. – innaM

+2

Hay algunas plataformas (muy raras) que no tienen buenos puertos Perl más allá de 5.004, pero en general 5.6 es un buen objetivo. Ha estado en uso desde 2000. – ephemient

4

Si el cliente no tiene Perl en sus máquinas, siempre puede usar Par::Packer para crear un ejecutable para esa plataforma. Esto también significa que no tiene que preocuparse por usar módulos, ya que también se incluirán en el ejecutable.

+0

Tenga cuidado si el módulo usa específicamente una licencia no permisiva como AGPL o algo. En realidad, tendrás que distribuir el código fuente de los módulos que uses. No es difícil, pero puede ser un dolor. – Weegee

+0

Hmm, yo diría que, uno puede recuperar el origen del ejecutable y, siempre que no lo modifique, CPAN debería contar como hacer que la fuente esté disponible. –

+0

@Weegee, Par :: Packer solo comprime los archivos, por lo que es trivial extraer cualquier código. LGPL puede requerir que usted haga posible que el usuario construya un nuevo ejecutable con su código modificado, lo que podría ser un problema. La forma más sencilla de lidiar con eso es incluir cualquier biblioteca involucrada en un archivo par separado. Su archivo principal puede cargar el archivo secundario. – daotoad

2

Aunque supongo que todas las versiones actuales de los sistemas operativos que mencionas instalan Perl, habrá, por supuesto, versiones anteriores que no lo hicieron ni lo hicieron. También debe tener en cuenta que incluso las herramientas como awk no se instalaron de manera rutinaria en versiones muy antiguas de UN * X, ya que esta y otras herramientas de programación eran extras opcionales (con un costo adicional). Recuerdo sistemas Altos donde incluso la pila TCP/IP fue un elemento costo adicional, pero es de suponer que no vamos tan atrás :-)

En pocas palabras: Si su aplicación realmente necesita Perl debe verlo está instalado (a través de una secuencia de comandos de shell Bourne - si theat no funciona realmente está jodido) y si no proporciona alguna forma de instalarlo.

0

Las Unidades comerciales tienden a agruparse con versiones muy antiguas de Perl.

Cuestiones relacionadas