Re: Bourne shell

[Michael Baeuerle]

Gerhard Wolf wrote:
>
> Hallo,
>
> ich habe hier eine "/bin/sh" shell und m�chte eine rc erstellen (wie
> die .bashrc f�r ba...) um ein paar alias(e) zu definieren. Wie heist
> diese rc-datei unter /bin/sh

Meine Bourne-Shell (Heirloom) versteht "alias" nicht und hat auch kein
rc-File. Die interessiert sich nur fuer '/etc/profile' und
'$HOME/.profile' wenn ich das in der Manpage richtig sehe.

Xpost und Fup nach de.comp.os.unix.shell, dort weiss man Bescheid.

Micha

[Sven Mascheck]

Michael Baeuerle wrote:
> Gerhard Wolf wrote:

>> ich habe hier eine "/bin/sh" shell und m�chte eine rc erstellen (wie
>> die .bashrc f�r ba...) um ein paar alias(e) zu definieren.

> Meine Bourne-Shell (Heirloom) versteht "alias" nicht und hat auch kein
> rc-File.

Die allererste Frage ist, um welche Shell es genau geht (der Pfad /bin/sh
sollte immer existieren und sagt nichts aus). Eine Bourne Shell w�re m�glich,
eine bourne-kompatible, "modernere" Shell ist aber viel wahrscheinlicher.
Ein genaues Betrachten der Eintr�ge (/bin/*sh) und der Manpages reicht
normalerweise. Wenn das nicht hilft, testet man auf Features
(Recherche: "whichshell" Brian Hiles/St�phane Chazelas).

Zur jeweiligen Shell ist dann eine Frage hier sinnvoll, wenn die
zugeh�rige Doku das nicht beantworten kann.

[Joerg.S...@fokus.fraunhofer.de]

In article <4B31E000...@stz-e.de>,

Michael Baeuerle <michael....@stz-e.de> wrote:
>Gerhard Wolf wrote:
>>
>> Hallo,
>>

>> ich habe hier eine "/bin/sh" shell und möchte eine rc erstellen (wie
>> die .bashrc für ba...) um ein paar alias(e) zu definieren. Wie heist

>> diese rc-datei unter /bin/sh
>
>Meine Bourne-Shell (Heirloom) versteht "alias" nicht und hat auch kein
>rc-File. Die interessiert sich nur fuer '/etc/profile' und
>'$HOME/.profile' wenn ich das in der Manpage richtig sehe.

Heirloom ist ein schnell portierte Source, die dann nach 2007 nicht mehr
aktualisiert wurde.

Eine aktuelle Version vom Bourne Shell gibt es in den Schily Tools

Siehe auch: http://schilytools.sourceforge.net/bosh.php

Diese Bourne Shell Version gibt es in 2 Varianten:

osh So wie es von OpenSolaris kam, nur richtig portabel gemacht, d.h.
es wird kein sbrk() mehr verwendet und daher läuft diese Version
auch unter Cygwin.

bosh Eine Weiterentwicklung auf Basis vom Bourne Shell.
Hier ist unter Anderem auch der History Editor drin, den ich 1982
konzipoert habe und den ich 1984 in den bsh eingebaut habe.

Darüberhinaus gibt es darin stark erweiterte aliase und es wird bei interaktivem
Shell die Datei $HOME/.shrc ausgewertet.

--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[Michael Baeuerle]

Joerg.S...@fokus.fraunhofer.de wrote:
>
> Eine aktuelle Version vom Bourne Shell gibt es in den Schily Tools
>
> Siehe auch: http://schilytools.sourceforge.net/bosh.php
>
> Diese Bourne Shell Version gibt es in 2 Varianten:
>
> osh So wie es von OpenSolaris kam, nur richtig portabel gemacht, d.h.
> es wird kein sbrk() mehr verwendet und daher läuft diese Version
> auch unter Cygwin.
>
> bosh Eine Weiterentwicklung auf Basis vom Bourne Shell.
> Hier ist unter Anderem auch der History Editor drin, den ich 1982
> konzipoert habe und den ich 1984 in den bsh eingebaut habe.
>
> Darüberhinaus gibt es darin stark erweiterte aliase und es wird bei interaktivem
> Shell die Datei $HOME/.shrc ausgewertet.

Danke für die Info. Werde ich bei Gelegenheit mal anschauen.
Normalerweise benutze ich zwar Bourne Shells nicht mehr (weil nicht
POSIX konform), aber zum testen ist es ja gelegentlich doch ganz nett
sowas auf dem Rechner zu haben.

BTW: Dein smake kommt hier auch öfter zum Einsatz, weil es die Befehle
eingerückt anzeigt. Ich finde das sieht übersichtlicher aus.

[Joerg.S...@fokus.fraunhofer.de]

In article <AABWVJEKmMwAA...@WStation3.stz-e.de>,
Michael Baeuerle <michael....@gmx.net> wrote:

>Joerg.S...@fokus.fraunhofer.de wrote:

>> bosh Eine Weiterentwicklung auf Basis vom Bourne Shell.
>> Hier ist unter Anderem auch der History Editor drin, den ich 1982
>> konzipoert habe und den ich 1984 in den bsh eingebaut habe.
>>
>> Darüberhinaus gibt es darin stark erweiterte aliase und es wird bei interaktivem
>> Shell die Datei $HOME/.shrc ausgewertet.
>
>Danke für die Info. Werde ich bei Gelegenheit mal anschauen.
>Normalerweise benutze ich zwar Bourne Shells nicht mehr (weil nicht
>POSIX konform), aber zum testen ist es ja gelegentlich doch ganz nett
>sowas auf dem Rechner zu haben.

Seit dem Sommer verwende ich diesen Bourne Shell selbst als meinen Login Shell
- nachdem ich nahezu alle Spezialfeatures von meinem "bsh" in den Bourne Shell
portiert habe.

Ziel ist es diesen Shell mal minimal POSIX konform zu machen und dabei aber
gleichzeitig die Erweiterbarkeit über nachladbare Builtins zu erlauben. Also
möglichst wenige Dinge in die Basis, die den Shell immer groß machen würden.

Seit einem Jahr ist er übrigens der 4. Shell geworden, der vfork() statt fork()
verwendet, wenn möglich.

1) csh ~ 1979
2) mein bsh 1985
3) ksh93 ~ 2008
4) Schily Bourne Shell 2014

Alle anderen von mir untersuchten Shells verwenden immer fork() und obwohl
selbst auf Solaris (wo das Copy-on-Write fork() erfunden wurde) vfork() noch ca.
3x schneller ist als fork(). Gemessen auf Solaris: fork() durchschnittlich 0,2ms
vfork() durchschnittlich 0,06ms.

Mein aktueller Umbau von Parser, Interpreter und Jobcontrol hat zudem die
Anzahl der Forks im Mittel um 10% gesenkt. Damit ist er aktuell ca. so schnell
wie ksh93. Allerdings benötigt ksh93 noch ca. 20% weniger Forks und wird dann
durch die sechsfache Größe gebremst. David hat da anscheinend richtig viel Zeit
investiert um Parser und Interpreter zu optimieren.

Aktuell ist übrigens der Schily Bourne Shell geringfügig schneller als "dash",
aber im Gegensatz zu dash unterstützt er multi-byte Zeichen - das kostet
Rechenzeit. Die höhere Geschwindigkeit bei Skripten bekommt er im wesentlichen
durch ca. 20% weniger Forks als dash. Mit Lazy Linking ist er initial nur 115 kB
groß und den History Editor muß er bei Skripten ja nicht nachladen.

WARNING: die aktuelle Version läßt mit eingeschaltetem Jobcontrol den Befehl:

while true; do date; done | uniq -c

nicht mit ^C abbrechen. Da kommt aber in wenigen Tagen ein Fix. So ist das halt
mit größeren Umbauten wie die aktuelle, wo nun:

echo bla | read var; echo $var

"bla" ausgibt wie bei ksh93.

>BTW: Dein smake kommt hier auch öfter zum Einsatz, weil es die Befehle
>eingerückt anzeigt. Ich finde das sieht übersichtlicher aus.

Danke!

[Michael Baeuerle]

Joerg.S...@fokus.fraunhofer.de wrote:
>
> Seit einem Jahr ist er übrigens der 4. Shell geworden, der vfork() statt fork()
> verwendet, wenn möglich.
>
> 1) csh ~ 1979
> 2) mein bsh 1985
> 3) ksh93 ~ 2008
> 4) Schily Bourne Shell 2014
>
> Alle anderen von mir untersuchten Shells verwenden immer fork() und obwohl
> selbst auf Solaris (wo das Copy-on-Write fork() erfunden wurde) vfork() noch ca.
> 3x schneller ist als fork(). Gemessen auf Solaris: fork() durchschnittlich 0,2ms
> vfork() durchschnittlich 0,06ms.
>
> Mein aktueller Umbau von Parser, Interpreter und Jobcontrol hat zudem die
> Anzahl der Forks im Mittel um 10% gesenkt. Damit ist er aktuell ca. so schnell
> wie ksh93. Allerdings benötigt ksh93 noch ca. 20% weniger Forks und wird dann
> durch die sechsfache Größe gebremst. David hat da anscheinend richtig viel Zeit
> investiert um Parser und Interpreter zu optimieren.
>
> Aktuell ist übrigens der Schily Bourne Shell geringfügig schneller als "dash",
> aber im Gegensatz zu dash unterstützt er multi-byte Zeichen - das kostet
> Rechenzeit. Die höhere Geschwindigkeit bei Skripten bekommt er im wesentlichen

> durch ca. 20% weniger Forks als dash. [...]

In den meisten Fällen ist mir die Geschwindigkeit relativ egal. Eine
Ausnahme ist GNU configure. Ich hatte es hier mal erwähnt, dass die ksh
auf meinem alten AIX da gar nicht damit klar kommt. Wenn ich stattdessen
eine bash nehme, dann läuft die Sache deutlich schneller durch. Und bash
ist dafür vmtl. auch nicht die beste Wahl (zu fett für die langsame
Maschine).

Wenn eine andere Shell GNU configure deutlich beschleunigen könnte, dann
wäre das mal ein ernsthafter Grund sie genauer anzuschauen.

[Joerg.S...@fokus.fraunhofer.de]

In article <AABWVLFJEAQAA...@WStation2.stz-e.de>,

Michael Baeuerle <michael....@gmx.net> wrote:

>In den meisten Fällen ist mir die Geschwindigkeit relativ egal. Eine

Das stimt heute allerdings wirklich.

Als ich 1982 den Prototypen meines History Editors geschrieben habe, hatte ich
noch keine Shell Source und mußte das Kommando mit "system()" aufrufen. Das hat
damals über eine Sekunde Overhead bedeutet.

>Ausnahme ist GNU configure. Ich hatte es hier mal erwähnt, dass die ksh

Mich interessiert das Ganze auch eigentlich nur wegen configure auf Cygwin,
da schlafen einem die Füße ein... Das Configure der Schily Tools benötigt auf
Cywin unter VirtualBox etwa eine dreivirtel Stunde mit meinem Bourne Shell
schaffe ich es dort immerhin unter 30 Minuten.

>auf meinem alten AIX da gar nicht damit klar kommt. Wenn ich stattdessen
>eine bash nehme, dann läuft die Sache deutlich schneller durch. Und bash
>ist dafür vmtl. auch nicht die beste Wahl (zu fett für die langsame
>Maschine).

Ich weis nicht was Du da für ein Configure verwendet hast, aber das Schily
Configure basiert absichtlich auf GNU Configure-2.13, weil alles was von der
FSF danach kam ein Albtraum war. So hat ein Configure Lauf mit einem neueren
GNU configure auf meiner Sun3-60 mal über 4 Stunden gedauert, weil das Teil
jeden Einzeltest mit einem separaten Bash Aufruf bedient hat.

Das allerneueste AIX (7.1 - meldet sich mit uname als 1.7 ;-) kommt immer noch
mit ksh88 als Default, hat aber unter "ksh93" einen ksh93t von 2009, das ist
schon sehr Anständig. Der ksh88 ist dort vermutlich weil ksh93 den POSIX Test
nicht besteht.

>Wenn eine andere Shell GNU configure deutlich beschleunigen könnte, dann
>wäre das mal ein ernsthafter Grund sie genauer anzuschauen.

ksh93 benötigt zu Hause mit dem configure von den SchilyTools 35 Sekunden,
während bash dafür 56 Sekunden benötigt.

Der OpenSolaris Bourne Shell benötigt unter diesen Randbedingungen 46 Sekunden,
dash 42 und mein Burne Shell knapp über 40 Sekunden.

Wenn ich dem ksh93 alle UNIX Basiskommandos als Builtin abschalte (Busybox hat
sich diese Idee mal vom ksh93 abgeschaut sagt David ;-), dann ist ksh93 in
etwa so schnell wie mein Bourne Shell, benötigt aber knapp 20% weniger Forks.
Meine Vermutung ist: Das was ksh93 durch einen überarbeiteten Interpreter
durch weniger fork() Aufrufe gewinnt, verliert er wieder durch seine Größe.

Übrigens, wenn man configure (wie bei den Schily Tools und anderer SW von mir)
sauber in eine Make Regel einbettet, dann kommt ja das Cache-File zum Tragen
und bei einer Erweiterung um einen weiteren Test muß es dann nur noch diesen
Test wirklich aufrufen. Ein solcher configure Lauf des Configure Skripts der
Schily Tools benötigt dann mit dem OpenSolaris Bourne Shell 12 Sekunden, mit
dem ksh93 6,5 Sekunden mit bash 16,5 Sekunden und mit dash/bosh 10,5 Sekunden.

Ob ein anderer Shell aktuelle Versionen von GNU autoconf beschleunigen kann,
häng im Wesentlichen davon ab, ob der Code nicht vielleicht bash spezifisch
ist, bzw. wie man das Skript dazu zwingen kann alles durchgängig mit dem
angegebenen Shell durchzuführen.

Für meine Test mit dem auf GNU autoconf-2.13 basierenden Schily Autoconf
verwende ich Kommandozeilen in dieser Art:

CONFIG_SHELL=/opt/schily/bin/bosh /opt/schily/bin/bosh ./configure

Ob bzw. wie man das mit neueren FSF Versionen schafft, habe ich mir noch nicht
angesehen, würde mich aber interessieren.

Aktuell verwende ich übrigens mein configure als Test um sicherzustellen, daß
alle Basisfeatures nach einem Umbau weiter funktionieren und um
sicherzustellen, daß ich durch einen Umbau nichts verlangsamt habe.

[Christian Weisgerber]

On 2015-11-24, Michael Baeuerle <michael....@stz-e.de> wrote:

> In den meisten Fällen ist mir die Geschwindigkeit relativ egal. Eine
> Ausnahme ist GNU configure.

Aber typischerweise wird die Ausführungeschwindigkeit von Shell-Skripten
doch nicht von der Shell bestimmt, sondern von der Laufzeit und
Anzahl der aufgerufenen externen Befehle.

> Ich hatte es hier mal erwähnt, dass die ksh auf meinem alten AIX
> da gar nicht damit klar kommt. Wenn ich stattdessen eine bash nehme,
> dann läuft die Sache deutlich schneller durch.

Das überrascht mich, bietet sich bei GNU-configure-Skripten doch
die ganze Testcompiliererei als wesentlicher Faktor an.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Joerg.S...@fokus.fraunhofer.de]

In article <slrnn5bldi...@lorvorc.mips.inka.de>,
Christian Weisgerber <na...@mips.inka.de> wrote:

>> Ich hatte es hier mal erwähnt, dass die ksh auf meinem alten AIX

>> da gar nicht damit klar kommt. Wenn ich stattdessen eine bash nehme,

>> dann läuft die Sache deutlich schneller durch.
>
>Das überrascht mich, bietet sich bei GNU-configure-Skripten doch

>die ganze Testcompiliererei als wesentlicher Faktor an.

Das ist eine Fehleinschätzung.

ich habe mir mal das Configure vom aktuellen gtar angesehen und darin gibt es
nur ca. 600 Kompileraufrufe, aber massenhaft "Echo Makros", die bei Shells,
die kein printf als eingebautes Kommando haben, alles extrem verlangsamen.

Gemessene Laufzeiten:

OpenSolaris Bourne Shell 94 Sekunden 16600 forks gesamt
bash 56 Sekunden 10400 forks gesamt
Schily Bourne Shell 55 Sekunden 14000 forks gesamt
dash 46 Sekunden 10400 forks gesamt
ksh93 35 Sekunden 6700 forks gesamt

Wenn ich aber das configure shell Skript editiere und folgendes reinschreibe:

as_echo='echo'
as_echo_n='echo -n'
SYSV3=xx
export SYSV3

dann bekomme ich:

OpenSolaris Bourne Shell 68 Sekunden 11100 forks gesamt
Schily Bourne Shell 45 Sekunden 9800 forks gesamt

weil nun fast 5000 Aufrufe des externen Programms /usr/bin/printf entfallen
und als builtin "echo" laufen.

Wie man sieht, ist die Anzahl der Forks der am meisten bestimmende Faktor.

Achja, wenn ich bei ksh93 die vielen eingebauten UNIX Basisprogramme abschalte
bekomme ich das:

ksh93 40 Sekunden 8100 forks gesamt

Wie man sieht, muß ich noch sehen, wie ich bei mir Parser und Interpreter so
umschreibe, daß ich noch ca. 15% der Forks vermeiden kann.

Generell schneiden aber ksh93 und Schily Bourne Shell tendenziell besser ab,
weil sie die einzigen sind, die vfork() statt fork() verwenden wo immer es geht.
Das betrifft ca. 2/3 aller Forks und immerhin ist vfork() auf Solaris trotz
Copy-on-Write bei fork() 6x schneller als fork().

[Martin Vaeth]

Joerg.S...@fokus.fraunhofer.de schrieb:
>>
>>Das überrascht mich, bietet sich bei GNU-configure-Skripten doch

>>die ganze Testcompiliererei als wesentlicher Faktor an.
>
> Das ist eine Fehleinschätzung.

Wie untenstehender Test zeigt:
Nein, es ist keine Fehleinschätzung, zumindest nicht auf Linux.

> Configure vom aktuellen gtar [...] nur ca. 600 Kompileraufrufe

Um das "nur" zu überprüfen, habe ich auf dem Linux-System,
das ich hier gerade zur Hand habe, eine Schleife geschrieben,
die 600 mal ein triviales Testfile mit "cat -" (wie bei ./configure)
produziert, und dieses mit gcc (hier: 4.8.4) ohne Optionen kompiliert.
Die Ergebnisse mit bash, zsh, dash (andere Shells sind hier gerade
nicht installiert) weichen um weniger als 1 Sekunde voneinander ab:

20 Sekunden Kompilierzeit (für das Testskript)
35 Sekunden ./configure (des aktuellen GNU Tar) nach "make distclean",
wobei man 5 Sekunden für spezielle zeitaufwändige Tests (sleep,
futimens, futimensat usw) abziehen sollte.

Und man darf nicht vergessen, dass neben dem Kompilieren
und Forken in ./configure noch eine ganze Menge mehr passiert.

Fazit: Bei den meisten Shells liegt das Einsparpotential
durch Forken in diesem Beispiel bei deutlich unter 30 Prozent,
vielleicht bei 10-20 Prozent. Da man nur ein paar Prozent der
fork()/vfork() tatsächlich einsparen könnte, sind wir vielelleicht
bei 5 Prozent Einsparpotential auf Linux.

> aber massenhaft "Echo Makros", die bei Shells,
> die kein printf als eingebautes Kommando haben

Deswegen haben die meisten modernen Shells printf inzwischen
als "builtin". Dass man durch besonders feature-arme Shells
oder auf Systemen mit extrem langsamem fork() die Laufzeit
künstlich in die Höhe treiben kann, bestreite ich nicht.
Dann muss man das allerdings dem Fehlen der Features dieser
Shells bzw. dem System mit dem langsamen fork() anlasten.

[Juergen Ilse]

Hallo,

Martin Vaeth <mar...@mvath.de> wrote:
> Joerg.S...@fokus.fraunhofer.de schrieb:
>>>Das überrascht mich, bietet sich bei GNU-configure-Skripten doch
>>>die ganze Testcompiliererei als wesentlicher Faktor an.
>> Das ist eine Fehleinschätzung.
> Wie untenstehender Test zeigt:
> Nein, es ist keine Fehleinschätzung, zumindest nicht auf Linux.

Da magst du recht haben. Bei Linux sind IIRC die Laufzeitunterschiede
zwischen fork() und cfork() nicht so granvierend, bei anderen unixoiden
Systemen ist das aber teils deutlich anders.

> Fazit: Bei den meisten Shells liegt das Einsparpotential
> durch Forken in diesem Beispiel bei deutlich unter 30 Prozent,
> vielleicht bei 10-20 Prozent. Da man nur ein paar Prozent der
> fork()/vfork() tatsächlich einsparen könnte, sind wir vielelleicht
> bei 5 Prozent Einsparpotential auf Linux.

Du solltest hier nicht pauschalisieren. Der Unterschied kann auf anderen
unixoiden Systemen u.U. deutlich groesser sein als bei Linux.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Joerg.S...@fokus.fraunhofer.de]

In article <n378bm$7jo$1...@speranza.aioe.org>,
Martin Vaeth <mar...@mvath.de> wrote:

>Nein, es ist keine Fehleinschätzung, zumindest nicht auf Linux.

Doch auch dort, ich habe es gerade auf einem Linux System nachgeprüft.

>> Configure vom aktuellen gtar [...] nur ca. 600 Kompileraufrufe
>

>Um das "nur" zu überprüfen, habe ich auf dem Linux-System,

>das ich hier gerade zur Hand habe, eine Schleife geschrieben,
>die 600 mal ein triviales Testfile mit "cat -" (wie bei ./configure)
>produziert, und dieses mit gcc (hier: 4.8.4) ohne Optionen kompiliert.
>Die Ergebnisse mit bash, zsh, dash (andere Shells sind hier gerade
>nicht installiert) weichen um weniger als 1 Sekunde voneinander ab:
>

>20 Sekunden Kompilierzeit (für das Testskript)

>35 Sekunden ./configure (des aktuellen GNU Tar) nach "make distclean",

>wobei man 5 Sekunden für spezielle zeitaufwändige Tests (sleep,

>futimens, futimensat usw) abziehen sollte.
>
>Und man darf nicht vergessen, dass neben dem Kompilieren
>und Forken in ./configure noch eine ganze Menge mehr passiert.
>
>Fazit: Bei den meisten Shells liegt das Einsparpotential
>durch Forken in diesem Beispiel bei deutlich unter 30 Prozent,
>vielleicht bei 10-20 Prozent. Da man nur ein paar Prozent der

>fork()/vfork() tatsächlich einsparen könnte, sind wir vielelleicht

>bei 5 Prozent Einsparpotential auf Linux.

Dort habe ich mal wieder das configure so editiert, daß statt printf das echo
des Bourne Shells verwendet wird.

Dann bekomme ich mit dem gtar configure:

OpenSolaris Bourne Shell 48 Sekunden
Schily Bourne Shell 37 Sekunden
bash 38 Sekunden

Da es sich um den selben Sourcecode für beide Bourne Shells handelt und sich
die beiden Kompilationsvarianten nur durch ihre Forks unterscheiden, kann man
gut sehen, daß der Schily Bourne Shell nur halb soviel Systemzeit benötigt wie
das Original und damit die verbrauchte gesamt-CPU-Zeit um 25% reduziert wird,
also tatsächlich 11 Sekunden.

Hinweis: das ist in einer Virtuellen Maschine in einem Blade Center, also langsamer
als es auf echter HW wäre.

Allerdings habe ich auch hier eine aktuelle Intel CPU, während meine anderen
Tests unter Solaris mit einem 12 Jahre alten Opteron-System liefen. Aus meinen
Tests mit dem Solaris Laptop weis ich aber schon, daß anscheinend bash unter
neueren Intel CPUs weniger stark langsam ist als auf der Opteron CPU.

Fazit: die Wahl des Shells hat merkliche Auswirkungen auf die Configure
Laufzeit.

[Michael Baeuerle]

Juergen Ilse wrote:
> Martin Vaeth <mar...@mvath.de> wrote:
> > Joerg.S...@fokus.fraunhofer.de schrieb:

> > > Christian Weisgerber wrote:
> > > >
> > > > Das überrascht mich, bietet sich bei GNU-configure-Skripten doch
> > > > die ganze Testcompiliererei als wesentlicher Faktor an.
> > >
> > > Das ist eine Fehleinschätzung.
> >
> > Wie untenstehender Test zeigt:
> > Nein, es ist keine Fehleinschätzung, zumindest nicht auf Linux.
>
> Da magst du recht haben. Bei Linux sind IIRC die Laufzeitunterschiede
> zwischen fork() und cfork() nicht so granvierend, bei anderen unixoiden
> Systemen ist das aber teils deutlich anders.

Es war wie gesagt AIX. Auf GNU/Linux habe ich dieses Verhalten auch noch
nie gesehen, dort benutze ich aber üblicherweise auch keine ksh.

Eventuell hat das hier (zitiert aus [1]) zugeschlagen:
|
| ------------------------------------------------------
| A working Bourne (or compatible) shell, or
| GNU bash version 2.??? (or later)
|
| Necessary when running configure because some /bin/sh shells have bugs
| or disastrous corner-case performance problems. Set CONFIG_SHELL in
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| your environment to your "good" shell prior to running configure/make.
| Sometimes /bin/ksh is sufficient, sometimes it isn't. See the
| host/target specific instructions for your platform, or use bash to be
| sure.
| ------------------------------------------------------

und aus [2]:
|
| David E mentioned that AIX ksh doesn't work, there may be others. I
| get intermitant failures on irix6.5 using ksh, but not on irix6.2.
| OTOH, I use ksh on solaris2 and it always works, hence the hedging
| about ksh. I prefer not to document all the place where it works and
| doesn't because this list will change in subtle ways every time we
| modify the configure files.

... ich hatte seinerzeit nämlich einen GCC compiliert.


________________
[1] <https://gcc.gnu.org/ml/gcc/2003-05/msg02367.html>
[2] <https://gcc.gnu.org/ml/gcc/2003-05/msg02405.html>

[Sven Mascheck]

Joerg.S...@fokus.fraunhofer.de wrote:

> Michael Baeuerle <michael....@stz-e.de> wrote:

>>> ich habe hier eine "/bin/sh" shell und möchte eine rc erstellen (wie
>>> die .bashrc für ba...) um ein paar alias(e) zu definieren. Wie heist
>>> diese rc-datei unter /bin/sh
>>
>>Meine Bourne-Shell (Heirloom) versteht "alias" nicht und hat auch kein
>>rc-File. Die interessiert sich nur fuer '/etc/profile' und
>>'$HOME/.profile' wenn ich das in der Manpage richtig sehe.
>
> Heirloom ist ein schnell portierte Source, die dann nach 2007 nicht mehr
> aktualisiert wurde.
>
> Eine aktuelle Version vom Bourne Shell gibt es in den Schily Tools

Die Motivationen dieser beiden Projekte erscheinen mir unterschiedlich.

Heirloom ("Erbstueck") macht ein ganzes traditionelles Toolkit (~160 tools,
also nicht nur sh), mit den ursprünglichen, historischen Interfaces verfügbar,
quasi zwecks Konservierung. Das ganze mit dem Ziel Verwendbarkeit; böse Bugs
und unnötige Limitierungen wurden also entfernt und UTF-8 erforderlich.

Manches davon zudem in verschiedenen Varianten (UCB, SVR4, SVR4.2, SUSv2, v3).

Siehe http://heirloom.sourceforge.net/man/intro.1.html

Wenn sowas rund läuft, ist das Lastenheft schonmal ganz gut erfüllt.


Zu "schnell portiert": kam mir nicht so vor. Ich habe das damals mitverfolgt
und auch hier und da getestet. Das Changelog reicht von '03 bis '07, einiges
begann aber deutlich früher, z.B. eine Portierung von vi und der SVR2 sh.
Da war aber natürlich mangels Lizenz nicht veröffentlichbar. Mit den
Lizenz-Coups von Caldera und Sun hat sich das geändert.

Sven

[Sven Mascheck]

Joerg.S...@fokus.fraunhofer.de wrote:
> Michael Baeuerle <michael....@stz-e.de> wrote:

>>> ich habe hier eine "/bin/sh" shell und moechte eine rc erstellen (wie
>>> die .bashrc fuer ba...) um ein paar alias(e) zu definieren. Wie heist

>>> diese rc-datei unter /bin/sh
>>
>>Meine Bourne-Shell (Heirloom) versteht "alias" nicht und hat auch kein
>>rc-File. Die interessiert sich nur fuer '/etc/profile' und
>>'$HOME/.profile' wenn ich das in der Manpage richtig sehe.
>
> Heirloom ist ein schnell portierte Source, die dann nach 2007 nicht mehr
> aktualisiert wurde.
>
> Eine aktuelle Version vom Bourne Shell gibt es in den Schily Tools

Die Motivationen dieser beiden Projekte erscheinen mir unterschiedlich.

Heirloom ("Erbstueck") macht ein ganzes traditionelles Toolkit (~160 tools,

also nicht nur sh), mit den urspruenglichen, historischen Interfaces
verfuegbar - sozusagen zwecks Konservierung. Das ganze mit dem Ziel
Verwendbarkeit; boese Bugs und unnoetige Limitierungen wurden also entfernt
und UTF-8 wurde erforderlich.

Manches davon zudem in verschiedenen Varianten (UCB, SVR4, SVR4.2, SUSv2, v3).

Siehe http://heirloom.sourceforge.net/man/intro.1.html

Zu "schnell portiert": kam mir nicht so vor. Ich habe das damals mitverfolgt

und auch hier und da getestet. Das Changelog reicht von '03 bis '07.
Begonnen hat es merklich frueher, z.B. mit einer Portierung von vi und der
SVR2 sh. Das war aber natuerlich mangels Lizenz nicht veroeffentlichbar.
Mit den Lizenz-Coups von Caldera und Sun hat sich dann einiges geaendert.

Sven
[2. post, adhoc-fix fuer utf8-putty-linux-Problem]

[Joerg.S...@fokus.fraunhofer.de]

In article <n3a7rp...@news.in-ulm.de>,
Sven Mascheck <masc...@in-ulm.de> wrote:

>Joerg.S...@fokus.fraunhofer.de wrote:
>> Heirloom ist ein schnell portierte Source, die dann nach 2007 nicht mehr
>> aktualisiert wurde.
>>
>> Eine aktuelle Version vom Bourne Shell gibt es in den Schily Tools
>
>Die Motivationen dieser beiden Projekte erscheinen mir unterschiedlich.

Wenn Du das Projekt "Schily Bourne Shell" (bosh) mit dem Project
"heiloom shell" vergleichst, dann hast Du recht. Wenn Du aber das ansiehst, was
in der Subdirectory "osh" kompiliert wird, dann sieht es anders aus.

Dort findet sich mämlich ein Shell der, mit Ausnahme von einigen bösen Bugs,
identisches Verhalten zum OpenSolaris Bourne Shell zeigt. Allerdings läuft er
auch auf Cygwin und Haiku.

>Heirloom ("Erbstueck") macht ein ganzes traditionelles Toolkit (~160 tools,
>also nicht nur sh), mit den urspruenglichen, historischen Interfaces
>verfuegbar - sozusagen zwecks Konservierung. Das ganze mit dem Ziel
>Verwendbarkeit; boese Bugs und unnoetige Limitierungen wurden also entfernt
>und UTF-8 wurde erforderlich.

Wenn Du jetzt UTF-8 anführst, dann mußt Du etwas falsch verstanden haben.

Seit 1989 hat der Bourne Shell von SVr4 die Eigenschaften, die man für UTF-8
benötigt: Multibyte Fähigkeit. Um 1993 kam dann auf Solaris UTF-8 Unterstützung
in die libc und war damit auch automatisch im Bourne Shell nutzbar.

>Manches davon zudem in verschiedenen Varianten (UCB, SVR4, SVR4.2, SUSv2, v3).
>
>Siehe http://heirloom.sourceforge.net/man/intro.1.html
>
>
>Zu "schnell portiert": kam mir nicht so vor. Ich habe das damals mitverfolgt
>und auch hier und da getestet. Das Changelog reicht von '03 bis '07.

Der Bourne Shell ist ja nicht das Einzige, das in diesem Projekt schnell
portiert wurde. Ich denke da an SCCS, es hat mich 6 Jahre gekostet das OSS zu
machen. Im Jahre 2001 hatte ich ein Abkommen mit SCO, aber kurz vor der
Quellcodeübergabe wurde die Firma von Caldera Linux gekauft und dann war OSS
nicht mehr von Interesse. Also fing ich 2004 an Sun zu überzeugen, was mir dann
im Dezember 2006 auch gelang. Ein Wochenende später habe ich dann auch eine
portable Version herausgebracht - nur aus dem Hause "heirloom" kam schon nach
einem Tag, etwas das angeblich auf Linux funktionieren sollte. Das aber war
unmöglich, weil die Originalsourcen mehrfach ein fclose() für den gleichen FILE
Pointer aufrufen und dies bei Linux zu einem Programmabsturz bei free() führt.
Meine Version war nach dem Wochenende vollständig getestet.

Was ist nun beim Bourne Shell nach meinem Verständnis "schnell gemacht":

- Heirloom sh benötigt weiterhin sbrk() und der Aufwand das zu ändern ist
mindestens 2x so groß wie alle Änderungen, die es im heirloom sh
insgesamt gab. Das vergleichbare schily Projekt "osh" funtioniert auf
Cygwin und anderen Systemen ohne sbrk() (Ich denke da an BeOS und
seine Nachfolger wie Haiku).

- Wenn jemand auf Linux arbeitet und portiert, dann würde ich erwarten,
daß in jobs.c ein Workaround für die Linux Defizite bei wait*()
implementiert wurde. So hat Linux z.B. kein funktionierendes "WNOWAIT".

Wenn man einen schnellen Port macht, dann funktioniert es danach aber
nicht mehr auf anderen Systemen, wie z.B. Solaris oder FreeBSD. Der
Heirloom Shell erzwingt die nicht lösbaren Linux Probleme auf allen
Plattformen, auch auf denen, wo wait*() vollständig implementiert
wurde.

Aus dem Hause "heirloom" gibt es aber seit langem keine Updates mehr.
Interessant ist, daß ich nur ein Projekt kenne, wo sich Leute gefunden haben
mit dem Heirloom Stand anzufangen und weiterzumachen: troff.

>[2. post, adhoc-fix fuer utf8-putty-linux-Problem]

Was soll das sein?

[Joerg.S...@fokus.fraunhofer.de]

In article <n344vv$kmc$1...@news.albasani.net>,

<Joerg.S...@fokus.fraunhofer.de> wrote:
>In article <AABWVLFJEAQAA...@WStation2.stz-e.de>,
>Michael Baeuerle <michael....@gmx.net> wrote:

>>auf meinem alten AIX da gar nicht damit klar kommt. Wenn ich stattdessen
>>eine bash nehme, dann läuft die Sache deutlich schneller durch. Und bash
>>ist dafür vmtl. auch nicht die beste Wahl (zu fett für die langsame
>>Maschine).
>
>Ich weis nicht was Du da für ein Configure verwendet hast, aber das Schily
>Configure basiert absichtlich auf GNU Configure-2.13, weil alles was von der
>FSF danach kam ein Albtraum war. So hat ein Configure Lauf mit einem neueren
>GNU configure auf meiner Sun3-60 mal über 4 Stunden gedauert, weil das Teil
>jeden Einzeltest mit einem separaten Bash Aufruf bedient hat.

So, ich habe am Freitag mal auf einem AIX-7.1 System in der FU einen gcc
installiert, nachdem ich eigenlich darauf gewartet hatte das der Admin einen
aktuellen IBM Kompiler organisiert...

Das eigentliche Problem bei AIX scheint das Filesystem zu sein. Beim Lesen ist
es zwar OK, aber wenn man neue Dateien anlegt, dann liefert es Leistungen, die
ich in den 1980ern gewohnt. war.

Das führt dazu, daß die CPU-Belastung während eines Configure Laufs nur bei ca.
20% liegt. Bei Solaris liege ich um 90%. Anders gesagt, die Laufzeit von
configure auf AIX ist im Wesentlichen Wartezeit auf das Filesystem.

Dennoch mal ein Vergleich:

bash 4:13.736830 real 44.012608 user 26.667802 sys 27% cpu 0+0io 5670pf+0w
bosh 5:55.021130 real 35.509145 user 25.005722 sys 17% cpu 0+0io 5669pf+0w
bosh64 5:57.046087 real 36.943466 user 26.507849 sys 17% cpu 0+0io 5670pf+0w
osh 6:00.205662 real 35.218264 user 24.778440 sys 16% cpu 0+0io 5669pf+0w
osh64 5:59.512325 real 36.645489 user 26.209993 sys 17% cpu 0+0io 5669pf+0w
sh 4:36.977628 real 35.038157 user 24.431784 sys 21% cpu 0+0io 5669pf+0w ksh88
sh 6:03.142332 real 36.063826 user 25.314571 sys 16% cpu 0+0io 5670pf+0w Burne Shell SVr3
ksh93 4:09.319785 real 40.945185 user 27.722155 sys 27% cpu 0+0io 5669pf+0w 93t+ 2009 /64-bit

Was hier verwunderlich ist:

- Warum ist der ineffiziente bash so schnell?
- Warum ist ksh93 auf AIX so ineffizient?
- Warum benötigt "osh" also der Bourne Shell ohne vfork() mehr SYS CPU?

Da ksh93 64bittig kompiliert ist, habe ich auch mal zum Vergleich den Bourne
Shell in vier Kompilationsvarianten getestet.

[Sven Mascheck]

Joerg.S...@fokus.fraunhofer.de wrote:

> Sven Mascheck <masc...@in-ulm.de> wrote:

>>Heirloom ("Erbstueck") macht ein ganzes traditionelles Toolkit (~160 tools,
>>also nicht nur sh), mit den urspruenglichen, historischen Interfaces
>>verfuegbar - sozusagen zwecks Konservierung. Das ganze mit dem Ziel
>>Verwendbarkeit; boese Bugs und unnoetige Limitierungen wurden also entfernt
>>und UTF-8 wurde erforderlich.
>
> Wenn Du jetzt UTF-8 anführst, dann mußt Du etwas falsch verstanden haben.
>
> Seit 1989 hat der Bourne Shell von SVr4 die Eigenschaften, die man für

> UTF-8 [...]

Ich verstehe nicht was Du meinst; da ging's doch um's ganze Toolkit.

[Joerg.S...@fokus.fraunhofer.de]

In article <n3l7br...@news.in-ulm.de>,

Dann solltest Du aber schreiben was Du meinst und nicht nur unverständliche
Andeutungen machen.

Sämtliche Programme von OpenSolaris unterstützen seit Langem (ca. 1993) UTF-8,
daher kann ich in diesem Umfeld keine Erweiterungsleistung erkennen.

[Michael Baeuerle]

Joerg.S...@fokus.fraunhofer.de wrote:
>
> Sämtliche Programme von OpenSolaris unterstützen seit Langem (ca. 1993) UTF-8,
> daher kann ich in diesem Umfeld keine Erweiterungsleistung erkennen.

Nur aus Interesse:
Können die auch mit neuerem Unicode umgehen, oder funktioniert es nur
bis U+FFFF wo damals die Unicode-Welt endete?

Es war damals zumindest anderswo nicht unüblich als interne Darstellung
UCS-2 zu benutzen. Da wäre eine Erweiterung auf UTF-16 dann durchaus
eine nennenswerte Leistung.

[Joerg.S...@fokus.fraunhofer.de]

In article <AABWXscYz5UAA...@WStation3.stz-e.de>,

Michael Baeuerle <michael....@gmx.net> wrote:
>Joerg.S...@fokus.fraunhofer.de wrote:
>>
>> Sämtliche Programme von OpenSolaris unterstützen seit Langem (ca. 1993) UTF-8,
>> daher kann ich in diesem Umfeld keine Erweiterungsleistung erkennen.
>
>Nur aus Interesse:
>Können die auch mit neuerem Unicode umgehen, oder funktioniert es nur
>bis U+FFFF wo damals die Unicode-Welt endete?

Es gibt zwei Ebenen der Implementierung:

- Programme müssen die i18n Funktionen zur Konvertierung zwischen
multi-byte Zeichen und "breiten Zeichen" (32 Bits) unterstützen.
Hier gibt es allerdngs einiges zu beachten, denn leider funktioniert
ein Programm das unter Solaris ohne Probleme läuft nicht immer unter
Mac OS X, da letzteres nach jedem Error einen expliziten Reset möchte.
Das war z.B. eine der Portierungsarbeiten, die ich unternommen habe.

Da die Solaris Programme aus einer Zeit vor UNICODE umgeschrieben
wurden, nämlich 1989 für SVr4, unterstützen sie auch statusbehaftete
Kodierungen wie KOI-8. Dies kostet übrigens Rechenzeit, die andere
Programme die nur UTF-8 verstehen nicht investieren müssen.

- Die Implementierung der Konvertierunfsfunktionen in der libc.
Hier werden einzelne Codierungen gewandelt.

Solange Du z.B. den Schily Bourne Shell auf einer Plattform kompilierst, die
alle 21 Bit von UNICODE unterstützt, wird es auch funktionieren.

>Es war damals zumindest anderswo nicht unüblich als interne Darstellung
>UCS-2 zu benutzen. Da wäre eine Erweiterung auf UTF-16 dann durchaus
>eine nennenswerte Leistung.

Diese Kodierungen sind aber nicht kompatibel mit dem UNIX Paradigma.
Du wirst daher in C nur entweder 32 Bit Breit oder n*8-bit Multibyte finden.

Bei MS hast Du übrigens das Problem, daß ein "wide char" nur 16 Bits faßt und
daher mehr als 16 Bits nur unterstütz werden kann, wenn in der jeweiligen
Applikation Surrogatunterstützung sitzt.

[Michael Baeuerle]

Joerg.S...@fokus.fraunhofer.de wrote:

> Michael Baeuerle wrote:
> > Joerg.S...@fokus.fraunhofer.de wrote:
> > >
> > > Sämtliche Programme von OpenSolaris unterstützen seit Langem (ca. 1993) UTF-8,
> > > daher kann ich in diesem Umfeld keine Erweiterungsleistung erkennen.
> >
> > Nur aus Interesse:
> > Können die auch mit neuerem Unicode umgehen, oder funktioniert es nur
> > bis U+FFFF wo damals die Unicode-Welt endete?
>
> Es gibt zwei Ebenen der Implementierung:
>
> - Programme müssen die i18n Funktionen zur Konvertierung zwischen
> multi-byte Zeichen und "breiten Zeichen" (32 Bits) unterstützen.

Darauf wollte ich hinaus. Wie breit 'wchar_t' ist, ist doch AFAIK schon
immer auch für Unix "implementation defined" gewesen.
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stddef.h.html>
|
| wchar_t
|
| Integer type whose range of values can represent distinct codes for
| all members of the largest extended character set specified among the
| supported locales; [...]

Worauf basiert deine Annahme für ein portables Unix Programm, da würden
immer genau 32 Bit verwendet?

Da hätten damals 16 Bit für eine UCS-2 basierte Locale doch ausgereicht
(UTF-32 gab es noch nicht).

[Joerg.S...@fokus.fraunhofer.de]

In article <AABWXtxXkAQAA...@WStation3.stz-e.de>,

Michael Baeuerle <michael....@gmx.net> wrote:
>> - Programme müssen die i18n Funktionen zur Konvertierung zwischen
>> multi-byte Zeichen und "breiten Zeichen" (32 Bits) unterstützen.
>
>Darauf wollte ich hinaus. Wie breit 'wchar_t' ist, ist doch AFAIK schon
>immer auch für Unix "implementation defined" gewesen.
><http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stddef.h.html>

Wenn Du auf einer Plattform bist, wo das weniger als 32 Bit sind, da mußt Du
halt davon ausgehe, daß nicht alles funktioniert.

Wie gesagt: Bei entsprechendem Support in einem Programm hängt es immer noch
von der Plattform ab ob alles nutzbar ist.