Por que o printf está "encolhendo" o trema?

Se eu executar o seguinte script simples:

#!/bin/bash
printf "%-20s %s\n" "Früchte und Gemüse"   "foo"
printf "%-20s %s\n" "Milchprodukte"        "bar"
printf "%-20s %s\n" "12345678901234567890" "baz"

Imprime:

Früchte und Gemüse foo
Milchprodukte        bar
12345678901234567890 baz

ou seja, o texto com tremas (como ü) é "reduzido" por um caractere por trema.

Certamente, tenho alguma configuração errada em algum lugar, mas não consigo descobrir qual poderia ser.

Isso ocorre se a codificação do arquivo for UTF-8.

Se eu alterar sua codificação para latin-1, o alinhamento está correto, mas os tremas estão incorretos:

Fr�chte und Gem�se   foo
Milchprodukte        bar
12345678901234567890 baz

POSIX requer printf é %-20spara contar os 20 em termos de bytes não caracteres apesar de que faz pouco sentido como printfé imprimir texto , formatado (ver discussão no Grupo de Austin (POSIX) e bashlistas de discussão).

O printfembutido bashe a maioria dos outros cartuchos POSIX honram isso.

zshignora esse requisito bobo (mesmo em shemulação) e printffunciona como você esperaria lá. O mesmo para o printfbuilt-in fish(não é um shell semelhante ao POSIX).

O ücaractere (U + 00FC), quando codificado em UTF-8, é composto de dois bytes (0xc3 e 0xbc), o que explica a discrepância.

$ printf %s 'Früchte und Gemüse' | wc -mcL
    18      20      18

Essa cadeia é composta por 18 caracteres, tem 18 colunas de largura ( -Lsendo uma wcextensão GNU para relatar a largura de exibição da linha mais larga na entrada), mas é codificada em 20 bytes.

Em zshou fish, o texto seria alinhado corretamente.

Agora, também existem caracteres com largura 0 (como combinar caracteres como U + 0308, a diarese combinada) ou largura dupla como em muitos scripts asiáticos (para não mencionar caracteres de controle como Tab) e nem zshalinharem aqueles corretamente.

Exemplo, em zsh:

$ printf '%3s|\n' u ü $'u\u308' $'\u1100'
  u|
  ü|
 ü|
  ᄀ|

Em bash:

$ printf '%3s|\n' u ü $'u\u308' $'\u1100'
  u|
 ü|
ü|
ᄀ|

ksh93possui uma %Lsespecificação de formato para contar a largura em termos de largura de exibição .

$ printf '%3Ls|\n' u ü $'u\u308' $'\u1100'
  u|
  ü|
  ü|
 ᄀ|

Isso ainda não funciona se o texto contiver caracteres de controle como TAB (como poderia? printfTeria que saber a que distância as paradas de tabulação estão no dispositivo de saída e em que posição ele começa a imprimir). Ele funciona acidentalmente com caracteres de backspace (como na roffsaída em que X(negrito X) é escrito como X\bX), embora ksh93considere todos os caracteres de controle como tendo uma largura de -1.

Como outras opções, você pode tentar:

printf '%s\t|\n' u ü $'u\u308' $'\u1100' | expand -t3

Isso funciona com algumas expandimplementações (embora não seja do GNU).

Nos sistemas GNU, você pode usar o GNU awkcujas printfcontagens em caracteres (não bytes, nem larguras de exibição, ainda não estão OK para os caracteres de 0 ou 2 de largura, mas sim para sua amostra):

gawk 'BEGIN {for (i = 1; i < ARGC; i++) printf "%-3s|\n", ARGV[i]}
     ' u ü $'u\u308' $'\u1100'

Se a saída for para um terminal, você também pode usar seqüências de escape de posicionamento do cursor. Gostar:

forward21=$(tput cuf 21)
printf '%s\r%s%s\n' \
  "Früchte und Gemüse"    "$forward21" "foo" \
  "Milchprodukte"         "$forward21" "bar" \
  "12345678901234567890"  "$forward21" "baz"

Se eu alterar sua codificação para latin-1, o alinhamento está correto, mas os tremas estão incorretos:

Fr�chte und Gem�se   foo
Milchprodukte        bar
12345678901234567890 baz

Na verdade, não, mas seu terminal não fala latim-1 e, portanto, você recebe lixo em vez de trema.

Você pode corrigir isso usando iconv:

printf foo bar | iconv -f ISO8859-1 -t UTF-8

(ou apenas execute todo o script do shell canalizado para iconv)