Por que as sequências de escape ASCII para ' são tratadas de forma diferente em grep/sed/awk?

\1, \2, \3, \4... são usados ​​para referências anteriores em expressões regulares básicas (BRE do final dos anos 60, como encontrado em ed, grep, sed...).

Expressões regulares estendidas introduzidas egrepno final dos anos 70 com um novo algoritmo de expressão regular não tinham (e não poderiam ter com esse algoritmo) suporte de referência anterior.

awkcontemporâneo a egrep, com uma linguagem moldada a partir daquela Cusada em EREs desde o início, tinha literais de string semelhantes a C, dentro dos quais você podia ter \47escapes octais (como em C), e não havia nada que impedisse que esses escapes também fossem adicionados nos /ERE/literais de expressão regular, já que EREs não podiam ter referências posteriores.

Fora de awk, nem POSIX BRE nem ERE suportam esses escapes. Only \né especificado para sed(como era historicamente suportado pelo original sed).

\47como uma sequência de escape para o byte 0x27 definitivamente não pode ser adicionada a BREs, pois entraria em conflito com referências anteriores. Como muitas implementações ERE adicionaram suporte para referências anteriores desde o final dos anos 70, adicioná-lo ao ERE também não é mais uma opção. É uma chatice que a maioria awknão suporta referências anteriores e, naqueles que suportam, como o busybox, você tem que fazer awk '$0 ~ "^(.*)\\1$"'for o equivalente a grep -x '\(.*\)\1'(not awk '/^(.*)\1$/'as that \1is ^Ainstead and awk '/^(.*)\\1$/'is para corresponder a algo que termina em \1).

Observe que a sintaxe em todas as ferramentas, exceto echopara aquelas sequências octais (inicialmente possivelmente de C), é \seguida por 1 a 3 números octais, não há necessidade de um 0 inicial 0e você não pode ter um 0 inicial para números de bytes acima de 63 (077). ( \0377em qualquer coisa, exceto echoé \037( ^_) seguido por 7), então enquanto \047não entra em conflito com referências anteriores, pois \0não é uma referência posterior válida (pelo menos no POSIX BRE, há alguns onde \0significa a correspondência completa), \377entraria.

O \xHHé do C89 (ANSI C), também encontrado em perl desde perl 4 (em seus literais de string e literais regexp lá). Ele não tem aquele problema de conflito com referências posteriores, mas não é suportado por todos os mecanismos regexp ainda³. Em C, \xpode ser seguido por qualquer número de dígitos hexadecimais, já que chars em ANSI C não precisa ser de 8 bits. Em perl, apenas até 2 dígitos são aceitos, embora \x{HH}possa ser estendido para \x{20AC}¹ quando no modo Unicode também é suportado. Em outros lugares, quantos dígitos hexadecimais podem ser consumidos depois \xvaria com o aplicativo. Por exemplo, em ksh93, $'\x20AC'não é byte 0x20(espaço em ASCII) seguido por AC, mas o caractere U+20AC ( €), codificado em UTF-8².

Os operadores de citação de shell $'\47'e $'\x27'do ksh93 agora estão no POSIXsh desde a edição de 2024 do padrão ( shainda não em todas as implementações; em particular, não dashcomo encontrados na maioria dos sistemas baseados em Debian).

em qualquer caso, como o do awk "\47"(ou $'\x27'⁴ ), que se expande para o byte 0x27, portanto, apenas em 'sistemas que usam ASCII como conjunto de caracteres base, então é esse que eu evito usar, pois não vejo sentido em introduzir uma dependência em uma codificação de caracteres específica.

O $'\u0027'(or $'\u27'or $'\U00000027') do zsh que se expande para o 'caractere quase chegou ao POSIX 2024 shtambém, mas como houve algumas divergências e diferenças entre os shells quanto ao conjunto de caracteres para o qual eles deveriam se expandir (UTF-8 incondicionalmente à la ksh93, o charmap do local no momento em que o código é lido à la bash, o charmap do local no momento em que ele é executado à la zsh) e o que fazer quando o charmap não tem o caractere correspondente, sua inclusão foi adiada para a próxima versão principal.

Em qualquer caso 'específico, não há necessidade de especificar o código do ponto, pois ele \'pode ser usado $'...'para representar uma aspa simples.

Com esses \OOOe \xHHagora adicionados ao sh, há ainda menos motivos para que cada ferramenta individual adicione suporte a eles.

Minha maneira preferida de incorporar 'dentro de um argumento de código entre aspas simples sed, awk, perl, shou qualquer argumento entre aspas simples para qualquer comando, para esse caso, em shells do tipo POSIX, é inseri-lo \'fora das aspas simples:

sh -c 'echo "It'\''s not pretty, but it works"'
awk 'BEGIN{print "It'\''s not pretty, but it works"}'

Com awk, você pode fazer:

awk -v q="'" 'BEGIN{print "It" q "s not really prettier"}'

Em rcouzsh -o rcquotes

awk 'BEGIN{print "It''s slightly prettier"}'

Em fish, você pode fazer:

awk 'BEGIN{print "It\'s slightly prettier"}'

Mas isso significa que '...'não há citações totalmente fortes lá, então, como no caso do ksh93 $'...', você tem que ficar atento ao \interior, o que é um problema.

Outra opção é fazer:

awk_code=$(cat << 'EOF'
BEGIN {print "It's much more legible albeit a bit longer"}
EOF
)
awk "$awk_code"

^{¹ \x{7fffffffffffffff}Indo muito além do intervalo Unicode, estendendo o algoritmo de codificação UTF-8.}

^{² enquanto $'\xe9'expande para o byte 0xe9, não para a codificação UTF-8 de U+00E9 ( é). Isso corresponde ao comportamento do perl neste modo não-Unicode padrão, onde a codificação padrão é iso8859-1 (também conhecido como latin1, byte único), onde caracteres acima de 255 não existem, então o perl muda para UTF-8 para eles (e emite um aviso), mas no perl, quando no modo Unicode, "\xe9"expande para a codificação UTF-8 de U+00E9, enquanto no ksh93, $'\xe9'é o byte 0xe9, independentemente de estar em uma localidade UTF-8 ou não. Para gerar caracteres codificados em UTF-8 com base em seu ponto de código Unicode, é melhor usar o mais novo (do zsh) \uXXXX(ou \UXXXXXXXXXpara aqueles pontos de código acima de 0xffff)}

^{³ No caso do FreeBSD sedque você mencionou, isso não é feito pelo mecanismo de expressões regulares; esses \xHHs são expandidos (em vários lugares, não apenas em expressões regulares) antes de chamar os mecanismos de expressões regulares (semelhante ao que acontece se você fizer isso subject ~ "\47"no awk), e somente desde o FreeBSD 13.0.}

^{4 embora tenha cuidado para garantir que o que se segue não seja mais dígitos hexadecimais, pois o comportamento do ksh93 $'\x20ac'se expande para, €como mencionado acima, é permitido, embora não exigido pelo POSIX, então se você quiser o byte 0x27 seguido por AC, você precisa $'\x27'$'AC', por exemplo (ou usar a forma octal que não tem o problema; o ksh93 suporta, $'\x{27}AC'mas essa não foi especificada pelo POSIX e, como mencionado, raramente é encontrada.}