9.2. Bash (Bourne-Again Shell)
O Red Hat Enterprise Linux 6 inclui a versão 4.1 do Bash e seu shell padrão. Esta seção descreve os problemas de compatibilidade que esta versão apresenta em relação as outras versões.
- O Bash-4.0 e posteriores agora permitem construções de substituição de processos para passar inalterados através da expansão de controle. Então qualquer expansão dos conteúdos terá de ser especificada separadamente e qualquer substituição de processo terá de ser digitada separadamente.
- O Bash-4.0 e posteriores agora permitem ao SIGCHLD interromper a espera builtin, conforme o Posix determina. Então o trap SIGCHLD não é mais invocado uma vez para cada filho existente se você estiver usando 'wait' para esperar por todos os filhos.
- Já que agora o Bash-4.0 e posteriores seguem as regras Posix para encontrar os delimitadores de encerramento de uma substituição de comando $(), ele não se comportará como nas versões anteriores, mas captará mais erros de sintaxe e análise antes de reproduzir uma subshell para avaliar a substituição de comando.
- O código de acabamento programável usa o mesmo conjunto de caractéres delimitadores como readline quando quebrar as linhas de comando em palavras, em vez do conjunto de meta caractéres do shell, então o acabamento programável e readline devem ser mais consistentes.
- Quando a leitura do builtin expira, ela tenta atribuir qualquer leitura de entrada para varáveis especificas, que também faz as variáveis serem definidas às strings vazias se não há entradas suficientes. Versões anteriores descartavam a leitura de caractéres.
- No Bash-4.0 e posteriores, quando um dos comandos em um pipeline é terminado por um SIGINT enquanto executar uma lista de comandos, o shell age como se recebesse a interrupção.
- O Bash-4.0 e versões posteriores mudam o manuseio da opção
set -epara que o shell saia se um pipeline falhar (e não somente se o último comando no pipeline com falha é um comando simples). Isto não é como o Posix especifica. Há uma tarefa a caminho para atualizar esta porção do padrão; o comportamento do Bash-4.0 tenta capturar o consensus no momento do lançamento. - O Bash-4.0 e posteriores tem o bug Posix corrigido que fazia o builtin
.(source)buscar o diretório atual para o seu argumento de nome de arquivo, mesmo se o"."não está no sistema PATH. O Posix diz que o shell não deve olhar na variável PWD neste caso. - O Bash-4.1 usa o local atual quando comparar as strings usando operadores do comando
[[. Isto pode ser revertido ao comportamento anterior definindo uma das opçõescompatNNshopt.
Expressões Regulares
Além dos pontos já listados, citar o argumento padrão à expressão regular correspondendo ao operador condicional =~ pode fazer a correspondência regexp parar de funcionar. Isto ocorre em todas as arquiteturas. Nas versões do bash anteriores ao 3.2, o efeito de comentar o argumento de expressão regular ao [[ operador =~ do comando não era especificada. O efeito prático era que comentar duas vezes o argumento padrão requeria "" para comentar caractéres especiais, que interferiam com o processamento da barra inversa realizada pela expansão da palavra duas vezes comentada.
Na versão bash 3.2, o shell foi mudado para citar internamente caractéres em argumentos de string únicos e duplicados ao operador =~, que suprime o significado especial dos caractéres que são importantes às expressões regulares processando (`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^', and `$') e os força a serem correspondidos literalmente. Isto é consistente em como o operador de correspondência padrão == trata as porções citadas de seu argumento padrão.
Já que o tratamento dos argumentos de strings citados foi mudado, diversos problemas podem acontecer, o principal deles é o problema de espaço em branco em argumentos padrões e a diferença de tratamento de strings citadas entre o bash 3.1 e o bash 3.2. Ambos os problemas podem ser resolvidos usando uma variável shell em todos os operadores do comando [[, ela fornece a habilidade de citar padrões que você desejar quando atribuir a variável, então expanda os valores a uma única string que pode conter espaços em branco. O primeiro problema pode ser resolvido usando "" ou qualquer outro mecanismo de citação para escapar os espaços em branco nos padrões.
O Bash 4.0 apresenta o conceito de um nível de compatibilidade, controlado por diversas opções ao shopt builtin. Se a opção compat31 estiver ativada, o bash reverterá para o comportamento do 3.1 em relação a citar o lado direito do operador =~.
