Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.shell > #14640 > unrolled thread

System und Shell-Scripte: Latin-1 zu UTF-8

Back to article view | Back to de.comp.os.unix.shell

Contents

  System und Shell-Scripte: Latin-1 zu UTF-8 Martin Klaiber <usenet.martinkl@gmx.de> - 2026-03-07 13:07 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Tim Ritberg <tim@server.invalid> - 2026-03-07 13:17 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Martin Klaiber <usenet.martinkl@gmx.de> - 2026-03-07 16:34 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Ralph Aichinger <ra@h5.or.at> - 2026-03-07 12:35 +0000
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Martin Klaiber <usenet.martinkl@gmx.de> - 2026-03-07 16:33 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Thomas Hochstein <thh@thh.name> - 2026-03-07 14:04 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Urs Janßen <urs@niko.tin.org> - 2026-03-07 15:36 +0000
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-07 16:38 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-07 16:48 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Urs Janßen <urs@niko.tin.org> - 2026-03-07 16:51 +0000
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2026-03-07 20:02 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Urs Janßen <urs@niko.tin.org> - 2026-03-07 20:45 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Urs Janßen <urs@niko.tin.org> - 2026-03-07 20:50 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Helmut Waitzmann <nn.throttle@erine.email> - 2026-03-08 01:25 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Martin Klaiber <usenet.martinkl@gmx.de> - 2026-03-07 16:29 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-07 23:12 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Martin Klaiber <usenet.martinkl@gmx.de> - 2026-03-08 00:42 +0100
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 Helmut Waitzmann <nn.throttle@erine.email> - 2026-03-08 03:40 +0100
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 06:14 +0100
            Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 10:47 +0100
            Re: System und Shell-Scripte: Latin-1 zu UTF-8 Helmut Waitzmann <nn.throttle@erine.email> - 2026-03-08 19:05 +0100
              Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 20:40 +0100
                Re: System und Shell-Scripte: Latin-1 zu UTF-8 Helmut Waitzmann <nn.throttle@erine.email> - 2026-03-08 22:29 +0100
                  Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 23:27 +0100
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 09:36 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 07:17 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 09:56 +0100
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 Ralph Aichinger <ra@h5.or.at> - 2026-03-08 09:11 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 10:19 +0100
            Re: System und Shell-Scripte: Latin-1 zu UTF-8 Ralph Aichinger <ra@h5.or.at> - 2026-03-08 10:25 +0000
              Re: System und Shell-Scripte: Latin-1 zu UTF-8 Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2026-03-08 10:41 +0000
              Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 11:52 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Hergen Lehmann <hlehmann-usenet26@snafu.de> - 2026-03-08 10:03 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-03-08 10:56 +0100
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 11:19 +0100
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-03-08 14:09 +0100

Page 1 of 2  [1] 2  Next page →

#14640 — System und Shell-Scripte: Latin-1 zu UTF-8

Ich benutze Linux seit etwa 30 Jahren, und genauso lange zu 99% auf
der Konsole. Von Anfang an hatte ich mir die meisten Programme für
meinen Alltag selbst geschrieben, oft in Form von Shell-Scripten.
Moderne Rechner sind ja schnell genug für so etwas. Ansonsten auch
etwas ruby und in letzter Zeit häufiger auch lua. Diese Orientierung
der Ein- und Ausgabe auf Texte, war auch genau der Grund, warum ich
Linux so anziehend fand. Mit GUIs werde ich bis heute nicht warm.

Diese Scripte haben alle einen 8-bit-Zeichensatz (Latin-1, ISO-8859-1).
Die gesamte Bildschirmausgabe, Formatierung, usw. ist darauf ausgelegt.
Wenn ich einen neuen Rechner in meinen "Zoo" aufgenommen habe, hatte
ich seinen Zeichensatz ebenfalls auf Latin-1 eingestellt.

Nun wird aber UTF-8 in den letzten Jahren immer mehr zum default. Ich
merke es daran, dass es immer häufiger Hakeleien gibt. Und anstatt
ständig gegen die Veränderung anzukämpfen, die sich ohnehin nicht
mehr aufhalten lässt, überlege ich, alle meine selbstgeschriebenen
Script-Programme auf UTF-8 umzustellen. Es geht um rund 1200 Scripte.

Hat das schon mal jemand gemacht? Da lässt sich sicher viel
automatisieren. Aber theoretisch ist UTF-8 ja doppelt so breit, aber
AFAIK auch nicht bei allen Zeichen, damit dürfte dann die Formatierung
am Bildschirm hinüber sein. Oder kompensiert das die Konsole irgendwie
automatisch?

Ich benutze auf meinen Rechnern virtuelle Framebuffer-Konsolen, also
ohne X11. Falls das wichtig sein sollte.

Für alle, die mich gerne als Ewiggestrigen verorten wollen: X11 haben
meine Rechner natürlich auch, das starte ich dann manuell, z.B. wenn
ich mich bei meinem Arbeitgeber einloggen muss, bei dem natürlich ein
Windows läuft. Aber privat ist das halt nichts für mich.

Vorschlag: Da es sich in erster Linie um ein Shell-Thema handelt:
Xpost und fup2 dcous. Ich lese aber auch in dcoulm mit.

Danke, Martin

[toc] | [next] | [standalone]

#14641

Am 07.03.26 um 13:07 schrieb Martin Klaiber:

> Hat das schon mal jemand gemacht? Da lässt sich sicher viel
> automatisieren. Aber theoretisch ist UTF-8 ja doppelt so breit, aber
> AFAIK auch nicht bei allen Zeichen, damit dürfte dann die Formatierung
> am Bildschirm hinüber sein. Oder kompensiert das die Konsole irgendwie
> automatisch?

Macht man das nicht mit iconv?

https://wiki.ubuntuusers.de/Skripte/Zeichensatzkonvertierung/

Tim

[toc] | [prev] | [next] | [standalone]

#14646

Tim Ritberg <tim@server.invalid> wrote:
> Am 07.03.26 um 13:07 schrieb Martin Klaiber:

>> Hat das schon mal jemand gemacht? Da lässt sich sicher viel
>> automatisieren. Aber theoretisch ist UTF-8 ja doppelt so breit, aber
>> AFAIK auch nicht bei allen Zeichen, damit dürfte dann die Formatierung
>> am Bildschirm hinüber sein. Oder kompensiert das die Konsole irgendwie
>> automatisch?

> Macht man das nicht mit iconv?

> https://wiki.ubuntuusers.de/Skripte/Zeichensatzkonvertierung/

Ja. Mir ging es um die Bildschirmdarstellung. Aber da hatte ich einen
Denkfehler im System. Siehe meine anderen Antworten.

Danke und Gruß
Martin

[toc] | [prev] | [next] | [standalone]

#14642

In de.comp.os.unix.shell Martin Klaiber <usenet.martinkl@gmx.de> wrote:
> Hat das schon mal jemand gemacht? Da lässt sich sicher viel
> automatisieren. Aber theoretisch ist UTF-8 ja doppelt so breit, aber
> AFAIK auch nicht bei allen Zeichen, damit dürfte dann die Formatierung
> am Bildschirm hinüber sein. Oder kompensiert das die Konsole irgendwie
> automatisch?

Ist in der Praxis kein Problem, wenn man nicht absichtlich eines zu 
inszenieren versucht. Jedenfalls wäre ich in den letzten 20 Jahren, 
in denen ich UTF-8 verwende nie drüber gestolpert.


> Ich benutze auf meinen Rechnern virtuelle Framebuffer-Konsolen, also
> ohne X11. Falls das wichtig sein sollte.

Ich bin mir nicht sicher wie gut die Font-Unterstützung da ist, den 
Umfang von Latin-15 solltest du aber sicher abdecken können.

Die Frage ist eher, was du in deinen Skripten machst, und wie du das was
in den Skripten verarbeitet wird konvertiest. Ich kann mich nicht 
erinnern, wann zuletzt ein Shellskript bei mir zuletzt wegen UTF-8
aufgemuckt hat.

Ich würde von diesen Skripts einfach mal 10 repräsentative auf einem
reinen UTF-8-System (notfalls VM) ausprobieren und schauen wie weit du
kommst. Ich vermute es gibt abgesehen von der Konvertierarbeit nicht
viele Probleme.

/ralph

[toc] | [prev] | [next] | [standalone]

#14647

Ralph Aichinger <ra@h5.or.at> wrote:
> In de.comp.os.unix.shell Martin Klaiber <usenet.martinkl@gmx.de> wrote:

>> Ich benutze auf meinen Rechnern virtuelle Framebuffer-Konsolen, also
>> ohne X11. Falls das wichtig sein sollte.

> Ich bin mir nicht sicher wie gut die Font-Unterstützung da ist, den 
> Umfang von Latin-15 solltest du aber sicher abdecken können.

Das denke ich auch.

> Ich würde von diesen Skripts einfach mal 10 repräsentative auf einem
> reinen UTF-8-System (notfalls VM) ausprobieren und schauen wie weit du
> kommst. Ich vermute es gibt abgesehen von der Konvertierarbeit nicht
> viele Probleme.

Denke ich inzwischen auch. Ich hatte einen Denkfehler in meinen
Überlegungen. Aus irgendwelchen Gründen dachte ich, 16-bit-Zeichen
würden am Bildschirm doppelt so breit wie 8-bit-Zeichen dargestellt.

Was natürlich Quatsch ist, ein Zeichen ist ein Zeichen, wie Thomas
schon sagte, aber das war mir vorher nicht aufgefallen.

Danke auch Dir!
Martin

[toc] | [prev] | [next] | [standalone]

#14643

Martin Klaiber schrieb:

> Nun wird aber UTF-8 in den letzten Jahren immer mehr zum default. Ich
> merke es daran, dass es immer häufiger Hakeleien gibt. Und anstatt
> ständig gegen die Veränderung anzukämpfen, die sich ohnehin nicht
> mehr aufhalten lässt, überlege ich, alle meine selbstgeschriebenen
> Script-Programme auf UTF-8 umzustellen.

Ja, sicherlich sinnvoll. UTF-8 ist seit langem der Default.

> Es geht um rund 1200 Scripte.

Lieber Himmel! Das ist ... bemerkenswert.

> Hat das schon mal jemand gemacht?

Ja, aber nicht für eine vierstellige Anzahl an Scripts. Solange das
Script keine Eingaben konvertieren muss (und wenn es das tut, hätte es
das ja schon immer tun müssen), dürfte es genügen, die Datei selbst mit
iconv umzukodieren.

> Aber theoretisch ist UTF-8 ja doppelt so breit, aber
> AFAIK auch nicht bei allen Zeichen, damit dürfte dann die Formatierung
> am Bildschirm hinüber sein.

Da kann ich Dir jetzt nicht folgen. Wie die Zeichen intern repräsentiert
werden, hat doch nichts mit der "Breite" in der Anezige zu tun. Ein "ä"
ist immer gleich "breit", ganz egal, wie es intern kodiert ist.

Üblicherweise wird man für die Konsole eine Festbreitenschrift
verwenden, da sind dann alle Zeichen gleich breit.

Grüße,
-thh

[toc] | [prev] | [next] | [standalone]

#14644

Thomas Hochstein wrote:
>> Aber theoretisch ist UTF-8 ja doppelt so breit, aber

ein zeichen (glyphe) in UTF-8 ist 1-4 (bzw. 1-6) bytes lang, und hat eine
bestimmte breite. fuer Latin-1 -> UTF-8 ist die laenge 1 oder 2 byte und
die breite eins.

>> AFAIK auch nicht bei allen Zeichen, damit dürfte dann die Formatierung
>> am Bildschirm hinüber sein.
> 
> Da kann ich Dir jetzt nicht folgen. Wie die Zeichen intern repräsentiert
> werden, hat doch nichts mit der "Breite" in der Anezige zu tun. Ein "ä"
> ist immer gleich "breit", ganz egal, wie es intern kodiert ist.

strlen(3) entsprechung in shell fuer die formatierung waer halt ein
problem.

> Üblicherweise wird man für die Konsole eine Festbreitenschrift
> verwenden, da sind dann alle Zeichen gleich breit.

這樣，這樣

[toc] | [prev] | [next] | [standalone]

#14648

Urs =?UTF-8?Q?Jan=C3=9Fen?= <urs@niko.tin.org> schrieb oder zitierte:
>ein zeichen (glyphe) in UTF-8 ist 1-4 (bzw. 1-6) bytes lang, und hat eine
>bestimmte breite. fuer Latin-1 -> UTF-8 ist die laenge 1 oder 2 byte und
>die breite eins.

  Glyphen (Grapheme) können auch aus mehreren Code-Punkte bestehen.

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
Skript zur Generierung einer HTML5-Demonstration von Mehrfach-Codepunkt-Glyphen.
Die Ausgabe wird als UTF-8 kodierte Datei 'output.html' gespeichert.
"""

def haupt():
    # Definiere Beispiele als (Bezeichnung, Liste von Codepunkt-Integers).
    beispiele = [
        ("US-Flagge", [0x1F1FA, 0x1F1F8]),
        ("Daumen hoch (Medium)", [0x1F44D, 0x1F3FD]),
        ("Familie (ZWJ-Sequenz)", [0x1F468, 0x200D, 0x1F469, 0x200D, 0x1F467]),
        ("e + Akut (Dekomponiert)", [0x0065, 0x0301]),
        ("Herz (Variationsselektor)", [0x2764, 0xFE0F]),
        ("Devanagari-Konjunkt", [0x0915, 0x094D, 0x0937]),
    ]

    # Beginne den HTML-Aufbau
    html_inhalt = []
    html_inhalt.append("<!DOCTYPE html>")
    html_inhalt.append("<html lang=\"de\">")
    html_inhalt.append("<head>")
    html_inhalt.append("    <meta charset=\"UTF-8\">")
    html_inhalt.append("    <title>Mehrfach-Codepunkt-Glyphen</title>")
    html_inhalt.append("    <style>")
    html_inhalt.append("        body { font-family: sans-serif; padding: 20px; }")
    html_inhalt.append("        table { border-collapse: collapse; width: 100%; max-width: 1000px; }")
    html_inhalt.append("        th, td { border: 1px solid #ddd; padding: 8px; text-align: left; }")
    html_inhalt.append("        th { background-color: #f2f2f2; }")
    html_inhalt.append("        .glyph { font-size: 2em; }")
    html_inhalt.append("        .mono { font-family: monospace; font-size: 0.9em; }")
    html_inhalt.append("    </style>")
    html_inhalt.append("</head>")
    html_inhalt.append("<body>")
    html_inhalt.append("    <h1>Demonstration von Unicode-Glyphenstrukturen</h1>")
    html_inhalt.append("    <p>Diese Tabelle zeigt Zeichen, die aus mehreren Unicode-Codepunkten bestehen.</p>")
    html_inhalt.append("    <table>")
    html_inhalt.append("        <thead>")
    html_inhalt.append("            <tr>")
    html_inhalt.append("                <th>Bezeichnung</th>")
    html_inhalt.append("                <th>Zeichen</th>")
    html_inhalt.append("                <th>Codepunkte</th>")
    html_inhalt.append("                <th>UTF-8 Bytes (Hex)</th>")
    html_inhalt.append("            </tr>")
    html_inhalt.append("        </thead>")
    html_inhalt.append("        <tbody>")

    for bezeichnung, punkte in beispiele:
        # Konstruiere den Zeichen-String aus Codepunkt-Integers
        zeichen = "".join(chr(cp) for cp in punkte)

        # Formatiere Codepunkte als U+XXXX für die Anzeige
        punkte_anzeige = " ".join(f"U+{cp:04X}" for cp in punkte)

        # Kodiere zu UTF-8, um die zugrunde liegende Byte-Struktur aufzudecken
        utf8_bytes = zeichen.encode('utf-8')
        byte_anzeige = " ".join(f"{b:02X}" for b in utf8_bytes)

        # Füge die Tabellenzeile hinzu
        html_inhalt.append("            <tr>")
        html_inhalt.append(f"                <td>{bezeichnung}</td>")
        html_inhalt.append(f"                <td class=\"glyph\">{zeichen}</td>")
        html_inhalt.append(f"                <td class=\"mono\">{punkte_anzeige}</td>")
        html_inhalt.append(f"                <td class=\"mono\">{byte_anzeige}</td>")
        html_inhalt.append("            </tr>")

    html_inhalt.append("        </tbody>")
    html_inhalt.append("    </table>")
    html_inhalt.append("</body>")
    html_inhalt.append("</html>")

    # Schreibe die Datei mit UTF-8-Kodierung
    with open('output.html', 'w', encoding='utf-8') as datei:
        datei.write('\n'.join(html_inhalt))

    print("Datei 'output.html' wurde erfolgreich erstellt.")

if __name__ == "__main__":
    haupt()

[toc] | [prev] | [next] | [standalone]

#14649

ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
>("US-Flagge", [0x1F1FA, 0x1F1F8]),

  Unicode definiert keine einzelnen Codepoints für jede
  Länderflagge. Stattdessen gibt es 26 "Regional Indicator
  Symbols", die den Buchstaben A bis Z entsprechen. Wenn zwei
  solcher Indikatoren direkt aufeinanderfolgen, interpretiert
  das Ausgabesystem sie als ISO-3166-Ländercode (hier "US")
  und rendert sie als die entsprechende Flagge.

>("Daumen hoch (Medium)", [0x1F44D, 0x1F3FD]),

  Basis-Emoji sind standardmäßig oft gelb. Um Hautfarben abzubilden,
  gibt es Hautfarben-Modifizierer nach der Fitzpatrick-Skala.

U+1F44D ist das Basis-Emoji "Daumen hoch" (ohne Hautfarbe).
U+1F3FD ist der "Emoji Modifier Fitzpatrick Scale-3".

>("Familie (ZWJ-Sequenz)", [0x1F468, 0x200D, 0x1F469, 0x200D, 0x1F467]),

  Um komplexe Szenen darzustellen (wie Gruppen oder Berufe), werden
  einzelne Emoji durch ein unsichtbares Zeichen verbunden.

U+1F468 (Mann)
U+200D (Zero Width Joiner – ein unsichtbares Steuerzeichen)
usw.

  Der ZWJ (U+200D) hat keine eigene Darstellung. Er signalisiert
  dem Ausgabessystem jedoch: "Verschmelze das Zeichen davor
  und das Zeichen danach zu einer einzigen Glyphe". Ohne das
  ZWJ würden drei separate Figuren nebeneinander stehen.

>("e + Akut (Dekomponiert)", [0x0065, 0x0301]),

U+0065 ist der lateinische Kleinbuchstabe e.
U+0301 ist das kombinierende akute Akzentzeichen.

>("Herz (Variationsselektor)", [0x2764, 0xFE0F]),

  Der Variationsselektor ändert die Darstellungsform des
  vorherigen Zeichens. VS16 erzwingt ausdrücklich die
  Emoji-Präsentation (bunt).

>("Devanagari-Konjunkt", [0x0915, 0x094D, 0x0937]),

U+0915 ist ein Konsonantenvokal Ka (क).
U+094D ist das Virama (्) - ein Zeichen, das den inhärenten Vokal 
       des vorherigen Konsonanten entfernt.
U+0937 ist der Konsonant Ssa (ष).

[toc] | [prev] | [next] | [standalone]

#14650

Stefan Ram wrote:
>>ein zeichen (glyphe) in UTF-8 ist 1-4 (bzw. 1-6) bytes lang, und hat eine
>>bestimmte breite. fuer Latin-1 -> UTF-8 ist die laenge 1 oder 2 byte und
>>die breite eins.
>   Glyphen (Grapheme) können auch aus mehreren Code-Punkte bestehen.

ich wollt's nicht noch komplizierter machen, aber ja.

[toc] | [prev] | [next] | [standalone]

#14651

On Sat, 07 Mar 2026 16:36:15 Urs Janßen wrote:
> Thomas Hochstein wrote:
>> Üblicherweise wird man für die Konsole eine Festbreitenschrift
>> verwenden, da sind dann alle Zeichen gleich breit.
 
> 這樣，這樣

Das hätte ich auch schon beinahe geschrieben, da die Skripte aber
von ISO-8859-1 nach UTF-8 kopiert werden, *können* sie danach keine
wide characters enthalten.

Einzig für mich vorstellbares Problem wären Operationen auf Strings
mit Umlauten, also ${parameter:offset} oder ähnliches. Das ist aber,
zuaml auf im Skript selbst definierte Strings, schon eher exotisch.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - das absurdste Versprechen, das es je gab.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#14652

Stefan Froehlich wrote:
>>> Üblicherweise wird man für die Konsole eine Festbreitenschrift
>>> verwenden, da sind dann alle Zeichen gleich breit.
> 
>> 這樣，這樣
> 
> Das hätte ich auch schon beinahe geschrieben, da die Skripte aber
> von ISO-8859-1 nach UTF-8 kopiert werden, *können* sie danach keine
> wide characters enthalten.

sagte ich ja
| fuer Latin-1 -> UTF-8 ist die laenge 1 oder 2 byte und
! die breite eins.

> Einzig für mich vorstellbares Problem wären Operationen auf Strings
> mit Umlauten, also ${parameter:offset} oder ähnliches. Das ist aber,
> zuaml auf im Skript selbst definierte Strings, schon eher exotisch.

ebenso
| strlen(3) entsprechung in shell fuer die formatierung waer halt ein
| problem

[toc] | [prev] | [next] | [standalone]

#14653

Stefan Froehlich wrote:
>>> Üblicherweise wird man für die Konsole eine Festbreitenschrift
>>> verwenden, da sind dann alle Zeichen gleich breit.
> 
>> 這樣，這樣
> 
> Das hätte ich auch schon beinahe geschrieben, da die Skripte aber
> von ISO-8859-1 nach UTF-8 kopiert werden, *können* sie danach keine
> wide characters enthalten.

sagte ich ja
| fuer Latin-1 -> UTF-8 ist die laenge 1 oder 2 byte und
! die breite eins.

(wobei die aussage "1 oder 2 byte" combining chars (z.b. U+0041 U+0308
 vs. U+00C4) nicht beruecksichtigt)

> Einzig für mich vorstellbares Problem wären Operationen auf Strings
> mit Umlauten, also ${parameter:offset} oder ähnliches. Das ist aber,
> zuaml auf im Skript selbst definierte Strings, schon eher exotisch.

ebenso
| strlen(3) entsprechung in shell fuer die formatierung waer halt ein
| problem

[toc] | [prev] | [next] | [standalone]

#14656

 Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich):
> Einzig für mich vorstellbares Problem wären Operationen auf 
> Strings mit Umlauten, also ${parameter:offset} oder ähnliches. 
> Das ist aber, zuaml auf im Skript selbst definierte Strings, 
> schon eher exotisch. 
>

 Hier folgen zwei Beispiele unter der Locale‐Konfiguration 


   LANG=C
   LANGUAGE=
   LC_CTYPE=de_DE.UTF-8
   LC_NUMERIC=en_US.UTF-8
   LC_TIME=de_DE.UTF-8
   LC_COLLATE=de_DE.UTF-8
   LC_MONETARY=de_DE.UTF-8
   LC_MESSAGES=C
   LC_PAPER=de_DE.UTF-8
   LC_NAME=de_DE.UTF-8
   LC_ADDRESS=de_DE.UTF-8
   LC_TELEPHONE=de_DE.UTF-8
   LC_MEASUREMENT=de_DE.UTF-8
   LC_IDENTIFICATION=de_DE.UTF-8
   LC_ALL=



 Das Shell‐Kommando 


   (
     for commandline in \
       'bash-built-in bash -c '\''"$@"'\'' bash' \
       'dash-built-in dash -c '\''"$@"'\'' dash' \
       'stand-alone env'
     do
       eval 'set -- '"$commandline" &&
       printf '\n%s:\n' "$1 printf" &&
       shift &&
       "$@" printf '%-4s%s\n' \
         a 'ein Buchstabe' ä 'ein Buchstabe' \
         ‐ 'ein Bindestrich' – 'ein Gedankenstrich'
     done
   )


 sollte in je einer eigenen Zeile ein kleines A, ein kleines Ä, 
 einen Bindestrich und einen Gedankenstrich und dahinter, nach 3 
 Leerzeichen eine Bemerkung zum ausgegebenen Zeichen, also die 
 folgende Tabelle, ausgeben, indem es das 
 „printf“‐Formatierungselement „%-4s“ benutzt: 


   a   ein Buchstabe
   ä   ein Buchstabe
   ‐   ein Bindestrich
   –   ein Gedankenstrich


 Es gibt die Tabelle dreimal aus:  Beim ersten Mal benutzt es 
 dabei das ins „bash“ eingebaute „printf“; beim zweiten Mal 
 benutzt es das ins „dash“ (Debian Almquist Shell) eingebaute 
 „printf“; und beim dritten Mal benutzt es das selbständige 
 „printf“‐Programm. 


 Beobachtung auf Debian 11: 


 die „printf“‐Kommandos rechnen in einer UTF-8‐Umgebung die Anzahl 
 der einzufügenden Leerzeichen falsch aus, und dabei spielt es 
 keine Rolle, welches der drei „printf“ man benutzt:  Alle drei 
 Fälle scheinen davon auszugehen, dass jedes Zeichen in genau 1 
 Byte kodiert ist. 



 Das folgende Shell‐Kommando sollte in je einer eigenen Zeile ein 
 kleines A, ein kleines Ä, einen Bindestrich und einen 
 Gedankenstrich und dahinter die Länge dieses ausgegebenen 
 Zeichens (sollte immer 1 sein), also die folgende Tabelle, 
 ausgeben, indem es vom Shell die Länge des Inhalts der Variablen 
 „$1“ berechnen lässt: 


   a 1
   ä 1
   ‐ 1
   – 1


 Es gibt die Tabelle zweimal aus:  Beim ersten Mal benutzt es ein 
 „bash“, das zweite Mal ein „dash“: 

   (
     for shell in bash dash
     do
       printf '\n%s:\n' "$shell" &&
       for zeichen in a ä ‐ –
       do
         "$shell" -c 'printf '\''%s %s\n'\'' "$1" "${#1}"' \
           "$shell" "$zeichen"
       done
     done
   )


 Beobachtung auf Debian 11:  Das „bash“ bekommt die Berechnung der 
 Länge der 1‐Zeichen‐Zeichenkette (jeweils 1) hin, während das 
 „dash“ einfach Bytes zählt (und damit den POSIX‐Standard bricht): 


   bash:
   a 1
   ä 1
   ‐ 1
   – 1

   dash:
   a 1
   ä 2
   ‐ 3
   – 3


 (Das ist einer der Gründe dafür, weshalb auf meinem 
 Debian‐11‐System „/bin/sh“ ein symbolic link nicht auf „dash“ 
 sondern auf „bash“ ist.) 

[toc] | [prev] | [next] | [standalone]

#14645

Thomas Hochstein <thh@thh.name> wrote:
> Martin Klaiber schrieb:

>> Es geht um rund 1200 Scripte.

> Lieber Himmel! Das ist ... bemerkenswert.

Naja, das ist Unix: do one job, and do it well ;-)

Da sind viele sehr kleine Scripte dabei, die eine spezialisierte
Aufgabe haben und mit anderen zu größeren Scripten kombiniert werden.
Also vielleicht das, was Bibliotheken bei Hochsprachen sind.

>> Aber theoretisch ist UTF-8 ja doppelt so breit, aber
>> AFAIK auch nicht bei allen Zeichen, damit dürfte dann die Formatierung
>> am Bildschirm hinüber sein.

> Da kann ich Dir jetzt nicht folgen. Wie die Zeichen intern repräsentiert
> werden, hat doch nichts mit der "Breite" in der Anezige zu tun. Ein "ä"
> ist immer gleich "breit", ganz egal, wie es intern kodiert ist.

Äh, ja, ich kann mir gerade selbst nicht mehr folgen ;-)

Das war ein Denkfehler von mir. Ich dachte, die 16-bit-Zeichen nehmen
dann auch zwei Bildschirmpositionen ein. Was natürlich Quatsch ist.

> Üblicherweise wird man für die Konsole eine Festbreitenschrift
> verwenden, da sind dann alle Zeichen gleich breit.

Yep. Der Groschen ist gefallen ;-)

Danke, Martin

[toc] | [prev] | [next] | [standalone]

#14654

Martin Klaiber <usenet.martinkl@gmx.de> writes:

[...]
> Nun wird aber UTF-8 in den letzten Jahren immer mehr zum default. Ich
> merke es daran, dass es immer häufiger Hakeleien gibt. Und anstatt
> ständig gegen die Veränderung anzukämpfen, die sich ohnehin nicht
> mehr aufhalten lässt, überlege ich, alle meine selbstgeschriebenen
> Script-Programme auf UTF-8 umzustellen. Es geht um rund 1200 Scripte.
[...]

Abgesehen vom Konvertieren der Skripte
mittels iconv sollte man auch darauf
achten, dass sämtliche dort verwendeten
Tools UTF-8-kompatibel sind und auf die
locale, insbesondere LC_CTYPE adäquat
reagieren.

-- 
Stefan

[toc] | [prev] | [next] | [standalone]

#14655

Stefan Wiens <s.wi@gmx.net> wrote:

> Abgesehen vom Konvertieren der Skripte
> mittels iconv sollte man auch darauf
> achten, dass sämtliche dort verwendeten
> Tools UTF-8-kompatibel sind und auf die
> locale, insbesondere LC_CTYPE adäquat
> reagieren.

Ja, danke, guter Tipp!

Denkst Du an ein bestimmtes Szenario?

Ich habe jetzt schon das "Problem", dass printf das Komma als
Dezimaltrennzeichen bei einer deutschen locale kennt, aber bc nicht,
sondern nur den Punkt.

Ich meine so etwas wie:

| martinkl@maurice:~$ printf "%f\n" $(echo "4/3" | bc -l)
| -bash: printf: 1.33333333333333333333: invalid number
| 1,000000

Ich muss immer LC_NUMERIC=C setzen, damit printf den Dezimalpunkt
akzeptiert:

| martinkl@maurice:~$ LC_NUMERIC=C printf "%f\n" $(echo "4/3" | bc -l)
| 1.333333

Irgendwo hatte ich auch mal eine Begründung gelesen, warum bc nicht
lokalisiert werden wird. Habe es aber wieder vergessen. Jedenfalls
wird das mit dem Dezimalpunkt wohl so bleiben.

Martin

[toc] | [prev] | [next] | [standalone]

#14657

 Martin Klaiber <usenet.martinkl@gmx.de>:
> Stefan Wiens <s.wi@gmx.net> wrote:
>
>> Abgesehen vom Konvertieren der Skripte 
>> mittels iconv sollte man auch darauf 
>> achten, dass sämtliche dort verwendeten 
>> Tools UTF-8-kompatibel sind und auf die 
>> locale, insbesondere LC_CTYPE adäquat 
>> reagieren. 
>
> Ja, danke, guter Tipp! 
>
> Denkst Du an ein bestimmtes Szenario? 
>
> Ich habe jetzt schon das "Problem", dass printf das Komma als 
> Dezimaltrennzeichen bei einer deutschen locale kennt, aber bc nicht, 
> sondern nur den Punkt. 
>
> Ich meine so etwas wie: 
>
> | martinkl@maurice:~$ printf "%f\n" $(echo "4/3" | bc -l)
> | -bash: printf: 1.33333333333333333333: invalid number
> | 1,000000
>
> Ich muss immer LC_NUMERIC=C setzen, damit printf den Dezimalpunkt 
> akzeptiert: 
>
> | martinkl@maurice:~$ LC_NUMERIC=C printf "%f\n" $(echo "4/3" | bc -l)
> | 1.333333
>

 Das Stand‐alone‐„printf“ akzeptiert in einem Locale mit 
 Dezimalkomma sowohl den Punkt als auch das Komma als 
 Dezimaltrenner.  Hier im Vergleich zu den in die Shells 
 eingebauten „printf“‐Kommandos: 


   (
     for commandline in \
       'bash-built-in bash -c '\''"$@"'\'' bash' \
       'sh-built-in sh -c '\''"$@"'\'' sh' \
       'dash-built-in dash -c '\''"$@"'\'' dash' \
       'stand-alone env'
     do
       eval 'set -- '"$commandline" &&
       printf '\n%s:\n' "$1 printf" &&
       shift &&
       "$@" printf '%f\n' '12.34' '12,34'
     done
   )


 ohne LC_NUMERIC auf C zu setzen.  (Bei mir ist „/bin/sh“ ein 
 symbolic link auf „bash“.) 


 Die Ausgabe sieht so aus: 


   bash-built-in printf:
   bash: line 1: printf: 12.34: invalid number
   12,000000
   12,340000

   sh-built-in printf:
   sh: line 1: printf: 12.34: invalid number
   12,000000
   12,340000

   dash-built-in printf:
   dash: 1: printf: 12,34: not completely converted
   12.340000
   12.000000

   stand-alone printf:
   12,340000
   12,340000


 Alternativ könnte man auch die Ausgabe von „bc“ durch „tr“ 
 schieben, um jegliche Punkte durch Kommata zu ersetzen: 


   printf '%s\n' '4/3' | bc -l |
   (
     dezimaltrenner="$( locale -- decimal_point )" &&
     tr -- . "$dezimaltrenner"
   )

[toc] | [prev] | [next] | [standalone]

#14658

Helmut Waitzmann <nn.throttle@erine.email> writes:

> Martin Klaiber <usenet.martinkl@gmx.de>:
>> Stefan Wiens <s.wi@gmx.net> wrote:
>>
>>> Abgesehen vom Konvertieren der Skripte mittels iconv sollte man
>>> auch darauf achten, dass sämtliche dort verwendeten Tools
>>> UTF-8-kompatibel sind und auf die locale, insbesondere LC_CTYPE
>>> adäquat reagieren. 
>>
>> Ja, danke, guter Tipp! Denkst Du an ein bestimmtes Szenario?
> [...]
> Alternativ könnte man auch die Ausgabe von „bc“ durch „tr“  schieben,
> um jegliche Punkte durch Kommata zu ersetzen:    printf '%s\n' '4/3' |
> [...]

tr(1) ist ein gutes Beispiel, wo es hakeln könnte.
Hier (GNU coreutils) 9.1:

,----[ (coreutils) Character arrays ]
|    The interpretation of STRING1 and STRING2 depends on locale.  GNU
| ‘tr’ fully supports only safe single-byte locales, where each possible
| input byte represents a single character.  Unfortunately, this means GNU
| ‘tr’ will not handle commands like ‘tr $'\u7530' $'\u68EE'’ the way you
| might expect, since (assuming a UTF-8 encoding) this is equivalent to
| ‘tr '\347\224\260' '\346\243\256'’ and GNU ‘tr’ will simply
| transliterate all ‘\347’ bytes to ‘\346’ bytes, etc.  POSIX does not
| clearly specify the behavior of ‘tr’ in locales where characters are
| represented by byte sequences instead of by individual bytes, or where
| data might contain invalid bytes that are encoding errors.  To avoid
| problems in this area, you can run ‘tr’ in a safe single-byte locale by
| using a shell command like ‘LC_ALL=C tr’ instead of plain ‘tr’.
`----

$ echo klöä | LC_ALL=de_DE.UTF8 tr [:lower:] [:upper:]
KLöä
§


sed (GNU sed) 4.9 scheint hingegen mit
LC_CTYPE_de_DE.UTF-8 klarzukommen
(dort gibt es aber keine Zeichenklassen).

-- 
Stefan

[toc] | [prev] | [next] | [standalone]

#14665

Ingrid Stefan Wiens <s.wi@gmx.net> writes:

> tr(1) ist ein gutes Beispiel, wo es hakeln könnte.
> Hier (GNU coreutils) 9.1:
[...]
> $ echo klöä | LC_ALL=de_DE.UTF8 tr [:lower:] [:upper:]
> KLöä
> §

Da gibt es eigentlich keinen Gestaltungsspielraum:

,----[ <https://pubs.opengroup.org/onlinepubs/009695399/utilities/tr.html> ]
| Otherwise, only character class names lower or upper are valid in
| string2 and then only if the corresponding character class ( upper and
| lower, respectively) is specified in the same relative position in
| string1. Such a specification shall be interpreted as a request for
| case conversion. When [: lower:] appears in string1 and [: upper:]
| appears in string2, the arrays shall contain the characters from the
| toupper mapping in the LC_CTYPE category of the current locale. When
| [: upper:] appears in string1 and [: lower:] appears in string2, the
| arrays shall contain the characters from the tolower mapping in the
| LC_CTYPE category of the current locale. The first character from each
| mapping pair shall be in the array for string1 and the second
| character from each mapping pair shall be in the array for string2 in
| the same relative position.
`----

Die exzessiven Leerzeichen bei "[: lower:]" etc. stehen
dort fälschlicherweise.

Jedenfalls ist GNU tr im Unrecht.

-- 
Stefan

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comp.os.unix.shell

csiph-web