¿El lenguaje de script más universal para Linux es?


24

Estamos escribiendo scripts para sistemas Linux, se ha debatido sobre cuál sería el lenguaje de scripting más universal de Linux para usar. Bash, SH, Posix? ¿Qué?


3
Supongo sh.
Blender

¿Tienes una lista de distribuciones de destino? ¿O distribuciones obligatorias / deseables en las que debe ejecutarse?

44
"sh"? Qué SH"? ¿La cáscara de Thomson? la cáscara de Bourne? bash, ksh, pdksh, ash, zsh como se encuentra en /bin/shel sistema X o Y ? La especificación sh POSIX, la especificación SUSv3, SUSv4 sh, la especificación LSB sh? "sh" en sí mismo no significa nada.
Stéphane Chazelas

1
si esto es para compilaciones de software e instalar scripts, es posible que desee consultar Autotools, que intenta resolver problemas de compilación entre sistemas.
Lie Ryan

1
@sch La intersección común más portátil, "obviamente". En caso de que las personas que no estén familiarizadas con los shells de Unix se confundan con su comentario, la especificación POSIX se implementa en casi todos los shells contemporáneos que se atreven a llamarse así sh, y los no conformes shque no son antiguos y raros en la actualidad (por ejemplo, Bourne). Uno puede recitar una lista cada vez mayor de extensiones y variaciones, pero si el objetivo es "universal" o portabilidad, uno debería ir en la dirección opuesta. La respuesta de Gilles cubre los detalles con más profundidad.
jw013

Respuestas:


38

Hay dos entornos de programación que están disponibles en todos los sistemas operativos tipo Unix, que son completos de Turing y que pueden llamar a otros programas: awk y sh , la familia de shell Bourne / POSIX. AWK está orientado hacia el procesamiento de texto (complementa las utilidades más especializadas), mientras que sh está orientado hacia ser un lenguaje adhesivo para unir programas. Sh es el lenguaje de script universal en Linux y en todo el mundo Unix.

El estándar POSIX define las características obligatorias de sh en sí y las utilidades asociadas. La mayoría de los sistemas tipo UNIX cumplen con POSIX 1003.1-2004 (también conocido como Single Unix v3, también conocido como el problema 6 de Open Group Base Specification); la última versión de ese estándar es POSIX 1003.1-2008 (también conocido como Single Unix v4, también conocido como Open Group Base Specification Issue 7).

Todos los sistemas Linux y Unix o Unix tienen un shell de estilo Bourne en el camino /bin/sh, y cualquier sistema no antiguo tiene un shell compatible con POSIX (salvo el error ocasional). Todos los sistemas modernos tipo Unix (incluido Linux) son compatibles con shebangs , por lo que automáticamente ejecuta scripts /bin/shsi la primera línea lo es #!/bin/sh. Hay sistemas POSIX en los que shse ubica en otro lugar (generalmente, capas de emulación en sistemas operativos que no consideraría realmente como Unix).

Los sistemas Linux integrados pueden tener un sistema BusyBox simplificado que no implementa todas las funciones POSIX. BusyBox tiene una gran cantidad de opciones de tiempo de compilación para acomodar sistemas de tamaño reducido, por lo que es difícil saber qué esperar con anticipación, tiene que adaptar sus scripts a un dispositivo en particular. BusyBox es la implementación de huella pequeña más común de sh y una variedad de utilidades; otro que puede encontrar es el entorno de shell extremadamente reducido en Android (las versiones posteriores son menos anémicas).

Los sistemas Linux no integrados casi siempre tienen guiones o bash como /bin/sh. Dash es un shell pequeño y rápido que implementa poco más que las funciones POSIX. Bash es un shell más grande con más características.

Los sistemas Linux no integrados casi siempre tienen Bash instalado como /bin/bash. Por lo tanto, para la portabilidad en sistemas Linux no integrados, puede suponer que bash está disponible. Entre las características adicionales útiles de bash están las matrices, la capacidad de hacer frente a los archivos de puntos convenientemente, la pipestatusvariable para obtener el estado de retorno de todos los comandos en una tubería, operadores de comparación adicionales para tiempos de archivo y (en versiones recientes) coincidencia de expresiones regulares .

Una de las características de la programación de shell es que no solo estás usando el shprograma, sino que también estás usando una serie de utilidades . La mayoría de las utilidades de manipulación de archivos y procesamiento de texto en Linux son los coreutils de GNU (en sistemas integrados, generalmente son de BusyBox).

Si necesita portabilidad más allá de Linux, su mejor opción es apegarse a POSIX. Es posible que otras variantes de Unix no tengan instalado bash (bash es parte de la instalación estándar en OSX, pero es un paquete opcional en * BSD y la mayoría de las unidades comerciales). Casi todas las variantes de Unix que no sean Linux y OSX (es decir, * BSD y unidades comerciales) tienen alguna versión del shell Korn , al menos pdksh . Muchas de las extensiones convenientes de bash son de ksh, por lo que puede ser útil escribir scripts que puedan ejecutarse en ambos, pero detectar dónde se encuentra bash o ksh en un sistema desconocido puede ser un poco complicado.

El caparazón no puede hacer todo. Si necesita un lenguaje más sofisticado, las dos opciones más comunes son Perl y Python (cualquier otra cosa está muy por detrás como un lenguaje de script Unix). Perl es el lenguaje de script tradicional, y pocos sistemas Linux no integrados carecen de él, pero Python está ganando terreno (impulsado en parte por ser el lenguaje de script recomendado para Ubuntu). En el mundo no Linux, Perl es parte de la instalación base en OSX y OpenBSD; es opcional pero muy comúnmente instalado en FreeBSD, y opcional pero a menudo instalado en NetBSD.


1
"impulsado en parte por ..." Eso y ser casi obligatorio en los sistemas Fedora y RHEL.
Ignacio Vazquez-Abrams

Principalmente de acuerdo con todo esto. Solo algunos énfasis diferentes: * algunas distribuciones están basadas en BusyBox pero no necesariamente integradas (uso una, Alpine). (Por supuesto, la respuesta no decir "casi siempre".) * BSD son una gran clase de sistemas similares a Unix donde no se puede asumir fiesta por defecto. * dash puede hacer casi todo lo que bash puede, solo a veces exige más cuidado. * Si necesita un lenguaje más sofisticado, sí, Perl y Python son las opciones más comunes, pero awk es aún más omnipresente y es adecuado para muchos propósitos. También se subestima comúnmente. Pero es más ligero que Perl y Python.
dubiousjim

2
Sin embargo, una advertencia justa: FreeBSD eliminó a Perl de su instalación predeterminada hace algún tiempo. Aparte de eso, no conozco ninguna otra distribución que no tenga Perl en su instalación base.
TC1

@ TC1 Perl siempre fue opcional en NetBSD. Está en el sistema base en OpenBSD.
Gilles 'SO- deja de ser malvado'

@dubiousjim Solo Linux (no integrado, o una aproximación suficientemente buena en la práctica) y OSX tienen bash en su instalación predeterminada; * BSD tiene pdksh o mksh, y las unidades comerciales tienen ATT ksh.
Gilles 'SO- deja de ser malvado'

11

En orden de disponibilidad:

  1. sh, pero atenerse a las instalaciones especificadas por POSIX
  2. bash, pero no olvides especificarlo explícitamente en el shebang o podrías obtener un guión.
  3. Pitón. Casi todos lo usan.
  4. Perl. Pero puedes escribirlo.

Después de eso, a nadie realmente le importa, ya que no hay mucho que no puedas hacer solo con eso.


10
Pondría PERL antes que python, está instalado por defecto en la mayoría de los sistemas Linux.
terdon

44
Perl es el # 3. Y puedes escribirlo, ¡bonificación! :)
Warren Young

2
Estoy de acuerdo con @ignacio perl es # 4 y python es # 3. El motivo es obvio. Creo que Python es la evolución de perl.
bagavadhar

55
@ashwin: no, python no es una evolución de, o incluso como, perl. perl es un lenguaje de sysadmins para sysadmins. Python es un lenguaje de programadores para programadores. Esa diferencia es crucial. Ambos tienen sus usos y, si bien puede haber una gran superposición en los casos de uso, para algunas tareas, Perl es la mejor opción, y para otras Python es claramente superior.
cas

1
Ruby y PHP fueron inspirados por Perl. Python es el resultado de un experimento de física en el que crearon anti-Perls en un supercollider. (No tengo nada en contra de Python. Ventajas y desventajas, ventajas y desventajas.)
Warren Young

4

Por lo general, diría sh... pero como especificó Linux, diré bashque está garantizado en todos los sistemas Linux (bueno, excluyendo los oscuros pedantes pequeños que fetichizan el minimalismo :).

Si no tiene que preocuparse por la portabilidad que no sea de Linux (y si no necesita ejecutar en pequeñas distribuciones o en dispositivos Linux integrados como enrutadores de caja de plástico), entonces también puede hacer uso de las mejoras significativas que Se ofrece sobre llano sh. De lo contrario uso sh.

Después de bash(y sh), el siguiente lenguaje de scripting más "universal" para Linux sería algún dialecto de awk- usualmente uno mawko gawk. Si se queda con awk simple y evita gawkisms, su script debería funcionar bien en casi cualquier sistema Linux (puede faltar en pequeñas distribuciones o dispositivos integrados). La mayoría de los sistemas Linux tendrán ambos mawky gawkestarán disponibles, pero en algunas distribuciones (debian, por ejemplo) mawkse instala de manera predeterminada y debe instalarlo gawkusted mismo si lo desea.

El siguiente sería perl. AFAIK, el lenguaje perl base se instala por defecto en todas las distribuciones de Linux comunes, por lo que es una buena opción. Aún más afortunadamente, hay muy poca incompatibilidad de versiones con las versiones perl5 (aunque perl 5.12 o podría haber sido 5.14 finalmente logró eliminar algunas características oscuras que habían quedado en desuso durante unos 15 años ... amplia advertencia de no usarlas). a menos que su estilo de codificación sea realmente extraño y le guste ignorar las advertencias de "no hacer eso" durante más de una década, sus scripts de Perl se ejecutarán perfectamente en casi cualquier lugar. El lenguaje es robusto y poderoso y puede hacer todo lo que puede awky sedpuede hacer y más. Con un poco de esfuerzo puede hacer las cosas queshtambién es tradicionalmente bueno (por ejemplo, ejecutar comandos externos y usar / canalizar la salida). Las bibliotecas perl estándar también son bastante completas, ya que cubren más que solo lo básico.

El único inconveniente con Perl es que también hay una enorme biblioteca de módulos CPAN para hacer casi cualquier cosa que se te ocurra (y muchas más que nunca se te ocurrirán), y no todos estarán disponibles en todos los sistemas con Perl . Por lo general, son de muy alta calidad, por lo que es fácil acostumbrarse a usarlos, pero si los usa, deberá asegurarse de que estén instalados. Muchos módulos CPAN están preenvasados ​​para Linux, y el resto se instala fácilmente con la herramienta cpan (o dh-make-perlen debian / ubuntu / etc para convertir un módulo CPAN en un paquete .deb)

Me gustaría poder decir lo pythonsiguiente, pero realmente no puedo. Python tiene mucho que gustar, pero no está incluido de manera predeterminada en muchos sistemas Linux y, francamente, su compatibilidad de versiones (tanto para Python como para sus supuestamente libs "estándar") es un completo desastre. Algunas distribuciones hacen un excelente esfuerzo para resolver el desastre, y otras no. Tampoco les ayuda el hecho de que python es básicamente un lenguaje escrito para programadores por programadores (a diferencia de los administradores de sistemas) y no parecen pensar que el sistema en el que se instalará su código sea de suma importancia ... su código es realmente súper especial, por lo que no necesitan preocuparse por cosas aburridas como la integración en los sistemas existentes.

(No tenga una idea equivocada de mi sarcasmo aquí; realmente me gusta Python como lenguaje, odio el hecho de que la gestión de versiones y dependencia es una PITA. Es como retroceder más de 20 años a la era de la búsqueda manual de lo oscuro bits de código y parches para obtener algo compilado y ejecutado en su propiedad * nix)


Sé que esta es una publicación antigua, pero la mejor manera de evitar esto es especificar qué versión en el shebang (por ejemplo /usr/bin/python2, /usr/bin/python3).
Isiah Meadows

1

Sugeriría seguir ksh93 o incluso POSIX sabor y siempre puedes usar bash / zsh para ejecutar.

Y la distribución basada en Debian usa mawk no gawk como awk por defecto. Entonces sí, evite las adiciones de gawk ya que mawk es mucho más rápido.


0

No bash. Escriba en un sh cerca de POSIX como guión o ceniza. Eso va a ser lo más universal. No creo que haya nada más que sea un competidor cercano. (Y esto me parece una pregunta objetiva, no una "opinión" como se queja uno de los comentaristas).

Si necesita algo un poco más potente que sh (por ejemplo, si desea matrices asociativas reales), use awk. (Evitar las extensiones gawk. Hay muchas versiones de awk, pero hay un núcleo compartido en gran medida). Eso debería estar disponible casi tan ampliamente como sh.


1
awk-on-Linux es universalmente gawk; No puedo pensar en ninguna distribución que tenga otra variante por defecto.
Ignacio Vazquez-Abrams

55
¿Qué variantes de Linux no son compatibles bash?
Jonathan Leffler

1
Ciertamente bashpuede instalarse y ejecutarse en (casi) cualquier caja de Linux, pero muchos usuarios de Debian solo instalarán dashy preferirán no instalar bash.
William Pursell

66
@WilliamPursell El paquete bash está etiquetado como Essential en Debian (es decir, debe pasar por aros para desinstalarlo, con amplias advertencias de que esto afectará su sistema). Bash es casi universal en sistemas Linux no integrados.
Gilles 'SO- deja de ser malvado'

1
@ JonathanLeffler: los incrustados, por el contrario, solo pueden tener Busybox.
Caracol mecánico

0

Yo diría que la disponibilidad se ubicaría en algún lugar en este orden:

  1. sh
  2. awk
  3. Perl (todavía no he visto un * nix sin él, incluidos los BSD)

Aunque Python suena como un buen lenguaje, no he usado ningún sistema operativo que venga con él en una instalación base, aunque aparentemente Ubuntu, ¿tal vez?


0

Creo que los expertos aquí ya han proporcionado excelentes sugerencias que deberían ayudarlo a decidir. La usabilidad y disponibilidad de los diferentes shells se han descrito muy bien en las otras publicaciones.

En una nota diferente, si yo fuera usted, también consideraría el objetivo que quiero lograr con los guiones. Cada herramienta tiene sus propios méritos y deméritos. Entonces, aunque uso Python en gran medida, no lo usaré en todos los casos.

Puedo pensar en algunos escenarios y mencionar algunas herramientas útiles para ellos.

Archivos FTP de un lado a otro; procesarlos; enviar notificaciones por correo electrónico; y así

En este caso, sería mejor quedarse con el shell (p. Ej., Bash) y utilizar las diversas utilidades (p. Ej. ftp, cronY mail). Este es un caso de uso típico en muchas grandes empresas.

Procesamiento de texto rápido

Una vez más, la cáscara. Las utilidades como grep, awk, sed, pastey otros son muy útiles en este caso.

Construir

En el dominio C / C ++, la herramienta universal para esto es make. El mundo Java prefiere Apache ANT.

Despliegue y control remoto

Ya sea el shell o Python. Por ejemplo, scpy rsync, respectivamente, sería bastante útil para copiar los archivos o sincronizar los archivos.

Python, por otro lado, tiene un módulo muy útil llamado fabric. Esto sería útil para operaciones más complejas, por ejemplo, copiar archivos, detener algún proceso, configurar el servidor y lo mismo. Además, Python también proporciona un módulo, pipque puede resolver las dependencias especificadas descargando e instalando los paquetes relevantes.

(Tenga en cuenta que las sugerencias anteriores no se centran mucho en las funciones de shell , sino en las diferentes utilidades disponibles).


-1

Perl no está en la base de FreeBSD, NetBSD o DragonflyBSD, lo siento. OpenBSD tiene Perl en la instalación base. OS X es hoy en día un UNIX certificado y puede considerarse como una especie de variante BSD en algún nivel y tiene Perl, Python y Ruby en la base.

Muchos UNIXen patentados no tienen Perl en su base, por ejemplo Solaris, AFAIK ni HP-UX o IBM AIX también ...


Su declaración sobre la pérdida de Solaris en Perl es incorrecta. Perl es un componente central obligatorio de Solaris al menos desde 2005 (Solaris 10).
jlliagre
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.