[Frage] (Kein) Editor für die Bearbeitung von Dateien mit UTF-8 kodierten Zeichen?

[make]

Ich muss aus gelegentlich Dateien auf einer 7390 editieren, die UTF-8 kodierte Zeichen enthalten. Typischerweise sind das Umlaute, aber auch das Grad-Symbol (°) gehört zu den Problemkandidaten.

Auf der Box habe ich VI und nano. Beide haben (unterschiedliche) Probleme bei Eingabe und Ausgabe der Zeichen. VI macht aus UTF-8 Zeichen ein . (möglicherweise konfigurierbar, macht aber für mich keinen Unterschied). nano übersetzt die UTF-8-Zeichen in irgendwelche Escape-Sequenzen. Ist mehr als ein UTF-8-Zeichen in einer Zeile vorhanden, kommt nano ordentlich durcheinander -- das Editieren solcher Zeilen versucht man besser gar nicht erst. Mein Terminal und LANG stehen auf irgendwas-utf-8, und in der Shell ist die Eingabe oder Ausgabe von Umlauten etc auch kein Problem.

Nano lässt sich prinzipiell auch mit utf-8-Unterstützung bauen. Allerdings setzt das wide-character support in ncurses voraus, und das scheint eine größere Baustelle zu sein. Zwar lässt sich der UTF-8-Support dort auch über Build-Option einschalten, allerdings heißen die ganzen Libraries dann anders und liegen (zum Teil?) in anderen Verzeichnissen. Davon abgesehen müsste man auch alle Pakete ändern, die ncurses ohne wide-character Support verwenden.

Meine Frage ist also ob es noch eine andere Alternative gibt, mit deren Hilfe ich meine Dateien mit UTF-8-Zeichen _auf der Box_ bearbeiten könnte? Ein anderer Editor vielleicht? Oder wäre der sinnvollere Ansatz, ein zweites ncurses-Paket (halt mit wide-character-support) anzulegen und beide ncurses-Libraries parallel zur Verfügung zu haben?

 

[er13]

Mit

FREETZ_BUSYBOX_LOCALE_SUPPORT=y
FREETZ_BUSYBOX_UNICODE_SUPPORT=y
FREETZ_BUSYBOX_UNICODE_USING_LOCALE=y
FREETZ_BUSYBOX_SUBST_WCHAR=0
FREETZ_BUSYBOX_LAST_SUPPORTED_WCHAR=0
FREETZ_BUSYBOX_UNICODE_COMBINING_WCHARS=y
FREETZ_BUSYBOX_UNICODE_WIDE_WCHARS=y
# FREETZ_BUSYBOX_UNICODE_PRESERVE_BROKEN is not set

funktioniert vi bei mir einwandfrei.

LANG-Variable wird dabei von diesem Script automatisch auf en_US.UTF-8 gesetzt.

 

[make]

Danke für den Tipp. Leider ändert das an meinem Problem nichts. Es muss da wohl noch einen anderen Faktor geben. Auch mit der Konfiguration von dir weigert sich vi bei mir Umlaute entgegen zu nehmen _oder_ anzuzeigen. Dargestellt werden eingegebene Umlaute im vi als . in der Statuszeile steht >'.' is not implemented<.

Ähnlich verhält es sich, wenn ich eine Datei mit Umlauten im vi öffne (echo "äöü" > foo && vi foo) -- statt der Umlaute sehe ich nur 6 Punkte.

Alle anderen Zeichen (ASCII) kann ich in vi ohne Probleme eingeben. Das ging aber auch schon ohne die busybox-Anpassungen.

Ticket?

 

[er13]

root@fb:/var/mod/root# echo $LANG
en_US.UTF-8
root@fb:/var/mod/root# echo $TERM
xterm

Busybox ist mit den Einstellungen oben gebaut - funktioniert wie gesagt bei mir einwandfrei - habe es soeben extra auf 4 verschiedenen Boxen in meiner Familie getestet.

Du sprichts komischerweise immer von vi... Dein Beispiel lässt vermuten, dass die Eingabe von Umlauten im Terminal an sich funktioniert (sonst wäre die Eingabe von echo "äöü" nicht möglich) und dass es ausschießlich ein Editor-Problem wäre. Könntest Du das bitte bestätigen, um zu vermeiden, dass wir das Problem an sich unterschiedlich verstehen. Was passiert, wenn Du echo "äöü" > foo && cat foo eingibst? Sind die Umlaute zu sehen?

Wenn Du von vi sprichst, meinst Du den busybox-vi (/bin/vi -> busybox) oder vi aus dem vi-Paket (/usr/bin/vim)?

Edit: Du sprichst vermutlich von vim - vim wird in Freetz ohne multibyte-support gebaut.

Edit2: nach r12892 funktioniert es bei mir auch mit vim.

 

[make]

root@fb:~# echo "öäüß°" > test && cat test
öäüß°
root@fb:~# which vi
/bin/vi
root@fb:~# ls -l /bin/vi
lrwxrwxrwx    1 root     root             7 Jan 31 00:01 /bin/vi -> busybox*
root@fb:~# echo $LANG
de_DE.UTF-8
root@fb:~# echo $TERM
xterm
root@fb:~#vi test
..........
~
~
- test 1/1 100%

LANG wird bei mir im .profile umgesetzt, hat aber keinen Einfluss auf das Problem. TERM habe ich eine ganze Reihe durchprobiert, ohne das sich etwas ändern würde. Also ja, ich denke, dass es um ein Problem des bzw. der Editoren handelt.

Edit: vim funktioniert bei mir, vi und nano nicht. Ich nehme an, dass vim die busybox-Anpassungen aus deinem ersten Beitrag nicht benötigt, oder?