Considere shells não-Bash que não possuam as strings here do Bash ( <<<"..."
) ou substituições de processos ( <(...)
), e o fato de algumas pessoas precisarem escrever scripts que exibam um nível de portabilidade entre sistemas. / p>
Aqui, os documentos são usados sempre que um texto pré-formatado de várias linhas precisa ser enviado para um utilitário, possivelmente com ou sem a execução de substituição de variáveis, etc. em seu conteúdo.
Em um script, isso pode ser útil para apresentar ao usuário algum texto, por exemplo:
Para evitar o entediante
echo 'Usage:'
echo " $0 [-a|-b] file [file ...]"
echo
echo 'Options:'
(Veja um exemplo do mundo real de alguém realmente fazendo isso, em um livro, e tente controlar quais strings são avaliadas e quais não são. Isso não passaria na minha revisão de código, com certeza: link )
Em vez disso, pode-se simplesmente alimentar um documento aqui para cat
:
cat <<-END_USAGE
Usage:
$0 [-a|-b] file [file ...]
Options:
END_USAGE
Isto, aliás, também fornece uma oportunidade de fazer uma certa quantidade de documentação do script por escolha inteligente de "tag" do documento aqui ( END_USAGE
, END_FTP
, etc.).
Também é útil para enviar scripts completos para utilitários como ftp
ou outros programas capazes de ler sequências de comandos em suas entradas padrão.
Como um programador Bash, você está obviamente livre para usar a maneira de fazer Bash, mas eu acho que aqui os documentos ainda fornecem uma maneira mais limpa de enviar um documento pré-formatado para um comando do que usar uma longa e desconexa string .
Removendo aqui - os documentos do Bash também tornariam Bash inútil como um candidato para /bin/sh
na maioria dos sistemas Unix, uma vez que seriamente enfraqueceria sua conformidade POSIX.