Eu tenho o seguinte script bash:
#!/bin/bash
encl0=( 0,0 0,1 0,2 0,3 0,4 0,5 0,7 0,8 0,9 0,10 0,11 0,12 0,13 0,14 0,15 )
MISSING_DISKS=()
OLDIFS=$IFS
IFS=$'\n'
MISSING_DISKS+=($({ printf '0 %s\n' {0..15}; printf '0 %s\n' "${encl0[@]#0,}"; } | sort | uniq -u))
IFS=$OLDIFS
echo "$({ printf '0 %s\n' {0..15}; printf '0 %s\n' "${encl0[@]#0,}"; } | sort | uniq -u)"
echo "${MISSING_DISKS[@]}"
if ((${#MISSING_DISKS[@]}>1)); then
echo "Greater than 1"
else
echo "Success"
fi
Quando o executo com o bash v4.4, funciona como esperado:
$ /usr/local/bin/bash test.sh
0 6
0 6
Success
No entanto, quando eu o executo com o bash v3.2, ele não:
$ /bin/bash test.sh
0 6
0 0 0 0 1 2 3 4 5 7 8 9 10 11 12 13 14 15 0 1 0 10 0 11 0 12 0 13 0 14 0 15 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9
Greater than 1
Não entendo como MISSING_DISKS
está sendo definido para algo diferente da saída do comando que o está configurando. Alguém sabe o que está causando isso?
Brincar com espaços, tabulações ou novas linhas está sempre perto do fracasso.
O problema central ocorre aqui:
Se executado no bash 3.2:
A expansão de
"${encl0[@]#0,}"
é processada como uma string, não uma lista de valores.O problema não se manifesta se o IFS tiver um espaço ou se a expansão não editar cada valor do array:
Executado:
Ou:
Executado:
O problema está oculto em seu script porque você restaura o IFS
IFS=$OLDIFS
antes da linha de eco de teste.Uma maneira de evitar o problema é não usar um espaço no printf:
A outra alternativa é evitar a expansão com substituição após alterar o IFS para uma nova linha usando um array alternativo:
Eu te recomendo que:
+=
uma matriz que esteja vazia nesse ponto do códigoMISSING_DISKS+=
.Se essas alterações forem feitas, o script se tornará: