Discussion:
Debian Buster dash und UTF-8 (was: Ist unison ok zur Dateispiegelung?)
(zu alt für eine Antwort)
Helmut Waitzmann
2020-05-31 08:03:23 UTC
Permalink
Ich frage nur, weil Debian /bin/sh früher als bash hatte, heute
Die dash ist zwar massiv schneller, hat aber weniger bashismen.
Dem Dash fehlt vor allem die Fähigkeit, mit UTF-8 umzugehen:


Wer nicht will, dass der Shell UTF-8‐Codepoints in Bytes zerlegt,
ist gut beraten, in Debian Buster «dash» nicht zu benutzen: 

Wenn man in Debian Buster in einem UTF-8‐Locale das Shell‐Kommando


(
for shell in bash dash
do
bash -c -- 'set -x && "$@"' bash \
exec -a sh -- "$shell" -c -- 'printf %s\\n "${#1}"' sh ä
done
)

laufen lässt, erhält man folgende Ausgabe:


+ exec -a sh -- bash -c -- 'printf %s\\n "${#1}"' sh ä
1
+ exec -a sh -- dash -c -- 'printf %s\\n "${#1}"' sh ä
2

Beobachtung:

Der als «sh» gestartete Bash (d. h. in POSIX‐Betriebsart) sieht
das UTF-8‐Zeichen «ä» als 1 Codepoint, während der als «sh»
gestartete Dash dasselbe «ä» als 2 Bytes sieht. 

Folgerung:

Dash erfasst in einem UTF-8‐Locale UTF-8‐Zeichen nicht als
Codepoints sondern als Byte‐Folge. 

Folgerung für mich:  Vor die Entscheidung gestellt, ob ich lieber
einen schnellen nicht utf-8‐fähigen Shell (Dash) oder lieber einen
langsamen utf-8‐fähigen Shell (Bash) laufen lasse, entscheide ich
mich für den langsamen Shell, weil ich ein UTF-8‐Locale betreiben
will. 

Erklärung zum oben angeführten Bash‐Kommando: 


exec -a sh -- bash -c -- 'printf %s\\n "${#1}"' sh ä

ruft einen «bash» unter dem Namen «sh» auf, ähnlich, wie wenn
beispielsweise «/bin/sh» ein symbolic link auf «bash» wäre. 

Entsprechend ruft


exec -a sh -- dash -c -- 'printf %s\\n "${#1}"' sh ä

einen «dash» als «sh» auf, ähnlich, als wäre «/bin/sh» ein
symbolic link auf «dash». 

Vorschlag: Crosspost & Followup-To: de.comp.os.unix.shell
Juergen Ilse
2020-05-31 16:01:20 UTC
Permalink
Hallo,
Post by Helmut Waitzmann
Wer nicht will, dass der Shell UTF-8‐Codepoints in Bytes zerlegt,
ist gut beraten, in Debian Buster «dash» nicht zu benutzen: 
Wenn man in Debian Buster in einem UTF-8‐Locale das Shell‐Kommando
(
for shell in bash dash
do
exec -a sh -- "$shell" -c -- 'printf %s\\n "${#1}"' sh ä
done
)
Wer in shell-scripts UTF-8 verwendet, dem sollte man den Rechner wegnehmen
und ihn nie mehr naeher als 1 km in die Naehe einer Tastatur lassen.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Helmut Waitzmann
2020-06-01 03:51:26 UTC
Permalink
Post by Juergen Ilse
Wer in shell-scripts UTF-8 verwendet, dem sollte man den Rechner
wegnehmen und ihn nie mehr naeher als 1 km in die Naehe einer
Tastatur lassen.
Quatsch. 

Der POSIX‐Standard
(<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02>)
legt fest, dass ein zu POSIX kompatibles Shell bei

${#parameter}

die Anzahl der Zeichen (characters) zählt. 


Unter «character» versteht der POSIX‐Standard
(<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_87>)
«A sequence of one or more bytes representing a single graphic
symbol or control code».
Juergen Ilse
2020-06-02 10:51:18 UTC
Permalink
Hallo,
Post by Helmut Waitzmann
Post by Juergen Ilse
Wer in shell-scripts UTF-8 verwendet, dem sollte man den Rechner
wegnehmen und ihn nie mehr naeher als 1 km in die Naehe einer
Tastatur lassen.
Quatsch. 
Nein, kein Quatsch. Es gibt nun mal (ob es einem gefaellt oder nicht) shells,
die den aktuellen PROSIX-Standard nicht (oder nicht vollstaendig) erfuellen.
Wer unnoetig die Kompatibilititaet mit solchen shells einschraenkt, sollte
IMHO keine shellscripts schreiben. Und die Verwendung von UTF-8 in shell-
scripts ist i.d.R. unnoetig.
Post by Helmut Waitzmann
Der POSIX‐Standard
(<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02>)
legt fest, dass ein zu POSIX kompatibles Shell bei
${#parameter}
die Anzahl der Zeichen (characters) zählt. 
Nicht alles, was vom Standard erlaubt ist, ist auch eine gute Idee.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Helmut Waitzmann
2020-06-04 08:09:05 UTC
Permalink
Post by Juergen Ilse
Post by Helmut Waitzmann
Post by Juergen Ilse
Wer in shell-scripts UTF-8 verwendet, dem sollte man den Rechner
wegnehmen und ihn nie mehr naeher als 1 km in die Naehe einer
Tastatur lassen.
Quatsch. 
Nein, kein Quatsch. Es gibt nun mal (ob es einem gefaellt oder
nicht) shells, die den aktuellen PROSIX-Standard nicht (oder
nicht vollstaendig) erfuellen.
Sicher gibt es die.  Aber man muss sie ja nicht ohne Not
verwenden, wenn es Alternativen gibt, die den POSIX‐Standard
besser erfüllen. 
Post by Juergen Ilse
Wer unnoetig die Kompatibilititaet mit solchen shells
einschraenkt, sollte IMHO keine shellscripts schreiben. Und die
Verwendung von UTF-8 in shellscripts ist i.d.R. unnoetig.
Das heißt, du startest Utilities vorsichtshalber nur in
Single‐Byte‐Locales oder vergewisserst dich vorher, dass sie keine
Shell‐Funktionalität nutzen, bei der der Dash in einem
UTF-8‐Locale scheitert? 

Ein Beispiel aus der Praxis:  HylaFAX+ 5.5.9 hatte ein Problem bei
beispielsweise dem Locale‐Setting, das man mit den folgenden
Shell‐Kommandos erhält: 

set -a
eval "$( l=POSIX && LANG="$l" LC_ALL="$l" locale )" &&
unset LC_ALL && LC_CTYPE=de_DE.UTF-8
set +a

Das ist ein gemischtes Locale‐Setting, bei denen für alle
Locale‐Kategorien außer LC_CTYPE das POSIX‐Locale verwendet wird,
während LC_CTYPE auf Deutsch mit UTF-8‐Zeichensatz eingestellt
ist.  Dieses Locale‐Setting wurde bei openSUSE Leap 42.3
eingestellt, wenn in der Datei «/etc/sysconfig/language» die
Einstellung

«ROOT_USES_LANG="ctype"»

vermerkt war – eine Einstellung, die aus Sicherheitsgründen
empfohlen wird – und ansonsten das Default‐Locale auf
«de_DE.UTF-8» eingestellt war. 

Bei diesem Locale‐Setting wurden die Telefax‐Versandprotokolle in
deutscher Sprache mit fehlenden Umlauten verfasst, sodass man dann
beispielsweise «Empfnger: …» lesen konnte.  Verantwortlich dafür
waren gewisse POSIX‐Shell‐Skripte, die daran scheiterten, das
Locale‐Setting der Kategorie LC_CTYPE richtig einzustellen.  Dank
der Fähigkeit des POSIX‐Shells, beim Kommando

v='Öse' && printf '%s\n' "${v#?}"

auch in einem UTF-8‐Locale‐Setting die Ausgabe «se» zu erhalten,
konnten die Shell‐Skripte korrigiert werden.  Mit Dash als
vermeintlichem POSIX‐Shell würden sie nicht funktionieren, und man
bekäme in den Telefax‐Versand‐Protokollen weiterhin «Empfnger» zu
lesen. 

Wer die POSIX‐Kompatibilitität einer Linux‐Distribution durch
Verwendung solcher Shells als POSIX‐Shell einschränkt, sollte sich
im Klaren sein, dass die Distribution nur in
Single‐Byte‐Locale‐Settings zum POSIX‐Standard kompatibel ist, und
so ehrlich sein, das auch offen zu kommunizieren, z. B. als FAQ: 

Frage:  Warum verschluckt HylaFAX in seinen Versand‐Protokollen
Umlaute?

Antwort:  Wir ziehen es vor, als POSIX‐Shell Dash zu verwenden,
weil es schneller ist als beispielsweise Bash.  Dass HylaFAX damit
in UTF-8‐Umgebungen auf die Schnauze fällt, nehmen wir in Kauf.

Oder kürzer:  «Schnellix – funktioniert mit UTF‐8 nicht richtig –
das aber rasend schnell!»
Michael Bäuerle
2020-06-04 09:29:32 UTC
Permalink
Post by Juergen Ilse
[...]
Nein, kein Quatsch. Es gibt nun mal (ob es einem gefaellt oder nicht)
shells, die den aktuellen PROSIX-Standard nicht (oder nicht
vollstaendig) erfuellen.
Sicher gibt es die.  Aber man muss sie ja nicht ohne Not verwenden,
wenn es Alternativen gibt, die den POSIX‐Standard besser erfüllen. 
Post by Juergen Ilse
Wer unnoetig die Kompatibilititaet mit solchen shells einschraenkt,
sollte IMHO keine shellscripts schreiben. Und die Verwendung von UTF-8
in shellscripts ist i.d.R. unnoetig.
Das heißt, du startest Utilities vorsichtshalber nur in
Single‐Byte‐Locales oder vergewisserst dich vorher, dass sie keine
Shell‐Funktionalität nutzen, bei der der Dash in einem UTF-8‐Locale
scheitert? 
Ein Beispiel aus der Praxis:  HylaFAX+ 5.5.9 hatte ein Problem bei
beispielsweise dem Locale‐Setting, das man mit den folgenden
Shell‐Kommandos erhält: 
set -a
eval "$( l=POSIX && LANG="$l" LC_ALL="$l" locale )" &&
unset LC_ALL && LC_CTYPE=de_DE.UTF-8
set +a
Das ist ein gemischtes Locale‐Setting, bei denen für alle
Locale‐Kategorien außer LC_CTYPE das POSIX‐Locale verwendet wird,
während LC_CTYPE auf Deutsch mit UTF-8‐Zeichensatz eingestellt ist.
Hier muss man aber fairerweise sagen, dass POSIX [1] fordert, dass
alle Kategorien der Locale die gleiche Codierung verwenden müssen:
|
| If different character sets are used by the locale categories, the
| results achieved by an application utilizing these categories are
| undefined. [...]

Das obige Beispiel funktioniert also, wenn die POSIX-Locale ebenfalls
UTF-8 verwendet (was AFAIK nicht verboten ist). Anderenfalls darf man
kein bestimmtes Ergebnis erwarten, egal mit welcher Shell und mit
welchem Programm.


_______________
[1] <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html>
Helmut Waitzmann
2020-06-05 13:25:11 UTC
Permalink
Post by Michael Bäuerle
Post by Helmut Waitzmann
Ein Beispiel aus der Praxis:  HylaFAX+ 5.5.9 hatte ein Problem
bei beispielsweise dem Locale‐Setting, das man mit den
folgenden Shell‐Kommandos erhält: 
set -a
eval "$( l=POSIX && LANG="$l" LC_ALL="$l" locale )" &&
unset LC_ALL && LC_CTYPE=de_DE.UTF-8
set +a
Das ist ein gemischtes Locale‐Setting, bei denen für alle
Locale‐Kategorien außer LC_CTYPE das POSIX‐Locale verwendet
wird, während LC_CTYPE auf Deutsch mit UTF-8‐Zeichensatz
eingestellt ist.
Hier muss man aber fairerweise sagen, dass POSIX [1] fordert,
dass alle Kategorien der Locale die gleiche Codierung verwenden
|
| If different character sets are used by the locale categories, the
| results achieved by an application utilizing these categories are
| undefined. [...]
Das obige Beispiel funktioniert also, wenn die POSIX-Locale
ebenfalls UTF-8 verwendet (was AFAIK nicht verboten ist).
Anderenfalls darf man kein bestimmtes Ergebnis erwarten, egal mit
welcher Shell und mit welchem Programm.
Ich meine:  Mit einem Locale, das in allen Kategorien außer
LC_CTYPE auf POSIX, in der Kategorie LC_CTYPE aber auf einen
Zeichensatz, der den Zeichensatz der Einstellung POSIX umfasst,
eingestellt ist, sollte es keinen Ärger geben:  Beispielsweise
Fehlermeldungen und andere erzeugte Texte (u. a. die Kategorien
LC_MESSAGES, LC_NUMERIC, LC_MONETARY, LC_TIME) liegen dann alle im
POSIX‐Zeichensatz (müsste dafür nicht der ASCII ausreichen?) und
werden damit vom bei LC_CTYPE eingestellten Zeichensatz
abgedeckt:  Sowohl UTF-8 als auch ISO_8859 umfassen den ASCII.

Das Problem mit Hylafax dabei hatte nicht direkt mit dem
gemischten Locale zu tun, sondern damit, dass versucht wurde, in
einem der beteiligten Shell‐Skripte das Locale so umzustellen,
dass es den gewünschten Zeichensatz benutzt, für deutschsprachige
Protokolle beispielsweise auf ein deutschsprachiges Locale mit
ISO_8859-1‐Zeichensatz: 

LANG="${LANG%%.*}".ISO_8859-1 && export LANG

Das hatte beim oben angeführten gemischten Locale aber für die
Kategorie LC_CTYPE keinen Effekt, weil die Umgebungsvariable
LC_CTYPE unverändert auf de_DE.UTF-8 stand und das Shell‐Skript es
unterließ, danach zu schauen.  (Vermutlich hatte vorher niemand
Hylafax in Verbindung mit «ROOT_USES_LANG="ctype"» ausprobiert,
ehe es ins openSUSE‐Release kam.)

Außerdem bringt ja


LANG="${LANG%%.*}".ISO_8859-1

generell nicht in jedem Fall eine korrekte Locale‐Einstellung
hervor.  Beispielsweise wird im Fall, dass vor dem Umsetzen LANG
auf POSIX steht, danach POSIX.ISO_8859-1 eher kein gültiger
Locale‐Name sein.  => Diese Vorgehensweise ist von vorne herein
zum Scheitern verurteilt. 

Motivation für den Wunsch, das Locale umzustellen, war ein
Wörterbuch, gespeichert in Shell‐Variablen, das je nach
gewünschter Sprache der Versandprotokolle in einer von
verschiedenen Übersetzungen mit entsprechendem Zeichensatz geladen
wurde.  Für die deutsche Fassung war das ISO_8859-1. 

Ich meine, mal irgendwann im POSIX‐Standard gelesen zu haben
(finde es aber gerade nicht mehr), dass das POSIX‐Locale
einerseits, was die Klassifikation der möglichen Zeichen angeht,
den ASCII als Zeichensatz verwendet, also beispielsweise bei den
Buchstaben («[[:alpha:]]») nur die des lateinischen Alphabets
umfasst, andererseits aber auch mit anderen Zahlenwerten in einem
Byte umgehen kann, auch wenn die dann kein gültiges Zeichen aus
dem Zeichensatz darstellen.  Das würde dann bedeuten, dass das
POSIX‐Locale alle Bytes klaglos schluckt, ohne über ungültige
Zeichen zu stolpern.

Zurück zur gescheiterten Locale‐Umstellung bei Hylafax:  Weil das
nicht funktionierte, wurden die Shell‐Skripte umgebaut:  Statt zu
versuchen, die Locale‐Einstellung zu ändern, wurden die
Wörterbucheinträge mittels «iconv» in den Zeichensatz des
vorgefundenen Locales (ermittelt über das Kommando «locale --
charmap») umkodiert.  Das Versandprotokoll wurde dann
quoted‐printable kodiert und an «sendmail» verfüttert.  Die
Quoted‐Printable‐Kodierung wurde ebenfalls per Shell‐Skript
gemacht und musste – mindestens, was das «Subject»‐Vorspannfeld
der E‐Mail‐Nachricht angeht – zeichenweise, nicht byteweise,
geschehen, um UTF-8‐Zeichen nicht zu zersägen.  Das bedeutet
beispielsweise, dass das Shell‐Kommando

v='Öse' && printf '%s' "${v%"${v#?}"}"

von der Zeichenkette «Öse» nicht das erste Byte des in UTF-8
kodierten «Ö» ausgeben darf, sondern das erste Zeichen, das «Ö»,
ausgeben muss, damit der Quoted‐Printable‐Kodierer in dem
Daten‐Strom, den er erhält, alle Bytes des Multi‐Byte‐Zeichens «Ö»
auf einmal erhält und daraus ermitteln kann, wo ihm
Kodierungsgrenzen erlaubt sind und wo nicht.  Dazu ist es nötig,
dass erstens die Locale‐Kategorie «LC_CTYPE» passend eingestellt
ist (das war der Fall) und zweitens der Shell im Fall eines
UTF-8‐Locales mit UTF-8 umgehen kann. 

Am zweiten Punkt scheitert Debian Buster, wie zuvor beschrieben,
wenn der Administrator «/bin/sh» nicht auf beispielsweise Bash
umstellt, sondern auf Dash stehen lässt. 
Michael Bäuerle
2020-06-05 16:46:17 UTC
Permalink
Post by Helmut Waitzmann
Ein Beispiel aus der Praxis:  HylaFAX+ 5.5.9 hatte ein Problem bei
beispielsweise dem Locale‐Setting, das man mit den folgenden
Shell‐Kommandos erhält: 
set -a
eval "$( l=POSIX && LANG="$l" LC_ALL="$l" locale )" &&
unset LC_ALL && LC_CTYPE=de_DE.UTF-8
set +a
Das ist ein gemischtes Locale‐Setting, bei denen für alle
Locale‐Kategorien außer LC_CTYPE das POSIX‐Locale verwendet wird,
während LC_CTYPE auf Deutsch mit UTF-8‐Zeichensatz eingestellt ist.
Hier muss man aber fairerweise sagen, dass POSIX [1] fordert, dass alle
|
| If different character sets are used by the locale categories, the
| results achieved by an application utilizing these categories are
| undefined. [...]
Das obige Beispiel funktioniert also, wenn die POSIX-Locale ebenfalls
UTF-8 verwendet (was AFAIK nicht verboten ist). Anderenfalls darf man
kein bestimmtes Ergebnis erwarten, egal mit welcher Shell und mit
welchem Programm.
Ich meine:  Mit einem Locale, das in allen Kategorien außer LC_CTYPE
auf POSIX, in der Kategorie LC_CTYPE aber auf einen Zeichensatz, der
den Zeichensatz der Einstellung POSIX umfasst, eingestellt ist, sollte
es keinen Ärger geben:  Beispielsweise Fehlermeldungen und andere
erzeugte Texte (u. a. die Kategorien LC_MESSAGES, LC_NUMERIC,
LC_MONETARY, LC_TIME) liegen dann alle im POSIX‐Zeichensatz (müsste
dafür nicht der ASCII ausreichen?)
In [2] heißt es:
|
| The POSIX locale shall contain 256 single-byte characters including
| the characters in Portable Character Set and Non-Portable Control
| Characters, which have the properties listed in LC_CTYPE. [...]

Demnach wären US-ASCII, ISO-8859-1 oder EBCDIC für die POSIX-Locale
möglich.
Nicht aber UTF-8 oder ISO-2022-JP (obwohl beide auf US-ASCII basieren),
die von mir geäußerte Vermutung trifft also offenbar nicht zu.
und werden damit vom bei LC_CTYPE
eingestellten Zeichensatz abgedeckt:  Sowohl UTF-8 als auch ISO_8859
umfassen den ASCII.
Ja, es dürfte wohl in den meisten Fällen so implementiert sein, dass
es sich so verhält. Dass es nicht funktioniert wäre aber auch konform,
falls ich die Norm richtig interpretiere.

Es es sogar erlaubt mehrere POSIX-Locales zu implementieren.
Zitat aus [3] (am Ende):
|
| According to XBD Portable Character Set, the standard requires that
| all supported locales must have the same encoding for <period> and
| <slash>, because these two characters are used within the locale-
| independent pathname resolution sequence. Therefore, it would be an
| error if locale -a listed both ASCII and EBCDIC-based locales, since
| those two encodings do not share the same representation for either
| <period> or <slash>. Any system that supports both environments would
| be expected to provide two POSIX locales, one in either codeset, where
| only the locales appropriate to the current environment can be visible
| at a time. [...]
Das Problem mit Hylafax dabei hatte nicht direkt mit dem gemischten
Locale zu tun, sondern damit, dass versucht wurde, in einem der
beteiligten Shell‐Skripte das Locale so umzustellen, dass es den
gewünschten Zeichensatz benutzt, für deutschsprachige Protokolle
beispielsweise auf ein deutschsprachiges Locale mit
ISO_8859-1‐Zeichensatz: 
LANG="${LANG%%.*}".ISO_8859-1 && export LANG
Das hatte beim oben angeführten gemischten Locale aber für die
Kategorie LC_CTYPE keinen Effekt, weil die Umgebungsvariable LC_CTYPE
unverändert auf de_DE.UTF-8 stand und das Shell‐Skript es unterließ,
danach zu schauen.  (Vermutlich hatte vorher niemand Hylafax in
Verbindung mit «ROOT_USES_LANG="ctype"» ausprobiert, ehe es ins
openSUSE‐Release kam.)
Außerdem bringt ja
LANG="${LANG%%.*}".ISO_8859-1
generell nicht in jedem Fall eine korrekte Locale‐Einstellung hervor. 
Beispielsweise wird im Fall, dass vor dem Umsetzen LANG auf POSIX
steht, danach POSIX.ISO_8859-1 eher kein gültiger Locale‐Name sein.  =>
Diese Vorgehensweise ist von vorne herein zum Scheitern verurteilt. 
Ja. Die Namen der anderen Locales müssen den Zeichensatz auch nicht im
Namen stehen haben.


BTW: Mein Newsreader versucht z.B. bei verfügbarer XSI-Extension nicht
den Locale-Name zu parsen, sondern auf diese Weise den Zeichensatz der
Locale herauszufinden:
|
| nl_langinfo(CODESET);

Da kann aber auch "ISO-8859-1", "iso88591", "iso-885915", "UTF-8" oder
"utf8" zurückkommen. Das dürfte alles gerne präziser genormt sein ...
_______________
[1] <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html>
[2] <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html#tag_06_02>
[3] <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/locale.html>
j***@schily.net
2020-06-15 11:02:04 UTC
Permalink
Ich frage nur, weil Debian /bin/sh fr=C3=BCher als bash hatte, heute=20
als dash. Da sind die Leute reihenweise auf die Nase gefallen:=20
Die dash ist zwar massiv schneller, hat aber weniger bashismen.
Dem Dash fehlt vor allem die F=C3=A4higkeit, mit UTF-8 umzugehen:=20
Davor warne ich seit Jahren....

Ansonsten ist dash der langsamste Shell, den ich kenne, denn Das Einbauen vom
Support für Multy-Byte Lokale würde ihn mindestens 30% langsamer machen und
danach wäre er dann langsamer als bash.

Der von mir auf POSIX erweiterte Bourne Shell (bosh) kommt mit vollem Support
für Multy-Byte und ist dennoch mindestens genauso schnell wie dash. Gäbe es ein
vollständig implementiertes vfork() auf Linux, wäre bosh sogar definitiv immer
schneller als dash. Linux hat zwar das Copy on Write in fork() von SunOS-4.0
nachimplementiert, aber vfork() auf Linux ist nur genauso schnell wie fork(),
während es auf Solaris 3x schneller ist. In der Zukunft ist aber eine
Neuimplementierung des Fiels Splitting geplant und die wird 20% bringen....

Da bosh aber seine volle Rückwärtskompatibilität nicht aufgeben will, gibt es
eine Kompilationsvariante "pbosh" bei der einige der bosh Erweiterungen
fehlen, aber vor Allem das Default Verhalten dem entspricht, was man mit
"bosh -o posix ..." bekommt.

Vor 4 Jahren gab es dazu mal einen Austausch mit den Gentoo Leuten und dort
wurde ich auf ein Papier verwiesen, in dem erklärt wird welche über einen
nackten POSIX Shell hinausgehende Eigenschaften in Gentoo benötigt werden und
dies wurde wohl aus dash abgeleitet. Es ist eigentlich nur das Builtin Kommando
"local" das benötigt wird, um rekursive Funktionsaufrufe sinnvoll nutzen zu
können.

Nachdem ich das in bosh eingebaut hatte (und nachdem einige kleinere Bugs in
bosh beseitigt wurden) läuft "pbosh" problemlos als /bin/sh unter Gentoo.
Wenn Debian nicht auf unbekannten dash Eingenschaftn basiert, sollte daher
auch Debian problemlos mit pbosh als /bin/sh laufen.

Eine andere Alternative als pbosh ist es "bosh" anders zu kompilieren,
nämlich mit:

smake clean
smake COPTX=-DDO_POSIX_SH

Dann macht auch "bosh" automatisch ein "set -o posix" beim Start, wenn die
letzte Pfadnamenkomponente "sh" ist, also für /bin/sh

Wer die fehlende Multy-Byte Unterstützung in dash leid ist, kann ja einfach mal
/bin/sh durch "pbosh" oder "bosh" ersetzen. Ich rate aber vorher eine
Not-Boot-Umgebung anzulegen, für den Fall daß es evt. doch zu Problemen kommt.
--
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/
Christian Schumacher
2020-06-15 15:11:51 UTC
Permalink
Post by j***@schily.net
Vor 4 Jahren gab es dazu mal einen Austausch mit den Gentoo Leuten und dort
wurde ich auf ein Papier verwiesen, in dem erklärt wird welche über einen
nackten POSIX Shell hinausgehende Eigenschaften in Gentoo benötigt werden und
dies wurde wohl aus dash abgeleitet. Es ist eigentlich nur das Builtin Kommando
"local" das benötigt wird, um rekursive Funktionsaufrufe sinnvoll nutzen zu
können.
Nachdem ich das in bosh eingebaut hatte (und nachdem einige kleinere Bugs in
bosh beseitigt wurden) läuft "pbosh" problemlos als /bin/sh unter Gentoo.
Für amd64 wurde bei meinem Gentoo bash als Standard mitgeliefert und
pbosh oder bosh finde ich im portage-Repository garnicht.
--
Gruß
Christian
j***@schily.net
2020-06-15 15:32:11 UTC
Permalink
Post by j***@schily.net
Vor 4 Jahren gab es dazu mal einen Austausch mit den Gentoo Leuten und dort
wurde ich auf ein Papier verwiesen, in dem erklärt wird welche über einen
nackten POSIX Shell hinausgehende Eigenschaften in Gentoo benötigt werden und
dies wurde wohl aus dash abgeleitet. Es ist eigentlich nur das Builtin Kommando
"local" das benötigt wird, um rekursive Funktionsaufrufe sinnvoll nutzen zu
können.
Nachdem ich das in bosh eingebaut hatte (und nachdem einige kleinere Bugs in
bosh beseitigt wurden) läuft "pbosh" problemlos als /bin/sh unter Gentoo.
Für amd64 wurde bei meinem Gentoo bash als Standard mitgeliefert und
pbosh oder bosh finde ich im portage-Repository garnicht.
Interessant, gibt es vielleicht schilytools?

http://sourceforge.net/projects/schilytools/files/
--
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/
Christian Schumacher
2020-06-15 17:01:37 UTC
Permalink
Post by j***@schily.net
Für amd64 wurde bei meinem Gentoo bash als Standard mitgeliefert und
pbosh oder bosh finde ich im portage-Repository garnicht.
Interessant, gibt es vielleicht schilytools?
http://sourceforge.net/projects/schilytools/files/
Leider Fehlanzeige.

Einige der darin zusammengefassten tools sind jedoch vorhanden.
z.B. app-cdr/cdrtools
Latest version available: 3.02_alpha09-r2


Wenn ich das richtig sehe, wartet das Gesamtpaket evtl. schon länger auf
ein ebuild:
https://bugs.gentoo.org/672060
--
Gruß
Christian
j***@schily.net
2020-06-15 18:32:20 UTC
Permalink
Post by Christian Schumacher
Post by j***@schily.net
Interessant, gibt es vielleicht schilytools?
http://sourceforge.net/projects/schilytools/files/
Leider Fehlanzeige.
Einige der darin zusammengefassten tools sind jedoch vorhanden.
z.B. app-cdr/cdrtools
Latest version available: 3.02_alpha09-r2
Wenn ich das richtig sehe, wartet das Gesamtpaket evtl. schon länger auf
https://bugs.gentoo.org/672060
Das ist schade, daß die es in mehr als 1,5 Jahren nicht geschafft haben.

Man kann es natürlich immer noch leicht selbst kompilieren....
--
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/
Ralph Angenendt
2020-06-17 14:40:43 UTC
Permalink
Für amd64 wurde bei meinem Gentoo bash als Standard mitgeliefert und
pbosh oder bosh finde ich im portage-Repository garnicht.
Apropos UTF-8 ...

Ralph
--
Übervaterlandverräter
Loading...