Discussion:
/bin/sh nicht gefunden?
(zu alt für eine Antwort)
Alexander Goetzenstein
2019-11-04 10:43:12 UTC
Permalink
Hallo,
ein Script gibt eine für mich nicht nachvollziehbare Fehlermeldung aus,
wird aber anschließend fehlerfrei abgearbeitet. Wie jedes meiner Scripte
beginnt es mit
#!/bin/sh
/home/alex/bin/dateinamen-entschaerfen.sh: Zeile 1: #!/bin/sh: Datei oder Verzeichnis nicht gefunden
lrwxrwxrwx 1 root root 11 20. Sep 15:17 /bin/sh -> /usr/bin/sh
lrwxrwxrwx 1 root root 20 26. Sep 21:59 /usr/bin/sh -> /etc/alternatives/sh
lrwxrwxrwx 1 root root 13 26. Sep 21:59 /etc/alternatives/sh -> /usr/bin/bash
-rwxr-xr-x 1 root root 1066104 20. Sep 15:17 /usr/bin/bash
Ich sehe den Fehler einfach nicht: was ist da los?
--
Gruß
Alex
Helmut Harnisch
2019-11-04 11:11:21 UTC
Permalink
Post by Alexander Goetzenstein
beginnt es mit
#!/bin/sh
/home/alex/bin/dateinamen-entschaerfen.sh: Zeile 1: #!/bin/sh: Datei oder Verzeichnis nicht gefunden
hast du es mit vi editiert? Schau mal auf die Zeilenenden bzw auf die
Codierung (UTF-8)
Alexander Goetzenstein
2019-11-04 13:16:47 UTC
Permalink
Hallo,
Post by Helmut Harnisch
hast du es mit vi editiert? Schau mal auf die Zeilenenden bzw auf die
Codierung (UTF-8)
das habe ich tatsächlich, aber das tat ich ja nicht zum ersten mal, und
in kate geöffnet sieht es auch in Ordnung aus. Ich habe dort auch noch
mal eine Leerzeile eingefügt und neu gespeichert, was aber auch nicht hilft.
--
Gruß
Alex
Helmut Harnisch
2019-11-04 11:14:40 UTC
Permalink
#!/bin/sh: Datei oder Verzeichnis nicht gefunden
read this:
https://unix.stackexchange.com/questions/27054/bin-bash-no-such-file-or-directory
Alexander Goetzenstein
2019-11-04 13:18:43 UTC
Permalink
Hallo,
Post by Helmut Harnisch
#!/bin/sh: Datei oder Verzeichnis nicht gefunden
https://unix.stackexchange.com/questions/27054/bin-bash-no-such-file-or-directory
Danke, das hat geholfen. Irgendwie haben sich unsichtbare Zeichen an den
Anfang geschmuggelt -weiß der Fuchs, wie. Ist aber auch egal, jetzt
rennt es wieder wie es soll.
--
Gruß
Alex
Eike Rathke
2019-11-05 16:13:35 UTC
Permalink
Post by Alexander Goetzenstein
Post by Helmut Harnisch
https://unix.stackexchange.com/questions/27054/bin-bash-no-such-file-or-directory
Danke, das hat geholfen. Irgendwie haben sich unsichtbare Zeichen an den
Anfang geschmuggelt -weiß der Fuchs, wie.
Vermutlich hast du einen deutschen Kommentar mit Umlauten in die Datei
geschrieben und deinem Editor nicht verboten, beim enkodieren nach UTF-8
ein BOM einzufuegen.

Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
J***@fokus.fraunhofer.de
2019-11-07 15:04:57 UTC
Permalink
Post by Eike Rathke
Post by Alexander Goetzenstein
Post by Helmut Harnisch
https://unix.stackexchange.com/questions/27054/bin-bash-no-such-file-or-directory
Danke, das hat geholfen. Irgendwie haben sich unsichtbare Zeichen an den
Anfang geschmuggelt -weiß der Fuchs, wie.
Vermutlich hast du einen deutschen Kommentar mit Umlauten in die Datei
geschrieben und deinem Editor nicht verboten, beim enkodieren nach UTF-8
ein BOM einzufuegen.
Ein Editor, der das tut, kann auf UNIX als defekt eingestuft werden.

UTF-8 hat keine Byte-order, es ist Oktett-basiert.
--
EMail:***@schily.net (home) Jörg Schilling D-13353 Berlin
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Stefan Kanthak
2019-11-08 01:03:53 UTC
Permalink
Post by J***@fokus.fraunhofer.de
Post by Eike Rathke
Post by Alexander Goetzenstein
Post by Helmut Harnisch
https://unix.stackexchange.com/questions/27054/bin-bash-no-such-file-or-directory
Danke, das hat geholfen. Irgendwie haben sich unsichtbare Zeichen an den
Anfang geschmuggelt -weiÃY der Fuchs, wie.
~~
Post by J***@fokus.fraunhofer.de
Post by Eike Rathke
Vermutlich hast du einen deutschen Kommentar mit Umlauten in die Datei
geschrieben und deinem Editor nicht verboten, beim enkodieren nach UTF-8
ein BOM einzufuegen.
Ein Editor, der das tut, kann auf UNIX als defekt eingestuft werden.
Keineswegs, siehe <https://www.unicode.org/faq/utf_bom.html#bom4>

JFTR: ein NUA, der UTF-8 ausspuckt, und das dreisterweise auch noch
falsch deklariert, ist VOELLIG KAPUTTER SCHROTT:

| Content-Type: text/plain; charset=ISO-8859-1
| Content-Transfer-Encoding: 8bit
| X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
Post by J***@fokus.fraunhofer.de
UTF-8 hat keine Byte-order, es ist Oktett-basiert.
Das ist hier VOELLIG wurscht: ein BOM ist definiert und zulaessig.

Sowohl fuer Dich wie auch den OP gilt: PEBKAC!

Stefan
Michael Bäuerle
2019-11-08 09:00:08 UTC
Permalink
Post by Stefan Kanthak
Post by J***@fokus.fraunhofer.de
Post by Eike Rathke
[...]
Vermutlich hast du einen deutschen Kommentar mit Umlauten in die Datei
geschrieben und deinem Editor nicht verboten, beim enkodieren nach UTF-8
ein BOM einzufuegen.
Ein Editor, der das tut, kann auf UNIX als defekt eingestuft werden.
Keineswegs, siehe <https://www.unicode.org/faq/utf_bom.html#bom4>
Jörg hat aber schon Recht, dass BOMs als Standardeinstellung meistens
problematisch sind. Man sollte IMHO die Erzeugung von BOMs explizit
aktivieren müssen.

Für die allermeisten Fälle braucht man BOMs nicht, z.B. beim Transport
von Text via Mail/News mit MIME (wo entsprechende Metadaten separat
übertragen werden können).
Bei Textdateien auf einem USB-Stick können BOMs aber durchaus Sinn
machen.
Stefan Kanthak
2019-11-08 09:55:41 UTC
Permalink
Post by Michael Bäuerle
Post by Stefan Kanthak
Post by J***@fokus.fraunhofer.de
Post by Eike Rathke
[...]
Vermutlich hast du einen deutschen Kommentar mit Umlauten in die Datei
geschrieben und deinem Editor nicht verboten, beim enkodieren nach UTF-8
ein BOM einzufuegen.
Ein Editor, der das tut, kann auf UNIX als defekt eingestuft werden.
Keineswegs, siehe <https://www.unicode.org/faq/utf_bom.html#bom4>
Jörg hat aber schon Recht, dass BOMs als Standardeinstellung meistens
problematisch sind.
Keineswegs, bzw. nur bei PEBKAC, der "use the right tool for the job"
nicht beachtet.

Siehe <https://www.unicode.org/faq/utf_bom.html#bom5>
Post by Michael Bäuerle
Man sollte IMHO die Erzeugung von BOMs explizit aktivieren müssen.
Welcher Trottel hat nochmal UTF-8 als Standardkodierung fuer UNIX,
Linux oder *BSD festgelegt?
Post by Michael Bäuerle
Für die allermeisten Fälle braucht man BOMs nicht, z.B. beim Transport
von Text via Mail/News mit MIME (wo entsprechende Metadaten separat
übertragen werden können).
Joerg hat dummerweise gerade das Gegenteil gezeigt: der von ihm
als NUA missbrauchte DEFEKTE SCHROTT deklariert ISO-8859-1 in den
Metadaten, kodiert aber UTF-8!

Stefan
Christian Garbs
2019-11-08 15:23:31 UTC
Permalink
Mahlzeit!
Post by Stefan Kanthak
Welcher Trottel hat nochmal UTF-8 als Standardkodierung fuer UNIX,
Linux oder *BSD festgelegt?
Ist das inzwischen tatsächlich Standard?

Zumindest Debian kommt erstmal nur mit LANG=C daher, alles andere sind
Admineinstellungen und ggf. erstmal nachzuinstallieren.
Post by Stefan Kanthak
Post by Michael Bäuerle
Für die allermeisten Fälle braucht man BOMs nicht, z.B. beim Transport
von Text via Mail/News mit MIME (wo entsprechende Metadaten separat
übertragen werden können).
Joerg hat dummerweise gerade das Gegenteil gezeigt: der von ihm
als NUA missbrauchte DEFEKTE SCHROTT deklariert ISO-8859-1 in den
Metadaten, kodiert aber UTF-8!
Der Header wird auch nicht korrekter, wenn im Body noch ein BOM steckt.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Wie würden Stühle aussehen, wenn wir die Kniescheiben hinten hätten?
Stefan Kanthak
2019-11-08 22:47:47 UTC
Permalink
Post by Christian Garbs
Mahlzeit!
Prost!
Post by Christian Garbs
Post by Stefan Kanthak
Welcher Trottel hat nochmal UTF-8 als Standardkodierung fuer UNIX,
Linux oder *BSD festgelegt?
Ist das inzwischen tatsächlich Standard?
Zumindest im Dateisystem ist UTF-8 Standard, wenn Datei- und Verzeichnis-
namen Zeichen jenseits von ASCII verpasst bekommen.
Post by Christian Garbs
Zumindest Debian kommt erstmal nur mit LANG=C daher, alles andere sind
Admineinstellungen und ggf. erstmal nachzuinstallieren.
Sobald Du Zeichen jenseits von ASCII verwendest schalten EINIGE
Programme (insbesonder Editoren, Mail- und News-Clients) auf UTF-8 um.
Speichere doch mal Dein eigenes Posting in eine Datei und sieh nach,
welche Kodierung Dein NUA verwendet.
Sieh in den Quelltext-Repositories von *BSD, GNU/Linux, Google, Mozilla,
Apple etc. nach: wenn Du dort eine Datei mit nicht-ASCII-Zeichen findest,
dann ist sie typischerweise in UTF-8 kodiert ... mal mit BOM, mal ohne.
Post by Christian Garbs
Post by Stefan Kanthak
Post by Michael Bäuerle
Für die allermeisten Fälle braucht man BOMs nicht, z.B. beim Transport
von Text via Mail/News mit MIME (wo entsprechende Metadaten separat
übertragen werden können).
Joerg hat dummerweise gerade das Gegenteil gezeigt: der von ihm
als NUA missbrauchte DEFEKTE SCHROTT deklariert ISO-8859-1 in den
Metadaten, kodiert aber UTF-8!
Der Header wird auch nicht korrekter, wenn im Body noch ein BOM steckt.
Richtig. Das Fehlen des BOM habe ich auch nicht bemaengelt!
Sein NUA spuckt UTF-8 aus (siehe oben: vermutlich automatisch), gibt
aber eine andere Kodierung in den Kopfzeilen an: die linke Hand des
Teufels weiss nicht, was die rechte macht!

Stefan
David Seppi
2019-11-09 16:21:31 UTC
Permalink
Post by Stefan Kanthak
Sein NUA spuckt UTF-8 aus (siehe oben: vermutlich automatisch), gibt
aber eine andere Kodierung in den Kopfzeilen an: die linke Hand des
Teufels weiss nicht, was die rechte macht!
Sein NUA spuckt ISO-8859-1 aus und deklariert das auch so.
Fehlerhaft war hingegen die Beibehaltung der UTF-8-Codierung des von ihm
zitierten Textes, anstatt dieses auf ISO-8859-1 umzucodieren oder im
ganzen Posting (deklariertes) UTF-8 zu verwenden.
--
David Seppi
1220 Wien
Eike Rathke
2019-11-09 01:52:19 UTC
Permalink
Post by Stefan Kanthak
Welcher Trottel hat nochmal UTF-8 als Standardkodierung fuer UNIX,
Linux oder *BSD festgelegt?
Und welches Text-Encoding haettest du stattdessen als
Standard-Uebereinkunft genommen?

Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
Stefan Kanthak
2019-11-09 23:00:44 UTC
Permalink
Post by Eike Rathke
Post by Stefan Kanthak
Welcher Trottel hat nochmal UTF-8 als Standardkodierung fuer UNIX,
Linux oder *BSD festgelegt?
Und welches Text-Encoding haettest du stattdessen als
Standard-Uebereinkunft genommen?
Eines, bei dem ein "Leser" in Abwesenheit eines BOM oder einer
Zeichensatzdeklaration NICHT raten muss, um welche Kodierung
es sich handeln koennte.

Stefan
Eike Rathke
2019-11-10 13:30:47 UTC
Permalink
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
Welcher Trottel hat nochmal UTF-8 als Standardkodierung fuer UNIX,
Linux oder *BSD festgelegt?
Und welches Text-Encoding haettest du stattdessen als
Standard-Uebereinkunft genommen?
Eines, bei dem ein "Leser" in Abwesenheit eines BOM oder einer
Zeichensatzdeklaration NICHT raten muss, um welche Kodierung
es sich handeln koennte.
Tja, da gibt es nur eines: UTF-32
Belegt dann fuer ASCII Texte die vierfache Menge an Speicherplatz und
fuer alles im Unicode BMP immer noch die doppelte Menge, kann nicht mit
Standard-Tools bearbeitet werden, aber du haettest dann Gewissheit.
Tolle Wurst.

Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
Ralph Aichinger
2019-11-10 13:57:21 UTC
Permalink
Post by Eike Rathke
Post by Stefan Kanthak
Eines, bei dem ein "Leser" in Abwesenheit eines BOM oder einer
Zeichensatzdeklaration NICHT raten muss, um welche Kodierung
es sich handeln koennte.
Tja, da gibt es nur eines: UTF-32
Belegt dann fuer ASCII Texte die vierfache Menge an Speicherplatz und
fuer alles im Unicode BMP immer noch die doppelte Menge, kann nicht mit
Standard-Tools bearbeitet werden, aber du haettest dann Gewissheit.
Warum ist das bei UTF-32 so? Und nicht z.B. bei UTF-8? Auch 32 Bit reichen
nicht mehr aus um alle Unicode-Zeichen zu kodieren, und woher weiß man, daß
man UTF-32 und nicht was anderes vor sich hat?

Verwendet UTF-32 überhaupt irgendjemand in der Praxis?

Sinnvoller wäre doch, langsam alles auf UTF-8 zu migrieren, das sich doch
für die Netzwerkübertragung weitgehend durchgesetzt hat. Letztendlich bräuchte
man nur mehr die lokalen Windows-Speicherformate (UTF-16 und UTF-8 gemischt?)
auf UTF-8 portieren?

/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
Michael Bäuerle
2019-11-10 14:27:22 UTC
Permalink
[UTF-32]
Auch 32 Bit reichen
nicht mehr aus um alle Unicode-Zeichen zu kodieren,
Doch, dafür werden nur 24-Bit benötigt:
Letzter Unicode-Codepoint ist U+10FFFF.
Ralph Aichinger
2019-11-10 14:31:40 UTC
Permalink
Post by Michael Bäuerle
[UTF-32]
Auch 32 Bit reichen
nicht mehr aus um alle Unicode-Zeichen zu kodieren,
Letzter Unicode-Codepoint ist U+10FFFF.
Mist, sorry, ich hab es mit UTF-16 und 16 Bit verwechselt.

/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
Eike Rathke
2019-11-10 14:34:43 UTC
Permalink
Post by Ralph Aichinger
Post by Eike Rathke
Post by Stefan Kanthak
Eines, bei dem ein "Leser" in Abwesenheit eines BOM oder einer
Zeichensatzdeklaration NICHT raten muss, um welche Kodierung
es sich handeln koennte.
Tja, da gibt es nur eines: UTF-32
Belegt dann fuer ASCII Texte die vierfache Menge an Speicherplatz und
fuer alles im Unicode BMP immer noch die doppelte Menge, kann nicht mit
Standard-Tools bearbeitet werden, aber du haettest dann Gewissheit.
Warum ist das bei UTF-32 so? Und nicht z.B. bei UTF-8?
Was ist was wie?
Post by Ralph Aichinger
Auch 32 Bit reichen
nicht mehr aus um alle Unicode-Zeichen zu kodieren,
Seit wann das denn nicht? Bislang ist Unicode bis U+10FFFF definiert.
Und danach waere auch noch jede Menge Platz.
Post by Ralph Aichinger
und woher weiß man, daß
man UTF-32 und nicht was anderes vor sich hat?
Eben. Das muss schon als Standard-Uebereinkunft angenommen werden. Und
natuerlich auch ob BE (BigEndian) oder LE (LittleEndian). Sonst halt
wieder durch ein BOM :-D
Post by Ralph Aichinger
Verwendet UTF-32 überhaupt irgendjemand in der Praxis?
In-memory manchmal, wenn es nicht auf Speichermangel ankommt, und wenn
Daten sowieso komprimiert werden laesst sich das auch gut wegschreiben.
Als rohes unkomprimiertes Text-Encoding eigentlich nicht in freier
Wildbahn.
Post by Ralph Aichinger
Sinnvoller wäre doch, langsam alles auf UTF-8 zu migrieren, das sich doch
für die Netzwerkübertragung weitgehend durchgesetzt hat. Letztendlich bräuchte
man nur mehr die lokalen Windows-Speicherformate (UTF-16 und UTF-8 gemischt?)
auf UTF-8 portieren?
Windows von sich aus macht kein UTF-8, nur UTF-16LE, und im schlimmsten
Fall so Krankheiten wie Windows-1252. Programme koennen davon ab fuer
ihre Daten natuerlich ein anderes Encoding waehlen. Windows ab 10 kann
angeblich dazu ueberredet werden, UTF-8 zu benutzen; viel Spass damit.

Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
Ralph Aichinger
2019-11-10 14:38:52 UTC
Permalink
Post by Eike Rathke
Seit wann das denn nicht? Bislang ist Unicode bis U+10FFFF definiert.
Und danach waere auch noch jede Menge Platz.
Post by Ralph Aichinger
Sinnvoller wäre doch, langsam alles auf UTF-8 zu migrieren, das sich doch
für die Netzwerkübertragung weitgehend durchgesetzt hat. Letztendlich bräuchte
man nur mehr die lokalen Windows-Speicherformate (UTF-16 und UTF-8 gemischt?)
auf UTF-8 portieren?
Windows von sich aus macht kein UTF-8, nur UTF-16LE,
Auch bei so Sachen wie Python-Programmen oder ähnlichem das aus der
Open-Source-Welt portiert worden ist?
Post by Eike Rathke
und im schlimmsten
Fall so Krankheiten wie Windows-1252. Programme koennen davon ab fuer
ihre Daten natuerlich ein anderes Encoding waehlen. Windows ab 10 kann
angeblich dazu ueberredet werden, UTF-8 zu benutzen; viel Spass damit.
Naja, dann besteht ja noch Hoffnung ;)

/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
Stefan Kanthak
2019-11-10 14:29:24 UTC
Permalink
Post by Ralph Aichinger
Post by Eike Rathke
Post by Stefan Kanthak
Eines, bei dem ein "Leser" in Abwesenheit eines BOM oder einer
Zeichensatzdeklaration NICHT raten muss, um welche Kodierung
es sich handeln koennte.
Tja, da gibt es nur eines: UTF-32
Belegt dann fuer ASCII Texte die vierfache Menge an Speicherplatz und
fuer alles im Unicode BMP immer noch die doppelte Menge, kann nicht mit
Standard-Tools bearbeitet werden, aber du haettest dann Gewissheit.
Warum ist das bei UTF-32 so?
WEIL ES NICHT SO IST!
Dein Vorposter schreibt (mit Ausnahme seiner ersten Aussage) BLOEDSINN!
Post by Ralph Aichinger
Und nicht z.B. bei UTF-8?
Wie willst Du UTF-8 SICHER von irgendeiner anderen Kodierung unterscheiden?
Post by Ralph Aichinger
Auch 32 Bit reichen nicht mehr aus um alle Unicode-Zeichen zu kodieren,
AUTSCH! Das ist BLOEDSINN.
Alle UTF-* koennen alle Unicode-Zeichen kodieren.
Post by Ralph Aichinger
und woher weiß man, daß man UTF-32 und nicht was anderes vor sich hat?
Per Konvention: der Sender/Erzeuger muss es Dir mitteilen.
Post by Ralph Aichinger
Verwendet UTF-32 überhaupt irgendjemand in der Praxis?
DEIN SPIELZEUG, INTERN!
Und WIMRE auch Solaris ... aber das ist tot,
Steht sogar in der FAQ: <https://www.unicode.org/faq/utf_bom.html#gen5>
Post by Ralph Aichinger
Sinnvoller wäre doch, langsam alles auf UTF-8 zu migrieren, das sich doch
für die Netzwerkübertragung weitgehend durchgesetzt hat.
Welchen Fehler liefert dann beispielsweise
curl https://example.com/shell-script | /bin/sh -

Alternativ: lade eine in UTF-8 erstellte Web-Seite oder oeffne eine in UTF-8
geschriebene Mail, in der ein Shell-Skript enthalten ist. Markiere das Shell-Skript,
schneide es aus, starte (D)einen Editor, fuege es ein und speichere es.
Die Chance, dass die Datei in UTF-8 kodiert wird, ist HOCH.
Und je nach Editor wird ein BOM geschrieben...
Post by Ralph Aichinger
Letztendlich bräuchte man nur mehr die lokalen Windows-Speicherformate
(UTF-16 und UTF-8 gemischt?) auf UTF-8 portieren?
Es gibt mehr als nur DateiINHALTE: UTF-8 ist unter Windows NICHT
gebraeuchlich, es wird nur von gaaaanz wenigen Schnittstellen unterstuetzt.

Stefan
Eike Rathke
2019-11-10 15:19:58 UTC
Permalink
Post by Stefan Kanthak
Post by Ralph Aichinger
Post by Eike Rathke
Post by Stefan Kanthak
Eines, bei dem ein "Leser" in Abwesenheit eines BOM oder einer
Zeichensatzdeklaration NICHT raten muss, um welche Kodierung
es sich handeln koennte.
Tja, da gibt es nur eines: UTF-32
Belegt dann fuer ASCII Texte die vierfache Menge an Speicherplatz und
fuer alles im Unicode BMP immer noch die doppelte Menge, kann nicht mit
Standard-Tools bearbeitet werden, aber du haettest dann Gewissheit.
Warum ist das bei UTF-32 so?
WEIL ES NICHT SO IST!
Dein Vorposter schreibt (mit Ausnahme seiner ersten Aussage) BLOEDSINN!
Ah ja? Ein ASCII-Zeichen in UTF-32 belegt also nicht vier Byte statt
einem? Ein beliebiges Zeichen aus Unicode BMP belegt also nicht vier
Byte statt zwei? Viele Standard-Tools beenden bei einem NULL-Byte also
nicht den String? Kannst du mir Ahnungslosem das bitte GANZ GENAU
erklaeren?

Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
Stefan Kanthak
2019-11-10 15:42:34 UTC
Permalink
Post by Eike Rathke
Post by Stefan Kanthak
Post by Ralph Aichinger
Post by Eike Rathke
Post by Stefan Kanthak
Eines, bei dem ein "Leser" in Abwesenheit eines BOM oder einer
Zeichensatzdeklaration NICHT raten muss, um welche Kodierung
es sich handeln koennte.
Tja, da gibt es nur eines: UTF-32
Belegt dann fuer ASCII Texte die vierfache Menge an Speicherplatz und
fuer alles im Unicode BMP immer noch die doppelte Menge, kann nicht mit
Standard-Tools bearbeitet werden, aber du haettest dann Gewissheit.
Warum ist das bei UTF-32 so?
WEIL ES NICHT SO IST!
Dein Vorposter schreibt (mit Ausnahme seiner ersten Aussage) BLOEDSINN!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Post by Eike Rathke
Ah ja? Ein ASCII-Zeichen in UTF-32 belegt also nicht vier Byte statt
einem? Ein beliebiges Zeichen aus Unicode BMP belegt also nicht vier
Byte statt zwei? Viele Standard-Tools beenden bei einem NULL-Byte also
nicht den String? Kannst du mir Ahnungslosem das bitte GANZ GENAU
erklaeren?
LERNE LESEN!
Und dann das Ganze nochmal sinnentnehmend: Ralphs Frage bezog sich
auf Deine Aussagen "da gibt's nur eines: UTF-32" sowie "aber du
haettest dann Gewissheit" ... die beide falsch sind!

Stefan
Stefan Kanthak
2019-11-10 14:10:03 UTC
Permalink
Post by Eike Rathke
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
Welcher Trottel hat nochmal UTF-8 als Standardkodierung fuer UNIX,
Linux oder *BSD festgelegt?
Und welches Text-Encoding haettest du stattdessen als
Standard-Uebereinkunft genommen?
Eines, bei dem ein "Leser" in Abwesenheit eines BOM oder einer
Zeichensatzdeklaration NICHT raten muss, um welche Kodierung
es sich handeln koennte.
Tja, da gibt es nur eines: UTF-32
BLOEDSINN!
Das ist gleich DOPPELT falsch:

1) UTF-16 hat dieselbe Eigenschaft wie UTF-32: ohne BOM sind beide -BE
<https://www.unicode.org/faq/utf_bom.html#gen6>

2) Dummerweise hilft das einem Leser nicht, der ASCII oder ISO-8859-*
oder UTF-* verarbeiten moechte: bereits um das BOM erkennen zu
koennen muss der zumindest die Laenge des ersten Codepoints richtig
erraten!
<https://www.unicode.org/faq/utf_bom.html#bom4>
Post by Eike Rathke
Tolle Wurst.
AMEN!
Rate mal, welche UTF-* Variante das von Dir missbrauchte Betruebs-
system intern verwendet?

wehret den ahnungslosen Wuersten!
Stefan
Eike Rathke
2019-11-10 15:09:47 UTC
Permalink
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
Welcher Trottel hat nochmal UTF-8 als Standardkodierung fuer UNIX,
Linux oder *BSD festgelegt?
Und welches Text-Encoding haettest du stattdessen als
Standard-Uebereinkunft genommen?
Eines, bei dem ein "Leser" in Abwesenheit eines BOM oder einer
Zeichensatzdeklaration NICHT raten muss, um welche Kodierung
es sich handeln koennte.
Tja, da gibt es nur eines: UTF-32
BLOEDSINN!
Ah ja?
Post by Stefan Kanthak
1) UTF-16 hat dieselbe Eigenschaft wie UTF-32: ohne BOM sind beide -BE
<https://www.unicode.org/faq/utf_bom.html#gen6>
Ja und?

Eine UTF-16 Uebereinkunft ist noch viel kranker als UTF-8, weil viele
Programme einfach nur UCS-2 statt UTF-16 machen.
Post by Stefan Kanthak
2) Dummerweise hilft das einem Leser nicht, der ASCII oder ISO-8859-*
oder UTF-* verarbeiten moechte: bereits um das BOM erkennen zu
koennen muss der zumindest die Laenge des ersten Codepoints richtig
erraten!
<https://www.unicode.org/faq/utf_bom.html#bom4>
256-Byte Encodings wie ISO-8859-* oder Windows-* oder andere Code-Pages
geben immer Probleme, egal ob UTF-8 oder UTF-16 oder UTF-32 als
Standard-Uebereinkunft (ohne BOM) genommen wird.
Post by Stefan Kanthak
Post by Eike Rathke
Tolle Wurst.
AMEN!
Rate mal, welche UTF-* Variante das von Dir missbrauchte Betruebs-
system intern verwendet?
Definiere "intern".
Post by Stefan Kanthak
wehret den ahnungslosen Wuersten!
Stefan
Na du bist ja ein ganz grosser Hecht.

Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
Stefan Kanthak
2019-11-10 15:38:27 UTC
Permalink
Post by Eike Rathke
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
Welcher Trottel hat nochmal UTF-8 als Standardkodierung fuer UNIX,
Linux oder *BSD festgelegt?
Und welches Text-Encoding haettest du stattdessen als
Standard-Uebereinkunft genommen?
Eines, bei dem ein "Leser" in Abwesenheit eines BOM oder einer
Zeichensatzdeklaration NICHT raten muss, um welche Kodierung
es sich handeln koennte.
Tja, da gibt es nur eines: UTF-32
BLOEDSINN!
Ah ja?
JA!
Post by Eike Rathke
Post by Stefan Kanthak
1) UTF-16 hat dieselbe Eigenschaft wie UTF-32: ohne BOM sind beide -BE
<https://www.unicode.org/faq/utf_bom.html#gen6>
Ja und?
Zu dumm zum Denken?
UTF-32 und UTF-16 unterscheiden sich NICHT in Hinsicht auf's Erraten
der korrekten Kodierung!
Post by Eike Rathke
Eine UTF-16 Uebereinkunft ist noch viel kranker als UTF-8, weil viele
Programme einfach nur UCS-2 statt UTF-16 machen.
Wegwerfen!
Genau so wie trn etc., die UTF-8 kodierte Umlaute als ISO-8859-1
deklarieren.
Post by Eike Rathke
Post by Stefan Kanthak
2) Dummerweise hilft das einem Leser nicht, der ASCII oder ISO-8859-*
oder UTF-* verarbeiten moechte: bereits um das BOM erkennen zu
koennen muss der zumindest die Laenge des ersten Codepoints richtig
erraten!
<https://www.unicode.org/faq/utf_bom.html#bom4>
256-Byte Encodings wie ISO-8859-* oder Windows-* oder andere Code-Pages
geben immer Probleme, egal ob UTF-8 oder UTF-16 oder UTF-32 als
Standard-Uebereinkunft (ohne BOM) genommen wird.
Also ist Deine obige Aussage "da gibt's nur eines" FALSCH!
Post by Eike Rathke
Post by Stefan Kanthak
Post by Eike Rathke
Tolle Wurst.
AMEN!
Rate mal, welche UTF-* Variante das von Dir missbrauchte Betruebs-
system intern verwendet?
Definiere "intern".
Kernel!
Siehe beispielsweise kernel_string_utf32()
Post by Eike Rathke
Post by Stefan Kanthak
wehret den ahnungslosen Wuersten!
Stefan
Na du bist ja ein ganz grosser Hecht.
Wieder falsch.
Kommt von Dir noch 'was ausser Dummschwatz?

Stefan
Eike Rathke
2019-11-10 16:20:44 UTC
Permalink
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
BLOEDSINN!
Ah ja?
JA!
Dein Geschrei macht dich nicht sympathischer, aber das musst du ja auch
nicht sein. Wenn du uns denn wenigstens an deiner immensen Weisheit
teilhaben lassen wuerdest.
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
1) UTF-16 hat dieselbe Eigenschaft wie UTF-32: ohne BOM sind beide -BE
<https://www.unicode.org/faq/utf_bom.html#gen6>
Ja und?
Zu dumm zum Denken?
Warum bist du eigentlich so ein Arschloch?
Post by Stefan Kanthak
UTF-32 und UTF-16 unterscheiden sich NICHT in Hinsicht auf's Erraten
der korrekten Kodierung!
Hab ich nie behauptet.
Post by Stefan Kanthak
Post by Eike Rathke
Eine UTF-16 Uebereinkunft ist noch viel kranker als UTF-8, weil viele
Programme einfach nur UCS-2 statt UTF-16 machen.
Wegwerfen!
Ja. Nur dass kaputte UCS-2 statt UTF-16 Programme viel spaeter auffallen
als kaputte Windows-1252 statt UTF-8 Porgramme.
Post by Stefan Kanthak
Genau so wie trn etc., die UTF-8 kodierte Umlaute als ISO-8859-1
deklarieren.
Post by Eike Rathke
Post by Stefan Kanthak
2) Dummerweise hilft das einem Leser nicht, der ASCII oder ISO-8859-*
oder UTF-* verarbeiten moechte: bereits um das BOM erkennen zu
koennen muss der zumindest die Laenge des ersten Codepoints richtig
erraten!
<https://www.unicode.org/faq/utf_bom.html#bom4>
256-Byte Encodings wie ISO-8859-* oder Windows-* oder andere Code-Pages
geben immer Probleme, egal ob UTF-8 oder UTF-16 oder UTF-32 als
Standard-Uebereinkunft (ohne BOM) genommen wird.
Also ist Deine obige Aussage "da gibt's nur eines" FALSCH!
Es ist die beste Wahl wenn nichts dekodiert werden soll.
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
Post by Eike Rathke
Tolle Wurst.
AMEN!
Rate mal, welche UTF-* Variante das von Dir missbrauchte Betruebs-
system intern verwendet?
Definiere "intern".
Kernel!
Siehe beispielsweise kernel_string_utf32()
Na also. Beste Wahl.
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
wehret den ahnungslosen Wuersten!
Stefan
Na du bist ja ein ganz grosser Hecht.
Wieder falsch.
Kommt von Dir noch 'was ausser Dummschwatz?
Ein lautes *PLONK*

Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
Stefan Kanthak
2019-11-10 17:44:09 UTC
Permalink
Post by Eike Rathke
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
BLOEDSINN!
Ah ja?
JA!
Dein Geschrei macht dich nicht sympathischer,
Extra fuer TAUBE NUESSE wie DICH!
Post by Eike Rathke
aber das musst du ja auch nicht sein. Wenn du uns denn
wenigstens an deiner immensen Weisheit teilhaben lassen wuerdest.
Gegen Deine STRUNZENDE Dummheit hilft leider nichts!
Post by Eike Rathke
Post by Stefan Kanthak
Post by Eike Rathke
Post by Stefan Kanthak
1) UTF-16 hat dieselbe Eigenschaft wie UTF-32: ohne BOM sind beide -BE
<https://www.unicode.org/faq/utf_bom.html#gen6>
Ja und?
Zu dumm zum Denken?
Warum bist du eigentlich so ein Arschloch?
Echt nett!

JFTR: Dein Nutzungsrecht fuer Software, an der ich ein Miturheberrecht
habe, has Du gerade verwirkt.
Post by Eike Rathke
Post by Stefan Kanthak
UTF-32 und UTF-16 unterscheiden sich NICHT in Hinsicht auf's Erraten
der korrekten Kodierung!
Hab ich nie behauptet.
Doch, hast Du: "da gibt's nur eines: UTF-32"
Lass Deinen Alterzheimer behandeln!
Post by Eike Rathke
Post by Stefan Kanthak
Post by Eike Rathke
Eine UTF-16 Uebereinkunft ist noch viel kranker als UTF-8, weil viele
Programme einfach nur UCS-2 statt UTF-16 machen.
Wieso nur empfiehlt ICU UTF-16?

<http://userguide.icu-project.org/icufaq>

| What is the performance difference between UTF-8 and UTF-16?
|
| Most of the time, the memory throughput of the hard drive and
| RAM is the main performance constraint. UTF-8 is 50% smaller
| than UTF-16 for US-ASCII, but UTF-8 is 50% larger than UTF-16
| for East and South Asian scripts. There is no memory difference
| for Latin extensions, Greek, Cyrillic, Hebrew, and Arabic.
|
| For processing Unicode data, UTF-16 is much easier to handle.
| You get a choice between either one or two units per character,
| not a choice among four lengths. UTF-16 also does not have
| illegal 16-bit unit values, while you might want to check for
| illegal bytes in UTF-8. Incomplete character sequences in
| UTF-16 are less important and more benign.

Stefan
J***@fokus.fraunhofer.de
2019-11-14 14:19:37 UTC
Permalink
Post by Michael Bäuerle
Post by Stefan Kanthak
Post by J***@fokus.fraunhofer.de
Post by Eike Rathke
[...]
Vermutlich hast du einen deutschen Kommentar mit Umlauten in die Datei
geschrieben und deinem Editor nicht verboten, beim enkodieren nach UTF-8
ein BOM einzufuegen.
Ein Editor, der das tut, kann auf UNIX als defekt eingestuft werden.
Keineswegs, siehe <https://www.unicode.org/faq/utf_bom.html#bom4>
Jörg hat aber schon Recht, dass BOMs als Standardeinstellung meistens
problematisch sind. Man sollte IMHO die Erzeugung von BOMs explizit
aktivieren müssen.
Also würde man dieses Zeichen in Skripten verwenden, dann würde man gegen den
POSIX Standard verstoßen, denn dieses Zeichen ist nicht Bestandteil der Shell
Syntax.

Da kann www.unicode.org schreiben was sie wollen, es ist halt nicht im POSIX
Standard.
--
EMail:***@schily.net (home) Jörg Schilling D-13353 Berlin
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Stefan Kanthak
2019-11-14 17:35:30 UTC
Permalink
Post by J***@fokus.fraunhofer.de
Post by Michael Bäuerle
Post by Stefan Kanthak
Post by J***@fokus.fraunhofer.de
Post by Eike Rathke
[...]
Vermutlich hast du einen deutschen Kommentar mit Umlauten in die Datei
geschrieben und deinem Editor nicht verboten, beim enkodieren nach UTF-8
ein BOM einzufuegen.
Ein Editor, der das tut, kann auf UNIX als defekt eingestuft werden.
Keineswegs, siehe <https://www.unicode.org/faq/utf_bom.html#bom4>
Jörg hat aber schon Recht, dass BOMs als Standardeinstellung meistens
problematisch sind. Man sollte IMHO die Erzeugung von BOMs explizit
aktivieren müssen.
Also würde man dieses Zeichen in Skripten verwenden, dann würde man gegen den
POSIX Standard verstoßen, denn dieses Zeichen ist nicht Bestandteil der Shell
Syntax.
FALCSH, umgekehrt wird's ein Schuh: POSIX verstoesst gegen den UNICODE-Standard,
der ein BOM EXPLIZIT vorsieht, bzw. mehr als ein Byte pro Zeichen!

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1629r0.html>

| From the POSIX standard requiring a single-byte encoding by default, ...

JFTR: das gilt nicht nur fuer Compiler bzw. C[++]-Quelltexte, sondern alle
Textdateien, denn die Definition von "Byte" uebernimmt POSIX vom
ISO-C-Standard.
Post by J***@fokus.fraunhofer.de
Da kann www.unicode.org schreiben was sie wollen, es ist halt nicht im POSIX
Standard.
Da kannst Du schreiben was Du willst, POSIX und UNICODE passen nicht zusammen.

"jeder bitte nur einen Standard"
Stefan
Michael Bäuerle
2019-11-15 10:28:48 UTC
Permalink
[...] POSIX und UNICODE passen nicht zusammen.
Dass C und POSIX gerade nicht vorschreiben, dass Megabytes an Code für
Unicode-Handling vorhanden sein müssen, ist kein Mangel sondern ein
Feature (das hoffentlich erhalten bleibt).

Apple hat bei macOS versucht das konsequent durchzuziehen, bis hin zu
Dateinamen mit Unicode-Semantik. Am Ende haben sie das (seit APFS)
aber wieder aufgegeben.
Es ist so kompliziert und fehleranfällig, siehe auch die Probleme an
anderen Stellen wie Unicode-Of-Death, dass man das je nach Anwendung
ggf. sogar explizit aus dem OS heraushalten möchte.

Stefan Reuther
2019-11-08 16:38:23 UTC
Permalink
Post by Stefan Kanthak
Post by J***@fokus.fraunhofer.de
UTF-8 hat keine Byte-order, es ist Oktett-basiert.
Das ist hier VOELLIG wurscht: ein BOM ist definiert und zulaessig.
Es ging um Skripte, und da ist ein BOM nicht zulässig. Ein Editor, der
automatisch einen setzt, ist also wenigstens unzweckmäßig.

Das gilt auch für das Betriebssystem, dessen Standardeditor mit der
Unsitte begonnen hat, Textdateien mit UTF-8-BOMs zu spicken:

Der Befehl "´╗┐echo" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.


Stefan
Stefan Kanthak
2019-11-08 22:28:53 UTC
Permalink
Post by Stefan Reuther
Post by Stefan Kanthak
Post by J***@fokus.fraunhofer.de
UTF-8 hat keine Byte-order, es ist Oktett-basiert.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Post by Stefan Reuther
Post by Stefan Kanthak
Das ist hier VOELLIG wurscht: ein BOM ist definiert und zulaessig.
Es ging um Skripte, und da ist ein BOM nicht zulässig.
Das schrob Joerg aber nicht!
Extra fuer Dich habe ich seine Aussage noch unterstrichen.
Post by Stefan Reuther
Ein Editor, der automatisch einen setzt, ist also wenigstens unzweckmäßig.
Rate mal, wieso ich "use the right tool for the job" schrob.
Post by Stefan Reuther
Das gilt auch für das Betriebssystem, dessen Standardeditor mit der
DU, Du musst jetzt GAAAANZ stark sein: dieser Editor

0) schreibt NICHT automatisch UTF-8, wenn PEBKAC einen Ümläüt in
eine vorhandene Datei einfuegt.

1) schreibt auch NICHT automatisch UTF-*, wenn PEBKAC ein Unicode-
Zeichen in eine (vorhandene ASCII-)Datei einfuegt ... sondern
der fragt seinen Missbraucher, ob er nach Unicode^WUTF-16LE
umkodieren soll/darf, oder nicht.

2) dieser Editor schreibt auch bei UTF-16LE und UTF-16BE immer ein
BOM!

D.h. der beim OP aufgetretene Fehler kann mit diesem besseren Editor
NICHT passieren!
Wieso informierst Du Dich nicht ueber solche Standard-Software, bevor
Du hier mit Maerchen aufwartest?

Abgesehen davon unterstuetzen die Schnittstellen dieses (hier OFF-
TOPIC) Betruebssystems mit gaaaanz wenigen Ausnahmen kein UTF-8,
sondern nur ASCII/ANSI und UTF-16LE: wer dort also Skripte fuer
dessen ALTEN Kommandoprozessor absichtlich in UTF-8 (genauer:
nicht in ASCII/ANSI) schreibt ist PEBKAC, bzw. missbraucht den falschen
Editor.

Gluecklickerweise koennen die anderen, seit 24 bzw. 14 Jahren mit
diesem Betruebssystem gelieferten Skriptinterpreter neben ASCII/ANSI
auch in UTF-16LE (der nicht nur im Dateisystem verwendeten STANDARD-
Kodierung dieses Betruebssystems) kodierte Skripts korrekt ausfuehren...
Post by Stefan Reuther
Der Befehl "Der Befehl "´╗┐echo" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.echo" ist entweder falsch geschrieben oder
Post by Stefan Reuther
konnte nicht gefunden werden.
Vergleiche diese vielsagende Ausgabe, anhand derer der Fehler SOFORT
erkennbar ist, mit der vom OP wiedergegebenen Fehlermeldung, die
KEINERLEI Anhaltspunkt gibt, sondern eine falsche und den OP
irrefuehrende Desinformation:

| ***@linux-t560b:~> dateinamen-entschaerfen.sh
| /home/alex/bin/dateinamen-entschaerfen.sh: Zeile 1: #!/bin/sh: Datei oder Verzeichnis nicht gefunden

"UNIX is user-friendly, it's just a little picky about who its friends are"

Stefan
Stefan Reuther
2019-11-09 11:12:14 UTC
Permalink
Post by Stefan Kanthak
Post by Stefan Reuther
Post by Stefan Kanthak
Post by J***@fokus.fraunhofer.de
UTF-8 hat keine Byte-order, es ist Oktett-basiert.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Post by Stefan Reuther
Post by Stefan Kanthak
Das ist hier VOELLIG wurscht: ein BOM ist definiert und zulaessig.
Es ging um Skripte, und da ist ein BOM nicht zulässig.
Das schrob Joerg aber nicht!
Extra fuer Dich habe ich seine Aussage noch unterstrichen.
"BYTE ORDER MARK" ist ein Name des Unicode-Zeichens U+FEFF, auch dann,
wenn man es UTF-8-codiert. Kann man mögen oder nicht, für sinnlos halten
oder nicht, ändert aber nichts an der Tatsache, dass das so ist, und
dass das Zeichen unter diesem Namen zur Markierung von UTF-8-Dateien
eingesetzt wird.
Post by Stefan Kanthak
Post by Stefan Reuther
Der Befehl "Der Befehl "´╗┐echo" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.echo" ist entweder falsch geschrieben oder
Post by Stefan Reuther
konnte nicht gefunden werden.
Vergleiche diese vielsagende Ausgabe, anhand derer der Fehler SOFORT
erkennbar ist, mit der vom OP wiedergegebenen Fehlermeldung, die
KEINERLEI Anhaltspunkt gibt, sondern eine falsche und den OP
| /home/alex/bin/dateinamen-entschaerfen.sh: Zeile 1: #!/bin/sh: Datei oder Verzeichnis nicht gefunden
"UNIX is user-friendly, it's just a little picky about who its friends are"
Die Ausgabe auf einem Windows-Terminal mit UTF-8-Unterstützung hätte
ähnlich ausgesehen wie die unter Linux. Die Ausgabe auf einem
Linux-Terminal mit deaktivierter UTF-8-Unterstützung hätte ähnlich
ausgesehen wie die unter Windows.

Und Linux hätte die Zeichensuppe korrekt kopiert, das "`" ist im
Original ein "∩", DOS-Zeichensatz sei dank...


Stefan
Loading...