Atualmente, estou explorando pacotes Debian e tenho lido alguns exemplos de código. E em todas as linhas, por exemplo, o postinstscript é um padrão.
some command || true
another command || truePortanto, se algum comando falhar, a linha retornará verdadeira, mas não vejo como isso afeta a saída do programa.
Respostas:
A razão para esse padrão é que os scripts de mantenedor nos pacotes Debian tendem a começar set -e, o que faz com que o shell saia assim que qualquer comando (estritamente falando, pipeline, lista ou comando composto) sai com um status diferente de zero. Isso garante que os erros não se acumulem: assim que algo der errado, o script é interrompido.
Nos casos em que um comando no script pode falhar, a adição || truegarante que o comando composto resultante sempre saia com status zero, para que o script não seja interrompido. Por exemplo, remover um diretório não deve ser um erro fatal (impedir que um pacote seja removido); então nós usamos
rmdir ... || truepois rmdirnão tem uma opção para dizer para ignorar erros.
set -ea necessidade || true, achei importante fornecer o contexto. Se você notar coisas estranhas no POWER, recomendo fortemente que você arquive bugs ( reportbug)!
set -enão é apenas "convenção Debian", mas um bom padrão de programação que sempre devemos usar. Vejo. por exemplo, davidpashley.com/articles/writing-robust-shell-scripts
|| trueset -e é o contexto provável e provavelmente o mais comum. Eu me curvo a esta resposta! Literalmente, porém, é útil sempre que o status de saída for considerado irrelevante E (como o link do artigo adiciona) Não estou usando o status de saída como parte do meu controle de script. Eu vejo utilidade (in set -e), mas não chegaria tão longe quanto o artigo diz e "Todo script que você escreve deve incluir set -e no topo". É um estilo de programação. "SEMPRE | Todo" inclui seu próprio conjunto de armadilhas - aka - absolutos re: as soluções de curingas vão ALWAYSsair pela culatra, eventualmente, aka - sem carona.
set -ecomportamento. Pode não ser importante para você, se seus únicos alvos são bashe os outros shells relativamente recentes que vivem /bin/sh, mas a situação é mais sutil quando você deseja dar suporte a shells / sistemas antigos.
set -e muito minuciosa documentando os comportamentos de conchas diferentes de Sven Mascheck , embora essa página também documente muitas conchas históricas / antigas irrelevantes hoje em dia. Há também estas duas páginas com um foco mais estreito moderna (procura por "set -e"): página "lintsh" , documentação shell portátil da autoconf -> Limitação de builtins subpage
Embora não afete a saída do programa que acabou de ser executado, ele permite que o chamador continue como se estivesse tudo bem, ou seja, afeta a lógica futura.
Reformulado: mascara o status de erro do comando anterior.
michael@x071:[/usr/sbin]cat /tmp/false.sh
#!/bin/sh
false
michael@x071:[/usr/sbin]cat /tmp/true.sh
#!/bin/sh
false || true
michael@x071:[/usr/sbin]sh /tmp/false.sh; echo $?
1
michael@x071:[/usr/sbin]sh /tmp/true.sh; echo $?
0set -ee a || trueutilidade será definida pelos traços e objetivos de o programador.
git remote remove foo || true git remote add foo http://blah- queremos ignorar o erro se o controle remoto não existir.
||:é outra maneira idiomática de escrever isso (:sendo outra entrada na tabela embutida apontando paratrue- mas garantida que é uma embutida mesmo de volta a Bourne; isto dito, para o POSIX sh,truetambém é garantido que ela é embutida - por isso é mais concisão do que eficiência em tempos até remotamente modernos).