Dlaczego printf „kurczy się”?

Jeśli wykonam następujący prosty skrypt:

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

Drukuje:

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

to znaczy tekst z umlautami (np. ü) jest „zmniejszany” o jeden znak na umlaut.

Oczywiście, mam gdzieś jakieś złe ustawienie, ale nie jestem w stanie ustalić, który to może być.

Dzieje się tak, jeśli kodowanie pliku to UTF-8.

Jeśli zmienię kodowanie na latin-1, wyrównanie jest prawidłowe, ale umlauty są renderowane nieprawidłowo:

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

POSIX wymaga printf , %-20saby policzyć te 20 w kategoriach bajtów, a nie znaków, chociaż nie ma to większego sensu, jak printfdrukowanie tekstu , formatowanie (patrz dyskusja w Austin Group (POSIX) i bashlisty mailingowe).

Uwzględniają to printfwbudowane bashi większość innych powłok POSIX.

zshignoruje to głupie wymaganie (nawet w shemulacji), więc printfdziała tak, jak można się tam spodziewać. To samo dotyczy printfwbudowanej fish(nie powłoki podobnej do POSIX).

üZnak (U + 00FC), w którym zakodowane UTF-8 składa się z dwóch bajtów (0xc3 i 0xbc), co wyjaśnia różnicę.

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

Łańcuch ten składa się z 18 znaków, ma 18 kolumn szerokości ( -Ljest wcrozszerzeniem GNU raportującym szerokość wyświetlania najszerszej linii na wejściu), ale jest zakodowany na 20 bajtach.

W zshlub fishtekst zostałby wyrównany poprawnie.

Teraz są też znaki, które mają szerokość 0 (jak łączenie znaków, takich jak U + 0308, łączenie diurezy) lub mają podwójną szerokość, jak w wielu skryptach azjatyckich (nie wspominając o znakach kontrolnych, takich jak Tab), a nawet zshnie wyrównywałyby te poprawnie.

Przykład w zsh:

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

W bash:

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

ksh93ma %Lsspecyfikację formatu, aby policzyć szerokość pod względem szerokości wyświetlania .

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

To nadal nie działa, jeśli tekst zawiera znaki sterujące, takie jak TAB (jak to możliwe? printfMusiałby wiedzieć, jak daleko od siebie są tabulatory w urządzeniu wyjściowym i w jakiej pozycji zaczyna drukować). Działa przypadkowo ze znakami backspace (jak na roffwyjściu, gdzie zapisano X(pogrubienie X) jako X\bX), chociaż ksh93uważa, że ​​wszystkie znaki sterujące mają szerokość -1.

Jako inne opcje możesz spróbować:

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

Działa to z niektórymi expandimplementacjami (choć nie GNU).

W systemach GNU możesz użyć GNU, awkktórego printfliczenie jest w znakach (nie bajtach, nie szerokościach wyświetlania, więc nadal nie jest OK dla znaków o szerokości 0 lub 2 szerokości, ale OK dla twojej próbki):

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

Jeśli dane wyjściowe trafiają do terminala, możesz także użyć sekwencji ucieczki pozycjonowania kursora. Lubić:

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

Jeśli zmienię kodowanie na latin-1, wyrównanie jest prawidłowe, ale umlauty są renderowane nieprawidłowo:

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

Właściwie nie, ale twój terminal nie mówi po łacinie-1, dlatego dostajesz śmieci zamiast umlautów.

Możesz to naprawić za pomocą iconv:

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

(lub po prostu uruchom cały skrypt powłoki przesłany do iconv)