Você pode fazê-los falhar no script:
#!/bin/bash
: "${2:?} ${1:?}"
#If either one of the above is unset or null the
#script will have already exited with a meaningful
#diagnstic message written to standard error.
O shell sai com erro e a mensagem é gerada automaticamente: exatamente o que ele diz ser dependente do shell, mas geralmente é assim:
(set --; ${1:?})
sh: 2: 1: parameter not set or null
... onde first_colon_delimited_field: é $0
, o próximo é $LINENO
; seguido por var_name e, finalmente, mensagem de diagnóstico. Você provavelmente já viu mensagens semelhantes no passado.
Você pode obter informações específicas sobre a mensagem de diagnóstico:
(set --; ${1:?Hi there!})
sh: 3: 1: Hi there!
Além disso, é um teste in-line implícito. Se os parâmetros alvo forem definidos e não nulos (ou possivelmente nulos se você eliminar o :
dois pontos da :?
da sintaxe de expansão do parâmetro) , eles expandirão normalmente:
(set param; echo "${1:?This better not be empty!}")
param
E isso, como outras formas de modificar expansões de parâmetros , pode ser aplicado a outros tipos de parâmetros além dos seus posicionamentos:
param= bash -c '
printf "Sure hope this works...\n" "${param:?Not a chance!}"
echo ... but what about me\?
' newzero
echo "RETURN: $?"
... que imprime no meu terminal ...
newzero: line 1: param: Not a chance!
RETURN: 127
A mensagem de diagnóstico opcional é em si uma expansão - o que quer que seja expandido é o que o shell irá gravar no stderr. Eu quase sempre o uso para a mensagem --help
quando adiciono análise de opção a um script. Eu apenas faço uma pequena função e passo o parâmetro numerado que eu esperava quando encontrei um problema:
#script and more script
help(){ eval "\${$param:?\$(cat)}"; } <<HELP
Usage [ and the usual ... ]
HELP
while getopts ....
do case $opt in ($myopts) :;;
(*) param=$OPTIND help;;esac
done