Gostaria de incluir alguns caracteres não ASCII em meus comentários de script de shell POSIX . Observe que isso não é de forma alguma uma duplicata de, por exemplo, "Quais codificações de caracteres são suportadas pelo posix?" já que me importo apenas com a seção de comentários. Portanto, não me importo se posso usar Unicode para codificação real. Eu me importo se todos os shells compatíveis com POSIX serão capazes de ler meu arquivo ou se alguns falharem devido à codificação não ASCII.
Portanto, meu editor (VS Code) salvará esse arquivo com codificação UTF-8.
Aqui estão dois arquivos identificados com o fileutilitário (não tenho certeza se ele se importa com o BOM):
$ file script1*
script1: POSIX shell script, ASCII text executable
script1.utf: POSIX shell script, Unicode text, UTF-8 text executable
A questão é: se os scripts shell POSIX devem estar apenas em ASCII. Não consigo encontrar nada relevante sobre este tópico. Obrigado.
POSIX especifica como os tokens devem ser reconhecidos , incluindo comentários:
Você está perguntando especificamente sobre o UTF-8; O UTF-8 garante que as novas linhas sejam codificadas conforme esperado em ASCII e que apenas as novas linhas produzam o valor de byte correspondente. Portanto, nenhuma codificação de caracteres UTF-8 não ASCII pode ser mal interpretada como uma nova linha, o que significa que UTF-8 é seguro para uso em comentários em shells compatíveis com POSIX.
Sua pergunta menciona BOMs de passagem; eles não são necessários em UTF-8 e os arquivos que começam com uma BOM não são compatíveis com versões anteriores de ASCII. Um script de shell que começa com uma BOM não é compatível com POSIX e não se comportará conforme o esperado:
O BOM é considerado parte do primeiro token, então o shell procura um comando correspondente a “BOM
echo” e não encontra nenhum.A resposta aceita é boa, mas deixe-me explicar a mesma com um ângulo ligeiramente diferente:
POSIX é muito exato e completo no tratamento de codificações de caracteres. Ou seja, qualquer efeito concebível de codificações de caracteres não triviais é mencionado nas páginas relevantes. Conforme mostrado nesta resposta , basicamente faz um requisito mínimo sobre quais caracteres existem, mas não diz nada realmente limitante sobre a codificação desses caracteres. Ele define o que acontece em certos casos difíceis (por exemplo, codificação inválida em certas circunstâncias; ocorrências do byte NUL especial; a exigência de que uma certa quantidade mínima de caracteres esteja contida no conjunto de caracteres e assim por diante). A parte relevante do padrão é POSIX Character Set .
Observe que, na esmagadora maioria dos lugares, o POSIX fala sobre caracteres e não sobre bytes . Na verdade, se você procurar por "byte" em POSIX Shell Command Language , qualquer menção a "byte" estará sempre no contexto de onde a codificação pode ter dado errado ou onde os limites de RAM estão envolvidos (ou seja, comprimentos máximos de caminho) e assim continuamente, ou o que deve acontecer caso o usuário altere a codificação definindo as variáveis de ambiente relevantes dentro de um shell. Em todas as descrições "normais" (ou seja, de comandos shell), fala sobre caracteres, e apenas caracteres.
Especificamente, o caractere de comentário é definido assim:
Na especificação do conjunto de caracteres vinculada acima, encontramos:
(O
#ou<number-sign>faz parte do Conjunto de Caracteres Portáteis).Este último é interessante. O UTF-8, sobre o qual você está perguntando, contém ASCII de 7 bits como um subconjunto verdadeiro na definição e codificação de caracteres, portanto, a postulação é cumprida. UTF-16 seria difícil neste caso e, portanto (e por muitas outras razões) UTF-16 não é compatível com POSIX .
Para sua pergunta atual: todos os usos bem formados de UTF-8 estão corretos após o comentário. O comentário (sinal numérico) e a nova linha são completamente bem definidos e seguros em UTF-8; não por coincidência, o UTF-8 também garante que os caracteres codificados em mais de um byte não contenham bytes ASCII de 7 bits, portanto, não pode haver um sinal de número involuntário ou caractere de nova linha em uma codificação UTF-8 aleatória .
Todas as coisas que não são fáceis de especificar são especificadas especificamente como "não especificadas" pelo POSIX. Então, o que acontece se o seu script contiver codificações inválidas é, bem, indefinido. Por exemplo, se no final do comentário, antes da nova linha, o último caractere for uma codificação multibyte, e a nova linha vier no meio disso -> não especificado. Espere que erros e todos os tipos de hilaridade aconteçam.
Dito isto, um comando bem comportado não (precisará) se preocupar com esses casos, tratando basicamente tudo como bytes e se preocupando apenas com bytes específicos de 7 bits (ou seja, caracteres de controle).
Ou , se o comando suportar UTF-8, os métodos usuais de recuperação definidos em UTF-8 para detectar e tratar codificações inválidas deverão ser aplicados. Especificamente de acordo com RFC 3629 - UTF-8 :
Mas o POSIX não diz nada sobre isso, no contexto desta questão.
Se você está preocupado com shells realmente compatíveis com POSIX, as respostas acima são adequadas. Mas o Real World™ não é compatível com POSIX. Você encontrará shells que lidam com Latin-1, ou UTF-8, ou outras codificações exóticas sem problemas. E (mais provavelmente em sistemas mais antigos, limitados ou apenas parecidos com Unix) você também encontrará aqueles que se ajustam se a entrada não for estritamente ASCII.
Princípio de Postel: “Seja conservador no que envia, seja liberal no que aceita”. Aqui você é o remetente.