Por que o bash trata as linhas de comando iniciando com pontos especialmente? [duplicado]

Question

Eu tentei pesquisar on-line por uma resposta, mas a resposta (se existir) é ofuscada por outros aplicativos de ponto em scripts de shell. Então aqui vai.

EDIT: Acontece que está relacionado à configuração padrão do Fedora de command_not_found_handle , então não está relacionado ao código-fonte bash. / EDIT

Eu descobri que enquanto o bash geralmente reclama de falta de comando, ou mesmo que tudo que eu insiro como linha de comando é um diretório:

[root@localhost tmp] # mkdir test
[root@localhost tmp] # test
[root@localhost tmp] # nonexistent
bash: nonexistent: command not found...
[root@localhost tmp] # test
[root@localhost tmp] # cd test
[root@localhost test] # empty
bash: empty: command not found...
[root@localhost test] # .
bash: .: filename argument required
.: usage: . filename [arguments]
[root@localhost test] # ..

Os itens acima são claramente válidos e esperados. Mas estes:

[root@localhost test] # ....
[root@localhost test] # .........................
[root@localhost test] # .whatever
[root@localhost test] # ..........whatever
[root@localhost test] # ......œę©æąðæćþóœ
[root@localhost test] # .ignored
[root@localhost test] # touch .whatever
[root@localhost test] # .whatever
[root@localhost test] # file .whatever 
.whatever: empty
[root@localhost test] # file .ignored
.ignored: cannot open '.ignored' (No such file or directory)
[root@localhost test] # .ignored
[root@localhost test] # .whatever follows is just discarded
[root@localhost test] # 

estão silenciosamente ignorando o que quer que eu escreva.

E isso não é o que se esperaria. Existe uma razão para esse comportamento?

EDIT: Eu encontrei um caso de uso!

[root@localhost ~] # ...|cat
[root@localhost ~] # ...|nonexistent
bash: nonexistent: command not found...
[root@localhost ~] # ...|nonexistent && echo works
bash: nonexistent: command not found...
[root@localhost ~] # ...|nonexistent || echo works
bash: nonexistent: command not found...
works
[root@localhost ~] # ...|cat && echo works
works
[root@localhost ~] # ...|cat || echo works
[root@localhost ~] # 

Aparentemente, ele permite verificar se um executável está em PATH sem tentar executá-lo - você pode ver que o cat não foi bloqueado. Nunca foi executado.

Isso é meio ridículo. Divirta-se!

[root@localhost ~] # LANG=en bash --version
GNU bash, version 4.3.42(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

EDIT2:

[root@localhost ~] # declare -f command_not_found_handle
command_not_found_handle () 
{ 
local runcnf=1;
local retval=127;
[[ $- =~ i ]] || runcnf=0;
[[ ! -S /var/run/dbus/system_bus_socket ]] && runcnf=0;
[[ ! -x '/usr/libexec/packagekitd' ]] && runcnf=0;
[[ -n ${COMP_CWORD-} ]] && runcnf=0;
if [ $runcnf -eq 1 ]; then
    '/usr/libexec/pk-command-not-found' "$@";
    retval=$?;
else
    if [[ -n "${BASH_VERSION-}" ]]; then
        printf 'bash: %scommand not found\n' "${1:+$1: }" 1>&2;
    fi;
fi;
return $retval
}

    

Answer 1

Acontece comportamento inesperado devido à implementação padrão do Fedora de command_not_found_handle . Obrigado @TNW por me lembrar de sua existência.

Após unset command_not_found_handle , funciona como esperado.

Não sei se é um bug ou uma limitação.