2010-04-27 16 views
9

¿Es una mejor práctica escribir scripts Bash o scripts Bourne? Mi equipo escribe los guiones de Bourne, pero no estoy del todo seguro de por qué.Bash o Bourne Scripts?

Si se trata de una cuestión de la guerra santa (es decir: vim vs emacs) por favor, sólo respuesta: la guerra santa.

+5

siempre y cuando no sea csh –

+1

[Programación Csh considerada nociva] (http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/) –

+0

¡Código de programadores REAL en Korn! :-P Siempre prefiero sh en comparación con bash, porque la mayoría de las funciones sintácticas serán las mismas o al menos compatibles con el comportamiento sh en la mayoría de las distros; mientras que bash simplemente no está disponible en algunos casos si trabajas con AIX, etc. Pero si trabajas con scripts solo para Linux, bash es preferible. Hace mucho más fácil la programación de imho. –

Respuesta

11

Depende de lo que es la plataforma de destino.

Si solo tiene como objetivo, por ejemplo, las principales distribuciones de Linux y Mac OS X, entonces puede estar seguro de que estos sistemas tendrán bash disponible. En otros UNIXes (por ejemplo, AIX, Solaris, HP-UX), bash puede no estar presente necesariamente, por lo que Bourne es la opción más segura. Si bash está disponible, no puedo pensar en ninguna razón por la que prefieras a Bourne.

12

Puede ser más seguro que shell Bourne se va a instalar en cualquier ordenador Unix dado. Sí, Bash es omnipresente en Linux, pero el mundo entero no es Linux.

+0

En este sentido, solo puedo pensar en tres razones: compatibilidad con versiones anteriores, portabilidad o "así es como siempre lo hemos hecho". –

+2

"Bash es omnipresente en Linux, pero el mundo entero no es Linux". Esta era mi creencia antes, luego comencé a trabajar con máquinas Solaris y HP-UX. Pensé que podría escribir guiones de shell en Bash para estas máquinas, ¡oh qué equivocado estaba! Pero fue una buena experiencia de aprendizaje humilde, ahora siempre uso el shell bourne y solo la sintaxis que sé que es compatible con POSIX. – Anders

4

Bueno, es una cuestión de gusto, pero para empezar, los guiones de shell bourne se pueden ejecutar con bash, y creo que bash tiene características que no pueden ser ejecutadas por Bourne.

10

Lo más importante es recordar que no todos los SO enlaces binarios/bin/sh a/bin/bash, como lo hacen algunas distros de Linux. Muchos guiones están escritos para bash, pero comienzan con:

#!/bin/sh 

para que se rompan, p. en Ubuntu. Por lo tanto, cuando se escribe escritura del golpe, siempre escribir:

#!/bin/bash 
+6

Uno de mis orkers de vacas estaba enojado con Ubuntu porque usaban algo más que bash para/bin/sh. Le dije que debería estar enojado con los idiotas que etiquetaron erróneamente sus scripts bash como shcripts, pero él no estuvo de acuerdo conmigo. –

+1

No, siempre debe escribir '#!/Usr/bin/env bash'. Bash podría estar instalado en/bin/bash en su máquina, pero eso no es estandarizado ni universal. Si te apegas a '#!/Bin/sh', sin embargo, probablemente estés bien. –

0

yo iría a Bourne Again Shell, como la cáscara de bourne puede ser ligeramente diferente entre las implementaciones de UNIX. Con bash puede estar seguro de que bash es siempre bash.

+0

No diría que las diferentes conchas funcionan de manera diferente. Cualquier caparazón que conozca volverá al comportamiento de la capa bourne si se inicia como 'sh' – soulmerge

+0

. He visto diferentes implementaciones de shell bourne (sh) que se comportan de manera diferente. Quizás este ya no es el caso. – topskip

+2

"Con bash puedes estar seguro de que bash siempre es bash". A menos que sea una versión diferente de Bash. Obviamente hay diferencias significativas entre los números de versión principales, pero también hay algunos entre los números de versión menores. –

1

Portabilidad. Escribo #!/bin/sh a menos que las cosas se pongan realmente dolorosas, y luego escribo #!/bin/bash. El mundo está cambiando muy rápidamente, y estoy apostando a que en el futuro será fácil convencer a los administradores de sistemas para que instalen bash. Pero cubro mis apuestas usando Bourne para la mayoría de las cosas, lo cual es simple.

1

En Mac OS X/bin/sh no es un shell Bourne. (Pero puede obtener un verdadero bournesh en carne fresca).

Para identificar una carcasa Bourne tradicional, puede intentar utilizar la circunfleja^(caret) como sustituto de | (tubo).

Ver:

El tradicional Bourne Shell familia,

http://www.in-ulm.de/~mascheck/bourne/

1

utilizo como mi Bash shell de entrada, pero las secuencias de comandos que elegiría el shell Bourne cualquier día de la semana y dos veces el domingo. Bash tiene mejores características, mejor facilidad de uso y mejores errores.

En realidad, las mismas cosas que me obligan a elegir Bash cuando estoy iniciando sesión, me hacen evitarlo al crear scripts. Bash intenta que todo sea agradable y acogedor para el usuario, pero a expensas de un ejecutable de 776   kB (en mi máquina), en comparación con 140   kB para Bourne shell. ¿Por qué mi script se preocupa por la facilidad de uso? Cualquier ganancia que logre mediante el uso de alguna función inteligente de Bash queda efectivamente anulada por la huella del casco, que es más de cinco veces más grande.

Tengo computadoras que ejecutan Linux, FreeBSD y OS X. Aunque rara vez muevo algo entre las computadoras, es bueno tener la posibilidad. En un script de shell Bourne, simplemente escriba

#!/bin/sh 

y simplemente funciona. Siempre. Bash podría ser común en Linux, pero no está tan estandarizado como el shell Bourne. En FreeBSD, Bash no está instalado por defecto. Se puede instalar desde puertos si el administrador del sistema piensa que es una buena idea pero, incluso así, termina en /usr/local/bin/bash (no en /bin/bash). Por lo tanto, si aún decide usar Bash, debe escribir

#!/usr/bin/env bash 

para hacer que la secuencia de comandos sea portátil. env encontrará la carcasa para usted, independientemente de su sabor de Unix (siempre que esté instalado).

Al final del día, es su elección. Solo asegúrese de que sus scripts sean realmente compatibles con en el shell que elija, y no confíe en que "sh" esté enlazado a "bash" o algo similar.

Cuestiones relacionadas