Substituição incorreta: sem fechamento “'” em um heredoc / EOF

Question

Gostaria de imprimir uma mensagem de uso de estilo man para descrever uma função de shell como esta saída man find :

NAME
       find - search for files in a directory hierarchy

SYNOPSIS
       find [-H] [-L] [-P] [-D debugopts] [-Olevel] [starting-point...] [expression]

DESCRIPTION
       This  manual  page  documents the GNU version of find.  GNU find searches the directory tree rooted at each
       given starting-point by evaluating the given expression from left to  right,  according  to  the  rules  of
       precedence  (see section OPERATORS), until the outcome is known (the left hand side is false for and opera‐
       tions, true for or), at which point find moves on to the next file name.  If no  starting-point  is  speci‐
       fied, '.' is assumed.

OPTIONS

Estou enfrentando uma mensagem de erro no caractere '.
O script simples a seguir mostra o erro:

~$ cat <<EOF
'.'
EOF

bash: bad substitution: no closing "'" in '.'

Eu pensei que heredoc era uma maneira legal de fazer eco de strings colando-as sem ter que escapar do conteúdo, como citações, etc. Eu suponho que eu estava errado: /

Alguém pode explicar esse comportamento, por favor? Pode heredoc aceitar 'caractere?

Editar 2 : Aceitei a resposta do citado here-document <<'END_HELP' , mas finalmente não vou usá-lo para esse tipo de saída manual completa como < um href="https://unix.stackexchange.com/users/116858/kusalananda"> kusalananda faz sugere

Editar 1 : (para leituras futuras) é o limite de usar entre aqui-documento que impede o uso de tput em o here-document .
Para fazer isso, fiz o seguinte:

1. sem coeficiente here-document , para que os comandos tput sejam executados
2. impede o erro de "substituição ruim" ao escapar do backtick
3. use tput dentro do here-document

Exemplo:

normal=$( tput sgr0 ) ;
bold=$(tput bold) ;

cat <<END_HELP # here-document not quoted
${bold}NAME${normal}
       find - search for files in a directory hierarchy

${bold}SYNOPSIS${normal}
       find [-H] [-L] [-P] [-D debugopts] [-Olevel] [starting-point...] [expression]

${bold}DESCRIPTION${normal}
       This  manual  page  documents the GNU version of find.  GNU find searches the directory tree rooted at each
       given starting-point by evaluating the given expression from left to  right,  according  to  the  rules  of
       precedence  (see section OPERATORS), until the outcome is known (the left hand side is false for and opera‐
       tions, true for or), at which point find moves on to the next file name.  If no  starting-point  is  speci‐
       fied, \'.' is assumed.
END_HELP

unset normal ;
unset bold ;

Aqui, observe o backtick de escape que era a fonte do erro:

\'.'

    

Answer 1

O backtick introduz uma substituição de comando. Como o documento here não é citado, isso será interpretado pelo shell. O shell reclama, já que a substituição do comando não tem um final backtick.

Para citar um documento aqui, use

cat <<'END_HELP'
something something help
END_HELP

ou

cat <<\END_HELP
something something help
END_HELP

Em relação aos seus comentários sobre a resolução deste problema:

Os utilitários raramente produzem um manual completo sozinhos, mas podem oferecer uma sinopse ou informações básicas de uso. Isso raramente, ou nunca, é colorido (já que sua saída pode não ser direcionada para um terminal ou pager como less ). O manual real é muitas vezes tipografado usando groff ou um formatador dedicado de páginas do manual como mandoc e é tratado completamente separado do código .

    

Answer 2

Você deseja usar especificamente um acento grave / backtick com a aspas simples / apóstrofo para citar alguma coisa? Por favor, não, a combinação parece horrível. Na maioria das fontes, o backtick é inclinado e o apóstrofo (ASCII) é reto. É assim que meu navegador mostra a última linha do seu snippet man page:

SevocêquiserusaraspasquesãomaissofisticadasdoqueasaspasASCIIverticais,provavelmentevocêdeveusaralgocomo U + 2018 e U + 2019 .

A saída, é claro, dependerá das suas fontes, mas acho que "isso" parece melhor do que "isso".