Harold Fischer's questions

Dado um arquivo, quero fazer uma lista de todos os bytes que ele contém em formato octal, cada byte em sua própria linha.

Por que isso funciona:

#!/bin/sh --

newline='
'

od -v -A n -t o1 -- /tmp/file | \
sed -e "s/ /\\${newline}/g" | \
sed -e '/^$/d'

e não isso:

#!/bin/sh --

newline='
'

od -v -A n -t o1 -- /tmp/file | \
sed -e "s/ /\\${newline}/g" -e '/^$/d'

Por que eu tenho que ligar para o sed duas vezes separadas para fazer o trabalho?

Para referência, a saída de od, sem processamento adicional, pode ser algo como o seguinte:

         047 124 167 141 163 040 142 162 151 154 154 151 147 054 040 141
         156 144 040 164 150 145 040 163 154 151 164 150 171 040 164 157
         166 145 163 012 011 104 151 144 040 147 171 162 145 040 141 156
         144 040 147 151 155 142 154 145 040 151 156 040 164 150 145 040
         167 141 142 145 072 012 101 154 154 040 155 151 155 163 171 040
         167 145 162 145 040 164 150 145 040 142 157 162 157 147 157 166
         145 163 054 012 011 101 156 144 040 164 150 145 040 155 157 155
         145 040 162 141 164 150 163 040 157 165 164 147 162 141 142 145
         056 012

Eu quero comparar dois números com bc. De acordo com esta resposta altamente cotada no StackOverflow , posso fazê-lo da seguinte maneira:

printf '%s\n' '1.2 > 0.4' | bc

bcenvia 1para STDOUT, indicando que a declaração é verdadeira (teria retornado 0 se a declaração fosse falsa).

De acordo com a página POSIX parabc :

Ao contrário de todos os outros operadores, os operadores relacionais ( '<', '>', "<=", ">=", "==", "!=" ) devem ser válidos apenas como objeto de um if, while, ou dentro de uma instrução for.

Talvez eu esteja interpretando mal, mas essa linguagem parece não permitir a sintaxe usada no exemplo acima.

O uso autônomo de operadores relacionais é bcuma violação do POSIX? Se sim, como devo reescrever meu exemplo?

Ao lidar com expansões de parâmetros aninhados, qual dessas é a maneira correta de citar as coisas?

Este:

var="${var#"${var%%[![:space:]]*}"}"

Ou este:

var="${var#${var%%[![:space:]]*}}"

Eu vi isso feito nos dois sentidos. A primeira variação é um trecho de uma resposta do Stack Overflow . É uma das respostas mais votadas para a pergunta (a pergunta é sobre como cortar o espaço em branco de uma variável).

Também estou tendo problemas para encontrar uma fonte respeitável que aborda como citar coisas ao trabalhar com uma "palavra" ou "padrão" que é uma variável em vez de texto literal. Dos dois abaixo, qual está correto?

Este:

strip_ext="${filename%."$filename_ext"}"

Ou este:

strip_ext="${filename%.$filename_ext}"

#!/bin/bash --

echo "$$"

LC_ALL=C sed 's/[!-~]/b/g' /tmp/bigfile > /tmp/outfile

echo end of script

Se eu enviar o QUITsinal usando Ctrl + \recebo esta saída:

# ./script.sh
6739
^\./script.sh: line 5:  6740 Quit                    LC_ALL=C sed 's/[!-~]/b/g' /tmp/bigfile > /tmp/outfile
end of script

Isso mata sede causa um dump de núcleo conforme o esperado, mas o script continua. Este é o comportamento esperado? Isso acontece comigo com bashe ashmas não não dashou ksh93.

Isto é o que estou usando agora para fazer o trabalho:

#!/bin/sh --

string='Aa1!z'

if ! printf '%s\n' "$string" | LC_ALL=C grep -q '[[:upper:]]' || \
   ! printf '%s\n' "$string" | LC_ALL=C grep -q '[[:lower:]]' || \
   ! printf '%s\n' "$string" | LC_ALL=C grep -q '[[:digit:]]' || \
   ! printf '%s\n' "$string" | LC_ALL=C grep -q '[[:punct:]]'; then
  printf '%s\n' 'String does not meet your requirements'
else
  printf '%s\n' 'String meets your requirements'
fi

Isso é extremamente ineficiente e verboso. Existe uma maneira melhor de fazer isso?

Quando eu corro

user@hostname:~$ su -- root -z

eu recebo

bash: -z: invalid option
Usage:  bash [GNU long option] [option] ...
...

O acima é o comportamento que eu espero.

Quando eu corro

user@hostname:~$ su -l -- root -z

eu recebo

-su: -z: invalid option
Usage:  -su [GNU long option] [option] ...
...

Eu uso a opção inválida -zapenas para demonstrar qual comando está analisando a opção.

Esse comportamento me irrita sem fim. sucontinuei procurando opções depois que declarei fim das opções. Estou faltando alguma coisa, isso é um bug ou apenas um design horrível?

#!/bin/sh --

for set_trap_sig in HUP INT QUIT ALRM TERM; do
    trap -- '
        trap -- - '"${set_trap_sig:?}"' EXIT || exit "$?"
        kill -s '"${set_trap_sig:?}"' -- "$$" || exit "$?"' "$set_trap_sig"
done

sleep 15 || exit "$?"

Aqui está o que acontece quando eu envio SIGINT para o script

user@hostname:/tmp$ ./script.sh
^C./script.sh: 3: ./script.sh: Syntax error: EOF in backquote substitution

Este problema parece específico para dash. No ash, bash e ksh93, não recebo esse erro. Isso é particularmente estranho porque meu script nem contém o caractere backquote.

Se eu remover as aspas duplas no final $?da linha 5, o erro desaparece.

Estou fazendo algo estúpido ou o Dash está sendo retardado? E sim, eu sei que escrevo roteiros como um esquizofrênico paranóico.

Edit: estabelecemos um bug muito sério que afeta até as versões modernas do Ubuntu e do Debian. Alguém sabe de uma solução alternativa?

Quero esclarecer que não estou falando sobre como escapar caracteres no nível de interpretação do shell.

Tanto quanto eu posso dizer, apenas dois caracteres precisam ser escapados: %e\

Para imprimir um literal %, você deve escapá-lo com um precedente %:

printf '%%'

Para imprimir um literal \, você deve escapá-lo com um precedente \:

printf '\\'

Existem outras instâncias em que eu precisaria escapar de um caractere para que ele fosse interpretado literalmente?

De acordo com a página de linguagem de comando POSIX Shell :

\

O <backslash>deve manter seu significado especial como um caractere de escape (consulte Caractere de escape (barra invertida)) somente quando seguido por um dos seguintes caracteres quando considerado especial :

$ ` " \ <newline>

Eu interpreto isso como significando que \só deve escapar um desses cinco caracteres especiais se for especial em seu determinado contexto.

As páginas man para ash, dash, bash e ksh não contêm a cláusula "quando consideradas especiais". Eu entendo que isso significa (e confirmei através de experimentação básica) que \tem o efeito de escapar desses cinco caracteres incondicionalmente, mesmo quando um desses cinco caracteres não é especial em seu contexto.

Considere a saída de $ printf '%s\n' "\abcde", que é \abcde. Isso é esperado porque anão é especial neste contexto (ou em qualquer contexto para esse assunto); portanto, o \não é especial e é tratado literalmente.

Agora considere a saída de $ printf '%s\n' "\\abcde", que é \abcde. Este não é o comportamento que eu espero. Na minha opinião, a primeira barra invertida na string \\abcdetambém deve ser tratada literalmente, porque é seguida por \um contexto em que \não é especial. A saída que eu esperaria é \\abcde.

Outro cenário em que vejo um comportamento inesperado está na saída de $ printf '%s\n' "ab\$", que é ab$. Na minha opinião, $tem um significado especial neste contexto porque serve para introduzir expansão de parâmetros, substituição de comandos ou expansão aritmética. Portanto, na minha opinião, o \deve ser tratado literalmente porque é seguido por $um contexto onde $não é especial. A saída que eu esperaria é ab\$.

Para que conste, espero estar totalmente fora da base aqui. Torna minha vida muito mais difícil ter que me preocupar em escapar desses cinco personagens apenas em certas circunstâncias. Eu me esforço para ser posixly correto sempre que possível, e não quero depender de \escapar desses cinco caracteres especiais incondicionalmente se esse comportamento (pessoalmente desejado) em shells compatíveis com POSIX não estiver alinhado com POSIX.

Na página Shell Command Language da especificação POSIX:

Se a primeira linha de um arquivo de comandos shell começar com os caracteres "#!", os resultados não serão especificados.

Por que o comportamento de #!não especificado pelo POSIX? Acho desconcertante que algo tão portátil e amplamente usado tenha um comportamento não especificado.

Conteúdo do arquivo.txt (sem estranheza, arquivo de texto conforme definido pelo POSIX)

iguana
gecko
anole

Exemplo de roteiro:

#!/bin/sh

string="$(cat file.txt)"

printf '%s' "$string"

Exemplo de saída:

[coolguy@somemachine ~]$ ./script.sh
iguana
gecko
anole[coolguy@somemachine ~]$

O que aconteceu com a última nova linha? Por que todas as novas linhas, exceto a última, são preservadas? Parece que não deveríamos ter que usar echo para adicionar uma nova linha se já deveria haver uma lá.

O POSIX define um arquivo de texto como:

Um arquivo que contém caracteres organizados em zero ou mais linhas. As linhas não contêm caracteres NUL e nenhuma pode exceder {LINE_MAX} bytes de comprimento, incluindo o caractere <nova linha>. Embora o POSIX.1-2017 não faça distinção entre arquivos de texto e arquivos binários (consulte o padrão ISO C), muitos utilitários produzem apenas uma saída previsível ou significativa ao operar em arquivos de texto. Os utilitários padrão que possuem tais restrições sempre especificam "arquivos de texto" em suas seções STDIN ou INPUT FILES.

Fonte: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403

No entanto, há várias coisas que não acho claras:

1. Um arquivo de texto deve ser um arquivo normal? No trecho acima, não diz explicitamente que o arquivo deve ser um arquivo regular

2. Um arquivo pode ser considerado um arquivo de texto se contiver um caractere e apenas um caractere (ou seja, um único caractere que não termine com uma nova linha)? Sei que essa pergunta pode parecer complicada, mas eles usam a palavra "caracteres" em vez de "um ou mais caracteres". Outros podem discordar, mas se eles querem dizer "um ou mais personagens", acho que deveriam dizer isso explicitamente

3. No trecho acima, faz referência a "linhas". Encontrei quatro definições com linha em seu nome: "Linha Vazia", ​​"Linha de Exibição", "Linha Incompleta" e "Linha". Devo inferir que eles significam "Linha" por causa da omissão de "Vazio", "Exibir" e "Incompleto" - ou todas as quatro dessas definições são consideradas uma linha no trecho acima?

Todas as perguntas que vêm após este bloco de texto dependem da inferência de que "caracteres" significa "um ou mais caracteres":

4. Posso inferir com segurança que, se um arquivo estiver vazio, não é um arquivo de texto porque não contém um ou mais caracteres?

Todas as perguntas que vêm após este bloco de texto dependem da inferência de que no trecho acima, uma linha é definida como "Linha", e que as outras três definições que contêm "Linha" em seu nome devem ser excluídas:

5. O "zero" em "zero ou mais linhas" significa que um arquivo ainda pode ser considerado um arquivo de texto se contiver um ou mais caracteres que não sejam terminados com nova linha?

6. "Zero ou mais linhas" significa que uma vez que uma única "Linha" (0 ​​ou mais caracteres mais uma nova linha de terminação) entra em jogo, torna-se ilegal que a última linha seja uma "Linha incompleta" (uma ou mais linhas não caracteres de nova linha no final de um arquivo)?

7. "Nenhum [nenhuma linha] pode exceder {LINE_MAX} bytes de comprimento, incluindo o caractere de nova linha" significa que há uma limitação para o número de caracteres permitidos em qualquer "Linha" em um arquivo de texto (como um aparte, o valor de LINE_MAX no Ubuntu 18.04 e FreeBSD 11.1 é "2048")?

Nunca percebi que você poderia fazer isso até agora:

: >> file

Parece ser funcionalmente semelhante a:

touch file

Existe uma razão pela qual a maioria dos recursos parece preferir tocar esse shell integrado?