9.2. Bash (Bourne-Again Shell)
Red Hat Enterprise Linux 6 incluye la versión 4.1 de Bash como el shell predeterminado. Esta sección describe los aspectos de compatibilidad que se han introducido en esta versión respecto a versiones anteriores.
- Ahora bash-4.0 y versiones posteriores permiten pasar construcciones de sustitución de procesos sin cambios a través de cualquier expansión de llaves, por lo que cualquier ampliación del contenido deberá especificarse independientemente, y cada sustitución de procesos se deberá ingresar por separado.
- Bash-4.0 y posteriores, permiten que SIGCHLD interrumpa la incorporación de espera, como especifica Posix, por lo tanto la trampa SIGCHLD ya no siempre se invoca una vez por hijo mediante `wait' para esperar a todos los hijos.
- Como Bash-4.0 y posteriores ahora siguen las reglas de Posix para hallar el delimitador de cerramiento de una sustitución de comando $(), no se comportará como las versiones anteriores, sino que capturará más sintaxis y errores de lectura antes de generar una subshell para evaluar la sustitución de comandos.
- El código de finalización programable utiliza el mismo set de caracteres delimitantes que readline para dividir la línea de comandos en palabras, en lugar del set de metacaracteres de shell, por lo tanto, la finalización programable y readline deberían ser más consistentes.
- Cuando se agota el tiempo de lectura incorporada, intentará asignar cualquier entrada de lectura a variables específicadas, lo cual también hace que las variables se establezcan para la cadena vacía si no hay suficiente entrada.
- En Bash-4.0 y posteriores, cuando uno de los comandos en una tubería es asesinado por un SIGINT mientras ejecuta la lista de comandos, el shell actúa como si hubiera recibido la interrupción.
- Bash-4.0 y versiones posteriores cambian el manejo de la opción
set -epara que el shell salga si una tubería falla (y no sólo si el último comando en la tubería que está fallando es un comando simple). Esto no es como especifica Posix. Hay un trabajo en curso para actualizar esta porción del estándar, la conducta de Bash-4.0 intenta capturar el consenso en el momento del lanzamiento. - Bash-4.0 y posteriores corrigen un error en modo Posix que hacía que
. (source)integrado buscara el directorio actual por el argumento de nombre de archivos, incluso si"."no estaba en la RUTA del sistema. Posix dice que el shell no debe buscar en la variable PWD en este caso. - Bash-4.1 utiliza la configuración regional actual al comparar cadenas mediante operadores para el comando
[[. Así revertir la conducta anterior al establecer una de las opcionescompatNNshopt.
Expresiones regulares
Además de los puntos ya mencionados, citar el argumento de patrón para el operador condicional de coincidencia de expresión regular =~ puede hacer que la coincidencia de regexp deje de funcionar. Esto ocurre en todas las arquitecturas. En versiones de bash anteriores a 3.2, el efecto de citar el argumento de expresión regular para el operador =~ del comando[[ no se especificaba. El efecto práctico era que poner entre comillas dobles las barras invertidas requeridas del argumento de patrón para citar caracteres de patrones especiales que interfirían con el procesamiento de barras invertidas realizado por la expansión de palabras entre comillas dobles, era incompatible con la forma en la que el operador de coincidencia de patrones de shell == trataba los caracteres entre comillas.
En la versión bash 3.2, el shell cambiaba a caracteres entre comillas en argumentos de cadena entre comillas dobles y sencillas al operador =~, el cual suprimía el significado especial de los caracteres importantes para el procesamiento de la expresiones regulares (`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^' y `$') y los obliga a coincidir literalmente. Esto es consistente con la forma como el operador de coincidencia de patrones == trata las porciones entre comillas de su argumento de patrones.
Dado que el tratamiento de los argumentos de cadena entre comillas fue cambiado, varias cuestiones han surgido, entre ellas el problema del espacio en blanco en argumentos de patrón y el tratamiento diferente de cadenas entre comillas entre bash 3.1 y bash 3.2. Ambos problemas pueden resolverse mediante el uso de una variable de shell para mantener el patrón. Puesto que no se realiza la división de palabras al expandir las variables de shell en todos los operandos del comando [[, se pueden citar los patrones como se desee al asignar la variable y, luego, expandir los valores a una sola cadena que puede contener espacios en blanco. El primer problema puede resolverse utilizando barras invertidas o cualquier otro mecanismo de comillas para escapar el espacio en blanco en los patrones.
Bash 4.0 introduce el concepto de nivel de compatibilidad, controlado por varias opciones al shopt integrado. Si la opción compat31 está habilitada, bash revertirá a la conducta 3.1 con respecto a colocar comillas a mano derecha del operador =~.
