script bash: resultados diferentes quando chamado com ou sem sudo

Todo script começa com um Shebang , sem ele o shell que inicia seu script não sabe qual interpretador deve executar seu script ¹ e pode - como no caso sudo ./script.shdaqui - executá-lo com sh, que no Ubuntu 16.04 está vinculado a dash. A expressão condicional [[ é um bashcomando composto , então dashnão sabe como lidar com isso e gera o erro que você encontrou.

A solução aqui é adicionar

#!/bin/bash

como a primeira linha do seu script. Você pode obter o mesmo resultado ao chamá-lo explicitamente com sudo bash ./script.sh, mas um shebang é o caminho a percorrer.
Para verificar qual shell executa seu script, adicione echo $0a ele. Isso não é o mesmo que echo $SHELL , citando wiki.archlinux.org :

SHELL contém o caminho para o shell preferido do usuário. Observe que esse não é necessariamente o shell que está em execução no momento, embora o Bash defina essa variável na inicialização.

1: Como você começou ./test.shcom bashapenas assumiu bash, o mesmo vale para o sudo susubshell.

Como @dessert explicou , o problema aqui é que seu script não tem uma linha shebang . Sem um shebang, sudoo padrão será tentar executar o arquivo usando /bin/sh. Não consegui encontrar documentado em lugar nenhum, mas confirmei verificando o sudocódigo fonte onde encontrei o seguinte no arquivo pathnames.h:

#ifndef _PATH_BSHELL
#define _PATH_BSHELL "/bin/sh"
#endif /* _PATH_BSHELL */

Isso significa "definir se a variável _PATH_BSHELLnão estiver definida, defina-a como /bin/sh". Então, no configurescript incluído no tarball fonte, temos:

for p in "/bin/bash" "/usr/bin/sh" "/sbin/sh" "/usr/sbin/sh" "/bin/ksh" "/usr/bin/ksh" "/bin/bash" "/usr/bin/bash"; do
    if test -f "$p"; then
    found=yes
    { $as_echo "$as_me:${as_lineno-$LINENO}: result: $p" >&5
$as_echo "$p" >&6; }
    cat >>confdefs.h <<EOF
#define _PATH_BSHELL "$p"
EOF

    break
    fi
done

Este loop procurará /bin/bash, /usr/bin/sh, ou /sbin/she então definirá o que for encontrado primeiro . Como era o primeiro da lista e existe, é definido como . O resultado de tudo isso é que o shell padrão de , a menos que definido de outra forma, seja ./usr/sbin/sh/bin/ksh_PATH_BSHELL/bin/sh_PATH_BSHELL/bin/shsudo/bin/sh

Portanto, sudoo padrão será executar as coisas usando /bin/she, no Ubuntu, um link simbólico para dash, um shell mínimo compatível com POSIX:

$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Feb 27  2015 /bin/sh -> dash

A [[construção é um recurso bash, não é definida pelo padrão POSIX e não é compreendida por dash:

$ bash -c '[[ true ]] && echo yes'
yes
$ dash -c '[[ true ]] && echo yes'
dash: 1: [[: not found

Em detalhes, nas três invocações que você tentou:

1. ./test.sh

   Não sudo; na ausência de uma linha shebang, seu shell tentará executar o próprio arquivo. Como você está executando o bash, isso será executado bash ./test.she funcionará efetivamente.

2. sudo suseguido por ./test.sh.

   Aqui, você está iniciando um novo shell para o usuário root. Este será o shell definido na $SHELLvariável de ambiente para esse usuário e, no Ubuntu, o shell padrão do root é bash:

   $ grep root /etc/passwd
   root:x:0:0:root:/root:/bin/bash
   

3. sudo ./test.sh

   Aqui, você está deixando sudoexecutar o comando diretamente. Como seu shell padrão é /bin/shexplicado acima, isso faz com que ele execute o script com /bin/sh, que é dashe falha, pois dashnão entende [[.

_{Nota : os detalhes de como sudodefine o shell padrão parecem ser um pouco mais complexos. Tentei alterar os arquivos mencionados em minha resposta para apontar, /bin/bashmas sudoainda estava com o padrão /bin/sh. Portanto, deve haver alguns outros locais no código-fonte onde o shell padrão é definido. No entanto, o ponto principal (que sudoé padronizado para sh) ainda permanece.}