Sair do status de fc -e é o caminho errado

3

Estou tentando editar e recuperar um comando anterior com o comando fc interno do Bash, mas de alguma forma o status de saída indica falha na edição bem-sucedida, mesmo que seja um no-op. Demonstração:

$ uname
Linux
$ fc -e vi
:q
uname
Linux
$ echo $?
1
$ # Would have expected 0 here: successful re-invocation

De man bash :

   fc [-e ename] [-lnr] [first] [last]
   fc -s [pat=rep] [cmd]
          [...]
          If  the  first  form  is  used,  the return value is 0 unless an
          invalid option is encountered or first or last  specify  history
          lines  out  of  range.  If the -e option is supplied, the return
          value is the value of the last command executed or failure if an
          error occurs with the temporary file of commands.  [...]

Aprofundando ainda mais:

$ uname
Linux
$ fc -e true -1  # No-op editor, should succeed.
uname
Linux
$ echo $?
1
$ # Why does this recall, but fail?
$ fc -e false -1 # Editor fails, no command invocation and failure, fine.
$ echo $?
1
$ fc -e rm -1    # This removes the temporary file, should fail, too!?
$ echo $?
0
$ # But actually this is the only branch that causes fc to succeed?!

Para mim, o status de saída de fc está confuso: A edição bem-sucedida (ou não operacional) deve resultar em sucesso (ou o status de saída do comando chamado) e a remoção do arquivo temporário deve ser indicada por falha, não o contrário .

Eu vejo isso no Bash 4.3.11 (1) - lançamento no Ubuntu 14.04.4 LTS, no Bash 4.3.42 (1) - lançamento no Ubuntu 16.04 LTS, e no Bash 4.2.46 (1) - lançamento no CentOS 7. Isso é um bug?

    
por Ingo Karkat 29.06.2016 / 14:14

1 resposta

1

Sim, isso é um bug. Ele já foi relatado e corrigido em novembro de 2015: link

Eu não notei a correção dentro do repositório Git porque eu só olhei em master . Aparentemente, o desenvolvimento ocorre em devel ; a correção atualmente só está lá. Eu atualizarei esta resposta assim que ela chegar em uma versão do Bash.

    
por 05.07.2016 / 17:06