Tabulatur mit echo ausgeben
Stefan Rauch
wie kann man denn ein Tabulatorzeichen in eine echo-Ausgabe einbauen? Wenn
ich
$ echo irgendwas irgendwas
eingebe wird aus dem Tab zwischen den beiden irgendwas ein Leerzeichen.
Versuche mit Formatierungszeichen wie \t haben auch nicht zum Erfolg
geführt. Kann mir jemand sagen, wie das geht?
Viele Grüße
Stefan
Felix von Leitner
$ echo foo\\tbar
foo bar
$ echo 'foo\tbar'
foo bar
$
HTH.
Felix
Alexander Trica
>
> Erst einmal stelle sicher, dass du nicht den evtl. in die Shell mit
> eingebauten echo-Befehl verwendest (wie z.B. in der Bash), indem zu
> explizit /bin/echo aufrufst.
in der bash sollte auch
echo foo$'\x9'bar
funktionieren
mfg
Lex
--
id: Alexander Trica . |
www: http://www.trica.de . http://www.inginf.de |
mail: mailto:l...@trica.de . mailto:l...@inginf.de |
__________________________________________________________________/
Gunnar Ritter
> wie kann man denn ein Tabulatorzeichen in eine echo-Ausgabe einbauen? Wenn
> ich
> $ echo irgendwas irgendwas
Indem Du ein Tabulatorzeichen in das Argument schreibst und es quotest:
$ echo 'irgendwas irgendwas'
Escape-Sequenzen sind bei »echo« nicht wirklich portabel, wenn Du drauf
stehst, solltest Du nicht »echo«, sondern
$ printf 'irgendwas\tirgendwas\n'
verwenden.
Grüße,
Gunnar
Matthias Andree
> > eingebe wird aus dem Tab zwischen den beiden irgendwas ein Leerzeichen.
> > Versuche mit Formatierungszeichen wie \t haben auch nicht zum Erfolg
> > geführt. Kann mir jemand sagen, wie das geht?
>
> $ echo foo\\tbar
> foo bar
> $ echo 'foo\tbar'
> foo bar
Komische Shell.
$ echo foo\\tbar
foo\tbar
$ echo -e foo\\tbar
foo bar
--
Matthias Andree
Felix von Leitner
> > $ echo foo\\tbar
> > foo bar
> > $ echo 'foo\tbar'
> > foo bar
> Komische Shell.
zsh. ;)
Felix
Gunnar Ritter
> Felix von Leitner <usenet-...@fefe.de> writes:
>> $ echo foo\\tbar
>> foo bar
>> $ echo 'foo\tbar'
>> foo bar
>
> Komische Shell.
Eine SUSv2-Shell muß das so machen.
Grüße,
Gunnar
Matthias Andree
> > Komische Shell.
>
> Eine SUSv2-Shell muß das so machen.
Ja. Das sagt mir jetzt, daß SuSE die bash ohne --enable-xpg-echo-default
gebaut hat und die bash kaputte Defaults hat.
--
Matthias Andree
Gunnar Ritter
>> Eine SUSv2-Shell muß das so machen.
>
> Ja. Das sagt mir jetzt, daß SuSE die bash ohne --enable-xpg-echo-default
> gebaut hat
RedHat macht das auch so. Es ist bei Linux-Systemen m.W. üblich.
> und die bash kaputte Defaults hat.
Nein, nicht direkt. Niemand behauptet, daß Linux-Distributionen zu
SUSv2 kompatibel wären, schon gar nicht im XCU-Bereich. In POSIX.2
sind die Auswirkungen von Backslashes ausdrücklich nicht spezifiziert,
vgl. <3AEDB062....@bigfoot.de>. Ehe man aber zu »-e« greift,
sollte man wirklich besser »printf« verwenden.
Grüße,
Gunnar
Frank Fürst
> Matthias Andree <matthia...@gmx.de> wrote:
>
> >> Eine SUSv2-Shell muß das so machen.
> >
> > Ja. Das sagt mir jetzt, daß SuSE die bash ohne --enable-xpg-echo-default
> > gebaut hat
>
> RedHat macht das auch so. Es ist bei Linux-Systemen m.W. üblich.
Debian auch.
Gruß, Frank
Matthias Andree
> Nein, nicht direkt. Niemand behauptet, daß Linux-Distributionen zu
> SUSv2 kompatibel wären, schon gar nicht im XCU-Bereich. In POSIX.2
> sind die Auswirkungen von Backslashes ausdrücklich nicht spezifiziert,
> vgl. <3AEDB062....@bigfoot.de>. Ehe man aber zu »-e« greift,
> sollte man wirklich besser »printf« verwenden.
Wenn die bash schon nicht SUSv2-kompatibel ist, ist es echo bestimmt
auch nicht ;-)
Sieht so aus, als wäre printf der brauchbarere Weg.
--
Matthias Andree
Gunnar Ritter
> Matthias Andree <matthia...@gmx.de> wrote:
>> Wenn die bash schon nicht SUSv2-kompatibel ist, ist es echo bestimmt
>> auch nicht ;-)
>
> Mal 'ne Frage am Rande: Welche Shell *ist* es denn?
Neuere ksh88, sofern vom Hersteller als POSIX.2-kompatibel ausgewiesen;
ksh93. Anders gesagt, bei kommerziellen Unices ist seit Mitte der 90er
i.d.R. eine dabei. In <3AC3B961....@bigfoot.de> steht, wie man
sie finden kann.
> Wobei aber auch wieder zu berücksichtigen ist, dass Standards gewöhnlich
> auf Eigenschaften existierender Systeme aufbauen, in der *Hoffnung*
> einer Verallgemeinerung. Ein Teufelskreis also.
Die Spezifikationen der OpenGroup sind ebenso wie POSIX.2 von denen,
die es beabsichtigten, längst umgesetzt worden. Daß das auf Linux-
und BSD-Systemen nicht der Fall ist, muß differenzierter betrachtet
werden:
· XPG/SUS ist eine System V-lastige Spezifikation, freie Systeme sind
aber eher an historischen BSD-Eigenschaften orientiert. So seltsam
das klingen mag, Argumente an »echo« stellen für manchen einen Aspekt
der Identifikation mit dem System dar - je länger jemand dabei ist,
desto mehr, und Entwickler sind i.d.R. recht lange dabei.
· Eine Zertifizierung ist ein ziemlich langwieriger Vorgang und bezieht
sich zudem auf eine Systemumgebung, nicht auf einzelne Tools. Die
Entwickler freier Software haben also nicht direkt damit zu tun. Ein
typischer Linux-Distributor hätte zudem schon die nächste Version
seines Produktes auf dem Markt, wenn er das Zertifikat erhielte.
Solange er nicht gerade an verknöcherte Behörden verkaufen oder
unbedingt »UNIX« auf seine Verpackung schreiben möchte, hat er von
der fehlenden Zertifizierung auch keine Nachteile. Und wenn der
Anreiz dafür fehlt, gibt es auch keinen Anlaß zur hundertprozentigen
Konformität. So erklärt sich, daß die meisten GNU-Tools nur
teilweise POSIX.2-konform sind; man pickt sich das heraus, was man
für richtig hält und ignoriert den Rest.
· Der Aufwand für eine wirkliche Konformität ist enorm, besonders
wenn man die Lokalisierung mitrechnet. Daß die bash immer wieder
gegen POSIX.2/SUSv2 verstößt, liegt sicher nicht daran, daß ihre
Entwickler zu unfähig wären; sie verwenden ihre Zeit wohl lieber
damit, Features hinzuzufügen.
· Es ist eher langweilig, Tools hundertprozentig standardkonform zu
machen, weil man dafür eine Menge Eigenschaften implementieren muß,
die de facto niemand braucht. Dieser Tatsache ist es u.a. zu
verdanken, daß sich niemand bisher die Mühe gemacht hat, BSD Mail zu
einem POSIX.2-konformen »mailx« zu machen. Für »nail« liegt bei mir
seit über einem halben Jahr eine TODO-Liste herum, zu mehr ist es
aber bisher nicht gekommen, weil weder ich noch irgendjemand anders
die entsprechenden Features zu vermissen scheint. Vom von POSIX.2
vorgeschriebenen »tabs«-Utility wurde m.W. noch überhaupt keine freie
Implementation vorgelegt; wer setzt noch Hardwaretabulatoren auf
Terminals?
Die Austin Group hat die Situation hier nur unwesentlich verbessert,
das einzige nennenswerte Entgegenkommen liegt in der feingliedrigeren
Aufteilung von Basisstandard und Erweiterungen. Ansonsten hat man die
Spezifikationen erweitert, anstatt sie rigoros zusammenzustreichen -
unter diesen Umständen kann ich mir nicht vorstellen, daß POSIX.1-200x
in der Welt der freien Software besser ankommt als seine Vorgänger.
Grüße,
Gunnar
Gunnar Ritter
> Matthias Andree <matthia...@gmx.de> wrote:
>> Wenn die bash schon nicht SUSv2-kompatibel ist, ist es echo bestimmt
>> auch nicht ;-)
>
> Mal 'ne Frage am Rande: Welche Shell *ist* es denn?
Neuere ksh88, sofern vom Hersteller als POSIX.2-kompatibel ausgewiesen;
ksh93. Anders gesagt, bei kommerziellen Unices ist seit Mitte der 90er
i.d.R. eine dabei. In <3AC3B9FC....@bigfoot.de> steht, wie man
Helmut Schellong
> > auch nicht ;-)
>
> Spezifikation leider recht wenig, wenn die diversen in Umlauf befindlichen
> Shells dieser nicht entsprechen. Das ist nicht als Kritik an der SUSv2
> gemeint, eher als Kritik an den nicht-konformen Shells. Wobei aber auch
> wieder zu berücksichtigen ist, dass Standards gewöhnlich auf Eigenschaften
> existierender Systeme aufbauen, in der *Hoffnung* einer Verallgemeinerung.
> Ein Teufelskreis also.
>
> wenn man portabel programmieren will.
Das ist ja furchtbar.
Will/muß man denn bis in alle Ewigkeit sh-kompatibel
programmieren?!
Man kann ja eigentlich alle Shells außer sh wegwerfen, da man
praktisch *(fast) kein* geliefertes Script sieht, das auf andere
Shells als sh abstellt.
Ich finde es grauenvoll, solche Konstruktionen:
case $GHR in; kell*) aaaaa;; *) zzzzz;; esac
zu sehen, nur weil es sh sein muß(?).
Man hat ja nun schon diese Zeile: #!/interpreter
als Unterscheidungsautomatik.
Angesichts dessen dürfte es kein Problem geben.
Es gibt aber doch Probleme, weil Shells, die unter
ein und demselben Pfad zu finden sind, offenbar
(bildlich) 1000 Unterschiede haben.
Damit wird das Konzept #!/interpreter unterlaufen.
#!/bin/sh
#!/bin/ksh
#!/bin/csh
#!/usr/bin/perl
#!/usr/bin/bsh
Das ist eigentlich eine sichere Angelegenheit,
wenn die Shells mit Unterschieden ein Versionskommando
hätten/haben, wie bsh (ver [n|s|o|l]) es hat.
Mit Links zu arbeiten ist eine schlechtere Lösung,
weil sie Undiszipliniertheit dabei nicht verhindert.
Bei großen Script-Projekten (z.B.configure) kann man auch ein
kleines Vorschalt-sh-Script standardmäßig vorsehen.
Das läuft *garantiert* und kann ggf. genaue Hinweise geben.
Ich finde, man sollte ksh93 durchdrücken.
Auf Intel-Plattformen kann man durchaus sogar
bsh verwenden, denn wenn ein Script mit #!.../bsh
oder *.bsh läuft, dann läufts, und zwar sehr gut.
--
Mit freundlichen Grüßen
Helmut Schellong po...@schellong.de po...@schellong.com
http://www.schellong.de http://www.schellong.com
http://home.t-online.de/home/schellong sche...@t-online.de
Gunnar Ritter
> #!/usr/bin/bsh
> Das ist eigentlich eine sichere Angelegenheit,
> wenn die Shells mit Unterschieden ein Versionskommando
> hätten/haben, wie bsh (ver [n|s|o|l]) es hat.
Soso, dann schlage ich mal vor, daß Du mit gutem Beispiel vorangehst
und Dein »bsh«-Programm umbenennst. Unter IRIX wie AIX, zwei recht
weit verbreiteten Unix-Systemen, ist »bsh« nämlich eine gute alte
Bourne-Shell. Und bei RedHat-Linux gibt es auch eine »bsh«, einen
symbolischen Link zur ash. Daß ausgerechnet Du auf Namenskonflikte
aufmerksam macht, ist blanker Hohn. Aber ich gehe mal ohne weitere
Nachforschungen davon aus, daß »bogush« noch für Dich frei ist.
> Ich finde, man sollte ksh93 durchdrücken.
Dann drück mal schön. - So läuft das einfach nicht. Ob Helmut Schellong
aus Bad Salzuflen, leidlich bekannt als Programmierer der schlechtesten
Shell der Welt, nun fordert, man solle irgendetwas »durchdrücken«, ist
für den Rest dieses Universums offensichtlich bedeutungslos.
Grüße,
Gunnar
Gunnar Ritter
> #!/usr/bin/bsh
> Das ist eigentlich eine sichere Angelegenheit,
> wenn die Shells mit Unterschieden ein Versionskommando
> hätten/haben, wie bsh (ver [n|s|o|l]) es hat.
Soso, dann schlage ich mal vor, daß Du mit gutem Beispiel vorangehst
und Dein »bsh«-Programm umbenennst. Unter IRIX wie AIX, zwei recht
weit verbreiteten Unix-Systemen, ist »bsh« nämlich eine gute alte
Bourne-Shell. Und bei RedHat-Linux gibt es auch eine »bsh«, einen
symbolischen Link zur ash. Daß ausgerechnet Du auf Namenskonflikte
aufmerksam machst, ist blanker Hohn. Aber ich gehe mal ohne weitere
Nachforschungen davon aus, daß »bogush« noch für Dich frei ist.
> Ich finde, man sollte ksh93 durchdrücken.
Dann drück mal schön. - So läuft das einfach nicht. Ob Helmut Schellong
Sven Mascheck
> Wie verhält es sich den eigentlich mit der pdksh?
<http://www.cs.mun.ca/~michael/pdksh/>, README und vor allem NOTES.
Felix von Leitner
> > Mal 'ne Frage am Rande: Welche Shell *ist* es denn?
> Neuere ksh88, sofern vom Hersteller als POSIX.2-kompatibel ausgewiesen;
configure ist deshalb so groß, weil sie doppelt benutzte Prüfungen
doppelt expandieren und keine Shell-Funktionen benutzen, mit dem
Hinweis, daß es mal eine /bin/sh gegeben haben soll, die keine
Funktionen kann. Weiß jemand, um welche Shell es sich dabei handeln
soll? Hat sie vielleicht sogar mal jemand gesehen? Oder ist das eine
schlechte Ausrede, weil m4 so grausam ist?
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> wrote:
>
> > #!/usr/bin/bsh
> > Das ist eigentlich eine sichere Angelegenheit,
> > wenn die Shells mit Unterschieden ein Versionskommando
> > hätten/haben, wie bsh (ver [n|s|o|l]) es hat.
>
> Soso, dann schlage ich mal vor, daß Du mit gutem Beispiel vorangehst
> und Dein »bsh«-Programm umbenennst. Unter IRIX wie AIX, zwei recht
> weit verbreiteten Unix-Systemen, ist »bsh« nämlich eine gute alte
> Bourne-Shell. Und bei RedHat-Linux gibt es auch eine »bsh«, einen
> symbolischen Link zur ash.
Das ist wohl so; aber gerade das ist zu kritisieren.
Und 'sh' ist doch weit überwiegend und auch traditionell
die gute alte Bourne-Shell.
Warum wird dann *dafür* ein weiterer *anderer* Name
(zusätzlich) besetzt?!
Und wiederum bei einem bestimmten Linux ist bsh erneut
was anderes. Da sieht dann einer in einem Bourne-Shell-Script
'local' auftauchen - und ist verwirrt.
Daß bsh doch schon belegt ist, hatte ich leider erst
1997 erfahren.
> Daß ausgerechnet Du auf Namenskonflikte
> aufmerksam machst, ist blanker Hohn. Aber ich gehe mal ohne weitere
> Nachforschungen davon aus, daß »bogush« noch für Dich frei ist.
Die Aufstellung hatte ich -vom Prinzip her- gemeint.
Als Name ist bogush nicht so gut - könnte ein Nachname
im englischen oder afrikanischen (bogobogush) Bereich sein.
Aber 'cmdsh' könnte ich mir vorstellen, weil das ein
wesentliches, vorteilhaftes Konzept der bsh andeutet.
> > Ich finde, man sollte ksh93 durchdrücken.
>
> Dann drück mal schön. - So läuft das einfach nicht. Ob Helmut Schellong
> aus Bad Salzuflen, leidlich bekannt als Programmierer der schlechtesten
> Shell der Welt, nun fordert, man solle irgendetwas »durchdrücken«, ist
> für den Rest dieses Universums offensichtlich bedeutungslos.
Es gibt andere Universen, da ist Das Schlechteste der Welt
sehr beliebt, denn so ein prickelndes Kamikaze-Gefühl,
das hat was.
Gunnar Ritter
> configure ist deshalb so groß, weil sie doppelt benutzte Prüfungen
> doppelt expandieren und keine Shell-Funktionen benutzen, mit dem
> Hinweis, daß es mal eine /bin/sh gegeben haben soll, die keine
> Funktionen kann. Weiß jemand, um welche Shell es sich dabei handeln
> soll?
Bourne-Shells vor SVr2 und auf allen BSD-Systemen bis einschließlich
4.3-Reno. Dürfte sich heute praktisch erledigt haben; wer ein solches
System zu anderen als musealen Zwecken betreibt, melde sich.
Grüße,
Gunnar
Gunnar Ritter
>> Soso, dann schlage ich mal vor, daß Du mit gutem Beispiel vorangehst
>> und Dein »bsh«-Programm umbenennst. Unter IRIX wie AIX, zwei recht
>> weit verbreiteten Unix-Systemen, ist »bsh« nämlich eine gute alte
>> Bourne-Shell. Und bei RedHat-Linux gibt es auch eine »bsh«, einen
>> symbolischen Link zur ash.
>
> Das ist wohl so; aber gerade das ist zu kritisieren.
> Und 'sh' ist doch weit überwiegend und auch traditionell
> die gute alte Bourne-Shell.
> Warum wird dann *dafür* ein weiterer *anderer* Name
> (zusätzlich) besetzt?!
Weil »sh« auf IRIX und AIX eine Korn-Shell ist. Nix zusätzlich.
>> Daß ausgerechnet Du auf Namenskonflikte
>> aufmerksam machst, ist blanker Hohn. Aber ich gehe mal ohne weitere
>> Nachforschungen davon aus, daß »bogush« noch für Dich frei ist.
>
> Die Aufstellung hatte ich -vom Prinzip her- gemeint.
> Als Name ist bogush nicht so gut - könnte ein Nachname
> im englischen oder afrikanischen (bogobogush) Bereich sein.
Das ist doch ein ganz anderer Namespace, da kommt es gar nicht zum
Konflikt. Gerade dank des exotischen Anklanges hat »bogush« einen
echten Wiedererkennungswert.
> Aber 'cmdsh' könnte ich mir vorstellen, weil das ein
> wesentliches, vorteilhaftes Konzept der bsh andeutet.
Im Vergleich zum aufregenden Voodoo-Touch von »bogush« klingt das doch
bieder und langweilig.
Grüße,
Gunnar
Stefan Kanthak
Helmut Schellong <sche...@t-online.de> wrote:
[sh auf IRIX & AIX]
>>> Daß ausgerechnet Du auf Namenskonflikte
>>> aufmerksam machst, ist blanker Hohn. Aber ich gehe mal ohne weitere
>>> Nachforschungen davon aus, daß »bogush« noch für Dich frei ist.
>>
>> Die Aufstellung hatte ich -vom Prinzip her- gemeint.
>> Als Name ist bogush nicht so gut - könnte ein Nachname
>> im englischen oder afrikanischen (bogobogush) Bereich sein.
>
> Das ist doch ein ganz anderer Namespace, da kommt es gar nicht zum
> Konflikt. Gerade dank des exotischen Anklanges hat »bogush« einen
> echten Wiedererkennungswert.
>
>> Aber 'cmdsh' könnte ich mir vorstellen, weil das ein
>> wesentliches, vorteilhaftes Konzept der bsh andeutet.
>
> Im Vergleich zum aufregenden Voodoo-Touch von »bogush« klingt das doch
> bieder und langweilig.
Wieso denn "nur" »bogush«?
Ich schlage »rabbish« (beschreibend) oder »marrakesh« (exotisch) vor: Dank
des auf »*r*sh« passenden Namens kann das Ding dann auch etwas weniger
Unheil anrichten.
mfg
Stefan
--
Die unaufgeforderte Zusendung einer Werbemail an Privatleute verstoesst gegen
§1 UWG und §823 I BGB. Beschluss des LG Berlin vom 2.8.1998 (Az: 16 O 201/98)
Helmut Schellong
>
> "Gunnar Ritter" <g...@bigfoot.de> schrieb:
> Helmut Schellong <sche...@t-online.de> wrote:
>
> [sh auf IRIX & AIX]
>
> >> im englischen oder afrikanischen (bogobogush) Bereich sein.
> >
> > Das ist doch ein ganz anderer Namespace, da kommt es gar nicht zum
> > Konflikt. Gerade dank des exotischen Anklanges hat »bogush« einen
> > echten Wiedererkennungswert.
> >
> >> Aber 'cmdsh' könnte ich mir vorstellen, weil das ein
> >> wesentliches, vorteilhaftes Konzept der bsh andeutet.
> >
> > Im Vergleich zum aufregenden Voodoo-Touch von »bogush« klingt das doch
> > bieder und langweilig.
>
> Wieso denn "nur" »bogush«?
> Ich schlage »rabbish« (beschreibend) oder »marrakesh« (exotisch) vor: Dank
> des auf »*r*sh« passenden Namens kann das Ding dann auch etwas weniger
> Unheil anrichten.
bosh (Bosch) oder hsh (h.schellong) sind auch Kandidaten.
Aber Unheil richtet das Ding nicht an, im Gegenteil,
es heilt von Syntax-Vergewaltigung, wie ein guter Heilpraktiker.
Juergen Salk
>>> Eine SUSv2-Shell muß das so machen.
>> Ja. Das sagt mir jetzt, daß SuSE die bash ohne --enable-xpg-echo-default
>> gebaut hat
> RedHat macht das auch so. Es ist bei Linux-Systemen m.W. üblich.
Ist auch nicht weiter schlimm. Wer keine Lust hat, sich eine eigene
bash mit »--enable-usg-echo-default« aka »--enable-xpg-echo-default«
zu bauen, kann es ja auch mit »shopt -s xpg_echo« zur Laufzeit festlegen.
Beste Grüsse - Jürgen
--
Einstein also said: "God does not gamble." thereby denying the -o)
existence of true stochastic processes. So, he clearly did not know /\\
everything, but does that make him stupid? (P.-H. van der Giessen) _\_v
Helmut Schellong
> >> Bleibt dann häufig nur die Besinnung auf den kleinsten gemeinsamen
> >> Nenner, wenn man portabel programmieren will.
> >
> > Das ist ja furchtbar.
> > Will/muß man denn bis in alle Ewigkeit sh-kompatibel
> > programmieren?!
>
> Kollegen per Email ein Skript schicke, und nicht genau weiss, was für ein
> System er verwendet, bzw. was für Shells auf seinem System vorhanden sind,
> bin ich auf der sicheren Seite, wenn es ein Bourne-Skript ist. Und dann
> verwende ich lieber ein oder zweimal ein hässliches Konstrukt, als dass ich
> erst lang und breit erklären muss, auf welchem System das Skript mit
> welcher Shell in welcher Version läuft. Man muss immer davon ausgehen, dass
> viele Unix-User über keine Programmier-Kenntnisse verfügen, und auch nicht
> mal den Unterschied zwischen einer Bourne- oder C-Shell kennen
MUSS man wirklich?
Ich habe mal über die Anzahl von aktuell konkret vorhandenen
Unix-Installationen nachgedacht, und ich komme zu der Schätzung,
daß wohl 999 von 1000 Installationen mindestens eine pdksh
zur Verfügung haben.
Wenn nun auf pdksh-Level programmiert würde und dieser eine
von 1000 Fällen mal einträte, würde eben dieser eine User
'auf den Bauch fallen' - na und.
Denn nur auf diese Weise etablierte sich die 'modernere Zeit'
bei den Shell-Skripten - mit ein wenig Zugzwang.
Falls ich mal die bsh mit Makefile und configure anböte,
wäre configure garantiert für ksh93 geschrieben.
Der Mikroanteil von MusealSys-Usern, die auf den Bauch fielen,
würde mir nicht leid tun.
Allerdings, wenn irgendein Skript ohne Syntax-Verrenkungen
für sh schreibbar wäre, würde auch ich es durchaus bei diesem
Level belassen.
> > Man kann ja eigentlich alle Shells außer sh wegwerfen, da man
> > praktisch *(fast) kein* geliefertes Script sieht, das auf andere
> > Shells als sh abstellt.
>
> wegwerfen. Auf gar keinen Fall. Mindestens 80% meiner Skripte sind für den
> einmaligen oder täglichen Gebrauch auf *einem* System und ich komme eher
> selten wirklich in die Verlegenheit, portabel zu programmieren. Und das
> mach ich dann meistens eh in C++ (gelegentlich Fortran, weil es sich nicht
> immer vermeiden lässt), und die Skripte dienen nur dem Zusammenschalten der
> einzelnen Komponenten. Da komme ich prima mit /bin/sh zurecht, ein bisschen
> awk, ab und zu bc und sed. Ob ich nun z.B. in einer Schleife mit
> i=$(($i + 1)) oder i=`expr $i + 1` hochzähle, ist von der Performance her
> völlig belanglos, denn das sind in meinen Programmen so gut wie nie die
> Flaschenhälse.
> ¹) Ich weiß, diese Argumentation hat auch ihre Tücken (Windows etc.)
Was mich betrifft, ist es so, daß ich mindestens 60% aller
potentiellen C/C++-Programme als bsh-Skript schreibe.
Also so 'richtige große' Arbeitsprogramme.
Das geht 3-5-fach schneller und ist danach wesentlich kleiner
und viel besser und schneller pflegbar.
Das geht halbwegs mit ksh, aber so richtig *nur* mit bsh,
und es war auch mein Ziel, genau das mit einer modernen,
anders konzipierten Shell zu erreichen.
Also ein richtiger, großer praktischer Nutzen - auch unter Windows.
Das ist der Grund, warum ich krampfige Syntax-Konstruktionen
schwer ertragen kann.
Ich hatte früher csh+sh+awk+bc+expr+sed+dd+... benutzt, um meine
Probleme zu lösen. Heute brauch ich nur noch 1 Werkzeug, 1 Syntax,
und das auch unter DOS und Windows portabel und runtime-schnell.
Deshalb meine bsh-Entwicklung; dabei stellte ich fest, daß sich
ksh offenbar erfreulicherweise etabliert hatte, jedoch wohl
doch nicht wirklich, denn ich sehe bis heute nicht, daß die ksh-Zeit
auf breiter Ebene sich in Skripts niederschlägt.
Sämtliche technische Dinge auf der Welt erneuern sich
permanent. Neues kommt auf, eine Weile ist das Alte und das
Neue da, aber dann verkrümelt sich das Alte und nur noch das
Neue bleibt - Ausnahme: die sh-Skripte, sogar mit grauseligen
Syntax-Purzelbäumen.
> Aber es ist gut zu wissen, dass es auch eleganter geht, und wenn die
> Funktionalität von printf nicht nur in C-Programmen, sondern auch in
> Shell-Skripten verfügbar ist, wunderbar! Und über die Standardisierung
> werden sich diese neuen Funktionen auch mit der Zeit etablieren.
Das ist *erholsam* *bei* der Programmierung.
Man programmiert dann mit Lust -ohne Frust- sogar besser!
> > Ich finde es grauenvoll, solche Konstruktionen:
> > case $GHR in; kell*) aaaaa;; *) zzzzz;; esac
> > zu sehen, nur weil es sh sein muß(?).
>
> Sobald man obige Konstruktion schön sauber untereinander schreibt, verliert
> sie ihren Schrecken. Für mich jedenfalls. Ich kann damit gut leben. Klar
> ist aber, dass es kein besonders eleganter Weg der Auswertung von RE's ist.
Das ist ein kleines Mißverständnis:
Das habe ich in diversen configure gesehen, in einer
Anordnungsform, die deutlich macht, daß man sich z.B. ein
crb=dflt
[[ $str == m??* ]] && crb=4
eigentlich herbeigesehnt hatte.
Man hat case-esac vergewaltigt, um überhaupt einen
pattern-Vergleich zu ermöglichen.
> > Es gibt aber doch Probleme, weil Shells, die unter
> > ein und demselben Pfad zu finden sind, offenbar
> > (bildlich) 1000 Unterschiede haben.
>
> Das bringen Verbesserungen mit sich. Der Preis, den man für
> Neuentwicklungen zahlt, ist meist eine eingeschränkte Universalität. Dann
> greift man eben auf's altbewährte zurück, wenn man's braucht. Und da sind
> es dann natürlich Standards, die einem sagen, was man verwenden darf. Ich
> sehe hier die Bourne-Shell auch als einen quasi Standard, der aber m.W. nie
> explizit als solcher niedergeschrieben wurde. Aber selbst damit kann auf
> die Nase fallen, wie das echo-Beispiel gezeigt hat.
Nötig wären die Probleme im Zusammenhang mit Verbesserungen
aber nicht, denn man kann sowas in geeigneter Weise bewehren,
sodaß es eindeutig kontrollierbar wird.
Gunnar Ritter
> Was mich betrifft, ist es so, daß ich mindestens 60% aller
> potentiellen C/C++-Programme als bsh-Skript schreibe.
> Also so 'richtige große' Arbeitsprogramme.
Quatsch, so etwas kann man mit Deinem »bsh«-Ding gar nicht machen,
schon wegen der arbiträren Limits, <3B747932....@bigfoot.de>.
Oder, ach natürlich, was Du unter »groß« verstehst, gilt für Dein
provinzielles Umfeld, haha.
> Das geht 3-5-fach schneller und ist danach wesentlich kleiner
> und viel besser und schneller pflegbar.
Hör gefälligst endlich auf, hier zu werben! Code für Deine »bsh« ist
absolut unwartbar, weil jeder normale Mensch Deine proprietäre Syntax
andauernd mit der einer richtigen Unix-Shell durcheinanderbringt. Da
die Reaktion des Programmes darauf bekanntlich nicht kalkulierbar ist,
ist es gefährlich, diesen Code auch nur anzusehen. »Schneller pflegbar«!
Ja. Indem man diesen Sondermüll nach /dev/null kippt, vielleicht.
Grüße,
Gunnar
Matthias Andree
> Aber Unheil richtet das Ding nicht an, im Gegenteil,
> es heilt von Syntax-Vergewaltigung, wie ein guter Heilpraktiker.
Indem die internen Befehle unlesbare und inkompatible Syntax mit sich
bringen?
Ist genau wie mit Heilpraktikern: viele Blender.
--
Matthias Andree
Matthias Andree
> Soso, dann schlage ich mal vor, daß Du mit gutem Beispiel vorangehst
> und Dein »bsh«-Programm umbenennst. Unter IRIX wie AIX, zwei recht
> weit verbreiteten Unix-Systemen, ist »bsh« nämlich eine gute alte
> Bourne-Shell. Und bei RedHat-Linux gibt es auch eine »bsh«, einen
> symbolischen Link zur ash. Daß ausgerechnet Du auf Namenskonflikte
> aufmerksam machst, ist blanker Hohn. Aber ich gehe mal ohne weitere
> Nachforschungen davon aus, daß »bogush« noch für Dich frei ist.
badsh soll auch noch frei sein...
--
Matthias Andree
Matthias Andree
> Ist auch nicht weiter schlimm. Wer keine Lust hat, sich eine eigene
> bash mit »--enable-usg-echo-default« aka »--enable-xpg-echo-default«
> zu bauen, kann es ja auch mit »shopt -s xpg_echo« zur Laufzeit festlegen.
Ich hab' spaßeshalber feed...@suse.de mal um Änderung gebeten. Ob sich
da was regt, wird man sehen.
--
Matthias Andree
Felix von Leitner
> daß wohl 999 von 1000 Installationen mindestens eine pdksh
> zur Verfügung haben.
"mindestens". -> Tonne.
Meine Systeme haben keine ksh und keine pdksh.
Portable Scripte sind in /bin/sh oder /usr/bin/perl.
Weitere Annahmen über Shells für den Fuß und passen zu Möchtegerns wie dir.
Gut, daß es dich gibt. So wird immer ein Markt für Leute wie mich sein,
um hinter dir wieder aufzuräumen.
Und wenn man dem Auftraggeber deine Sourcen zeigt (es reicht schon, was
du bisher so veröffentlicht hast), glauben sie einem auch ohne
Diskussionen, daß man das wegschmeißen und neu machen muß, weil sich
Refakturierung nicht lohnt. Ich hoffe, daß du sehr alt wirst und bei
vielen Firmen viel Schaden anrichtest, bevor man dich aus dem Verkehr
zieht.
Felix
Juergen Ilse
Helmut Schellong <sche...@t-online.de> wrote:
> Gunnar Ritter wrote:
>> Helmut Schellong <sche...@t-online.de> wrote:
>> > #!/usr/bin/bsh
>> > Das ist eigentlich eine sichere Angelegenheit,
>> > wenn die Shells mit Unterschieden ein Versionskommando
>> > hätten/haben, wie bsh (ver [n|s|o|l]) es hat.
>> Soso, dann schlage ich mal vor, daß Du mit gutem Beispiel vorangehst
>> und Dein »bsh«-Programm umbenennst. Unter IRIX wie AIX, zwei recht
>> weit verbreiteten Unix-Systemen, ist »bsh« nämlich eine gute alte
>> Bourne-Shell. Und bei RedHat-Linux gibt es auch eine »bsh«, einen
>> symbolischen Link zur ash.
> Das ist wohl so; aber gerade das ist zu kritisieren.
... und zwar an deiner shell, denn die bsh unter IRIX und AIX gab es
schon frueher ... ;-)
> Und 'sh' ist doch weit überwiegend und auch traditionell
> die gute alte Bourne-Shell.
... bis auf die Systeme, wo /bin/sh eine Posix-shell ist und aus
historischen Gruenden trotz allem noch eine "nicht Posix" Version
mitgeliefert werden soll ...
> Warum wird dann *dafür* ein weiterer *anderer* Name
> (zusätzlich) besetzt?!
Weil es zur Unterscheidung notwendig ist, sofern man verschiedene
Versionen einer shell ausliefert (sh fuer Posix-shell, bsh fuer
"alte Bourne shell", jsh fuer Posix-shell mit Job-Control, ...).
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Du hast keine Spracherkennung installiert? | Juergen Ilse
Doch Komma aber Mai Stenz Macht Sie den um Gang |Internet POP Hannover GmbH
mit dem Juice nett auch nicht leichter. |Vahrenwalder Str. 205
(Adrian Suter und Matthias Esken in dsnu) |30165 Hannover
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> wrote:
>
> > Was mich betrifft, ist es so, daß ich mindestens 60% aller
> > potentiellen C/C++-Programme als bsh-Skript schreibe.
> > Also so 'richtige große' Arbeitsprogramme.
>
> Quatsch, so etwas kann man mit Deinem »bsh«-Ding gar nicht machen,
> schon wegen der arbiträren Limits, <3B747932....@bigfoot.de>.
> Oder, ach natürlich, was Du unter »groß« verstehst, gilt für Dein
> provinzielles Umfeld, haha.
Unter groß verstehe ich -mit bsh- 25000...100000 Byte,
was -mit sh- etwa 60000...250000 Byte entspricht.
Mein Umfeld ist die professionelle Industrielandschaft;
provinziell würde ich das nicht nennen.
> > Das geht 3-5-fach schneller und ist danach wesentlich kleiner
> > und viel besser und schneller pflegbar.
>
> Hör gefälligst endlich auf, hier zu werben! Code für Deine »bsh« ist
> absolut unwartbar, weil jeder normale Mensch Deine proprietäre Syntax
> andauernd mit der einer richtigen Unix-Shell durcheinanderbringt.
Du redest von unfähigen Programmierern, die nicht begreifen, daß
proprietäre Syntax nun mal von der portablen abweicht?!
Ich habe jedenfalls erheblich mehr Merkprobleme mit der
proprietären und zusätzlich kryptischen Syntax der ksh:
?(pattern-list)
*(pattern-list)
+(pattern-list)
@(pattern-list)
!(pattern-list)
${#vname[*]}
${#vname[@]}
${!vname}
${!vname[subscript]}
${!prefix*}
${parameter:-word}
${parameter:=word}
${parameter:?word}
${parameter:+word}
${parameter:offset:length}
${parameter:offset}
${parameter#pattern}
${parameter##pattern}
${parameter%pattern}
${parameter%%pattern}
${parameter/pattern/string}
${parameter//pattern/string}
${parameter/#pattern/string}
${parameter/%pattern/string}
Helmut Schellong
>
> Thus spake Helmut Schellong (sche...@t-online.de):
> > daß wohl 999 von 1000 Installationen mindestens eine pdksh
> > zur Verfügung haben.
>
> "mindestens". -> Tonne.
> Meine Systeme haben keine ksh und keine pdksh.
Dann gehören sie zu der '1' von '1000'.
> Und wenn man dem Auftraggeber deine Sourcen zeigt (es reicht schon, was
> du bisher so veröffentlicht hast), glauben sie einem auch ohne
> Diskussionen, daß man das wegschmeißen und neu machen muß, weil sich
> Refakturierung nicht lohnt. Ich hoffe, daß du sehr alt wirst und bei
> vielen Firmen viel Schaden anrichtest, bevor man dich aus dem Verkehr
> zieht.
Komischerweise ist mein Kode seit vielen Jahren sehr beliebt
und problemlösend - im *professionellen* Bereich.
Mitunter ist mein Kode sogar *Der Produktamlebenerhalter*,
weil ich Kode von Vorgängern auf 40% der Ursprungsgröße bringe,
fehlerbereinige, Funktionalität und Tempo verbessere und mit
den 60% freigeschaufeltem Rest 2-3-mal mehr anfange als
viele andere vermögen.
Meine Sourcen werden im *professionellen* Bereich uneingeschränkt
anerkannt, manchmal sogar bewundert.
Spätestens, wenn ich mit meinem Kode beginne, bisher ungelöste
Probleme zu lösen.
Ich erhalte auch vierstellige Gehaltserhöhungen und kaufe mir
seit 15 Jahren Pkw der unteren Oberklasse, die ich ohne
irgendwelche Kredite bar bezahle, wohne/wohnte auf 160 qm,
- alles aufgrund meiner geschätzten Programmier- und
sonstigen Entwicklungstätigkeit.
So, das war jetzt mal ein Ausschnitt aus der Wirklichkeit...
Man soll sich selbst nicht loben, aber das war hier mal
notwendig, denn sonst glaubt tatsächlich noch jemand diese
haltlosen Behauptungen, die hier immer wieder platziert werden.
Helmut Schellong
>
> Hallo,
>
> Helmut Schellong <sche...@t-online.de> wrote:
> > Gunnar Ritter wrote:
> >> Helmut Schellong <sche...@t-online.de> wrote:
> >> > #!/usr/bin/bsh
> >> > Das ist eigentlich eine sichere Angelegenheit,
> >> > wenn die Shells mit Unterschieden ein Versionskommando
> >> > hätten/haben, wie bsh (ver [n|s|o|l]) es hat.
> >> Soso, dann schlage ich mal vor, daß Du mit gutem Beispiel vorangehst
> >> und Dein »bsh«-Programm umbenennst. Unter IRIX wie AIX, zwei recht
> >> weit verbreiteten Unix-Systemen, ist »bsh« nämlich eine gute alte
> >> Bourne-Shell. Und bei RedHat-Linux gibt es auch eine »bsh«, einen
> >> symbolischen Link zur ash.
> > Das ist wohl so; aber gerade das ist zu kritisieren.
>
> ... und zwar an deiner shell, denn die bsh unter IRIX und AIX gab es
> schon frueher ... ;-)
Ich finde es tatsächlich auch nicht schön, als ich entdecken
mußte, daß 'bsh' doch schon besetzt war.
Aber es ging hier ganz allgemein um Namensbesetzungen, die
schnell und isoliert vorgenommen wurden.
> > Und 'sh' ist doch weit überwiegend und auch traditionell
> > die gute alte Bourne-Shell.
>
> ... bis auf die Systeme, wo /bin/sh eine Posix-shell ist und aus
> historischen Gruenden trotz allem noch eine "nicht Posix" Version
> mitgeliefert werden soll ...
Das sollte man besser per *Verzeichnis*namen unterscheiden.
> > Warum wird dann *dafür* ein weiterer *anderer* Name
> > (zusätzlich) besetzt?!
>
> Weil es zur Unterscheidung notwendig ist, sofern man verschiedene
> Versionen einer shell ausliefert (sh fuer Posix-shell, bsh fuer
> "alte Bourne shell", jsh fuer Posix-shell mit Job-Control, ...).
Das sollte man primär besser per *Verzeichnis*namen unterscheiden.
Andreas Ferber
>> > daß wohl 999 von 1000 Installationen mindestens eine pdksh
>> > zur Verfügung haben.
>> "mindestens". -> Tonne.
>> Meine Systeme haben keine ksh und keine pdksh.
> Dann gehören sie zu der '1' von '1000'.
Ohne die 1 ist die 1000 nichts...
> Mitunter ist mein Kode sogar *Der Produktamlebenerhalter*,
> weil ich Kode von Vorgängern auf 40% der Ursprungsgröße bringe,
> fehlerbereinige, Funktionalität und Tempo verbessere und mit
> den 60% freigeschaufeltem Rest 2-3-mal mehr anfange als
> viele andere vermögen.
> Meine Sourcen werden im *professionellen* Bereich uneingeschränkt
> anerkannt, manchmal sogar bewundert.
> Spätestens, wenn ich mit meinem Kode beginne, bisher ungelöste
> Probleme zu lösen.
> Ich erhalte auch vierstellige Gehaltserhöhungen und kaufe mir
> seit 15 Jahren Pkw der unteren Oberklasse, die ich ohne
> irgendwelche Kredite bar bezahle, wohne/wohnte auf 160 qm,
> - alles aufgrund meiner geschätzten Programmier- und
> sonstigen Entwicklungstätigkeit.
Du musst ein Gott sein - sogar die Überheblichkeit und der Grössenwahn
könnten nicht besser getroffen sein. Wo ist der Tempel, in dem man dich
anbeten kann?
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - a...@devcon.net - www.devcon.net
Helmut Schellong
Willst Du ein Pilger sein?
Das geht, darauf bin ich eingerichtet.
Du mußt auf den Knien zu meinem Thron rutschen
und dabei mehrmals laut und vernehmlich ausrufen:
El Supremo, El Supremo, ...
Andreas Riedel
>> Will man natürlich nicht. Muss man aber dennoch oft. Wenn ich einem
>> Kollegen per Email ein Skript schicke, und nicht genau weiss, was für
>> ein System er verwendet, bzw. was für Shells auf seinem System
>> vorhanden sind, bin ich auf der sicheren Seite, wenn es ein
>> Bourne-Skript ist. Und dann verwende ich lieber ein oder zweimal ein
>> hässliches Konstrukt, als dass ich erst lang und breit erklären muss,
>> auf welchem System das Skript mit welcher Shell in welcher Version
>> läuft. Man muss immer davon ausgehen, dass viele Unix-User über keine
>> Programmier-Kenntnisse verfügen, und auch nicht mal den Unterschied
>> zwischen einer Bourne- oder C-Shell kennen
>
> MUSS man wirklich?
Letzteres wohl weniger, aber das Vorhandensein irgend einer Shell außer
sh oder csh vorauszusetzen ist reichlich gewagt.
> Ich habe mal über die Anzahl von aktuell konkret vorhandenen
> Unix-Installationen nachgedacht, und ich komme zu der Schätzung,
> daß wohl 999 von 1000 Installationen mindestens eine pdksh
> zur Verfügung haben.
Ein Rechner, der nicht von mir administriert wird:
rian@odoaker rian $ ksh
bash: ksh: command not found
rian@odoaker rian $ cat /etc/redhat-release
Red Hat Linux release 6.2 (Zoot)
Auch bei FreeBSD muß man die ksh erst nachinstallieren, hier habe ich
das eigentlich nur wegen dieser NG getan. Auf den Rechnern in meiner
Reichweite ist die bash wesentlich verbreiteter (aber zu 99,9%-Aussagen
werde ich mich gewiß nicht hinreißen lassen), die verwende ich meist,
wenn mir sh mal nicht reicht und Portabilität nicht soo wichtig ist.
> Wenn nun auf pdksh-Level programmiert würde und dieser eine
> von 1000 Fällen mal einträte, würde eben dieser eine User
> 'auf den Bauch fallen' - na und.
Diese Einstellung kennen wir von Dir bereits.
> Falls ich mal die bsh mit Makefile und configure anböte,
> wäre configure garantiert für ksh93 geschrieben.
Configure-Scripts sind eigentlich das klassische Beispiel für eine
Anwendung, bei der Portabilität extrem wichtig ist. Aber wir merken uns:
Wer bsh installiert, braucht trotzdem noch ksh93. Wenn auch ungewollt -
Du wirst langsam ehrlich.
> Allerdings, wenn irgendein Skript ohne Syntax-Verrenkungen
> für sh schreibbar wäre, würde auch ich es durchaus bei diesem
> Level belassen.
Ob ich mich ob der Portabilität verrenke oder nicht kommt auf die
Anwendung an. Ob mein MP3-Abspieler oder die Scripts in
/usr/local/etc/rc.d besonders portabel sind oder nicht ist mir relativ
Brot, bei Dingen die ich weggebe ist mir Portabilität dagegen einiges an
Aufwand wert.
> Sämtliche technische Dinge auf der Welt erneuern sich
> permanent. Neues kommt auf, eine Weile ist das Alte und das
> Neue da, aber dann verkrümelt sich das Alte und nur noch das
> Neue bleibt - Ausnahme: die sh-Skripte, sogar mit grauseligen
> Syntax-Purzelbäumen.
Unter Unix hat portables Programmieren Tradition. Das ist auch aus der
Not geboren - es gibt nun mal "hunderte" Unices, und man will seine
Programme nicht nur einer Minderheit zugänglich machen. Das gilt nicht
nur für Shellscripts, auch für andere Programme.
Gruß
Andreas
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Andreas Ferber
>
> Ob ich mich ob der Portabilität verrenke oder nicht kommt auf die
> Anwendung an. Ob mein MP3-Abspieler oder die Scripts in
> /usr/local/etc/rc.d besonders portabel sind oder nicht ist mir relativ
> Brot, bei Dingen die ich weggebe ist mir Portabilität dagegen einiges an
> Aufwand wert.
Oder man sagt explizit dazu, daß es z.B. auf jeden Fall eine bash
benötigt, und dann steht auch #!/bin/bash in der ersten Zeile. IMO hat
das dann, wenn man die Abhängigkeit _dokumentiert_, den gleichen
Stellenwert wie z.B. ein Programm, das zwingend irgendeine Library
voraussetzt. Stillschweigendes Voraussetzen einer bestimmten Shell ist
natürlich nicht die feine Art.
BTW, hat eigentlich schonmal jemand ausprobiert, was mit einem üblichen
GNU/Linux passiert (Initskripte etc.), wenn man statt der bash als
/bin/sh eine andere (POSIX-/SUSv2-)Shell verwendet?
Gunnar Ritter
> Mein Umfeld ist die professionelle Industrielandschaft;
Haha, »professionell«. Soll heißen, Du ziehst Leuten beruflich Geld aus
der Tasche, ja? Hier nicht. Mittlerweile hat hier wirklich jeder Leser
begriffen, daß man Dich nicht ernstnehmen kann - mit Worthülsen ist da
nichts zu retten. Du kannst Dein Umfeld noch so oft als »professionell«
bezeichnen, es ändert Deine Position als Witzfigur und Gruppenkasper
nicht im geringsten. Wenn Du behauptetest, Napoleon oder der Kaiser von
China zu sein, wäre das exakt genauso glaubhaft.
>> Hör gefälligst endlich auf, hier zu werben! Code für Deine »bsh« ist
>> absolut unwartbar, weil jeder normale Mensch Deine proprietäre Syntax
>> andauernd mit der einer richtigen Unix-Shell durcheinanderbringt.
>
> Du redest von unfähigen Programmierern, die nicht begreifen, daß
> proprietäre Syntax nun mal von der portablen abweicht?!
Weißt Du, Helmut, vergiß es doch einfach. Ich werde das jetzt nicht
noch mal von vorne aufrollen. Stell für das Geld, um das Du andere mit
»bsh« gebracht hast, einen Sonderpädagogen an, der Dich betreut und Dir
geduldig erklärt, was Du in der großen weiten Welt so alles nicht
verstanden hast.
> Ich habe jedenfalls erheblich mehr Merkprobleme mit der
> proprietären und zusätzlich kryptischen Syntax der ksh:
Möchte jemand wissen, wobei Du »Merkprobleme« hast? Bitte melden.
Grüße,
Gunnar
Gunnar Ritter
> Ich erhalte auch vierstellige Gehaltserhöhungen und kaufe mir
> seit 15 Jahren Pkw der unteren Oberklasse, die ich ohne
> irgendwelche Kredite bar bezahle, wohne/wohnte auf 160 qm,
Ich bin schwer beeindruckt. Nein, nicht von Deinem Häuschen, sondern
von der Idee, IT-Leuten die Existenz eines Studienrates als Privileg
vorzuhalten. Das hat doch was, fast so eine Art Zurück zur Natur!
> - alles aufgrund meiner geschätzten Programmier- und
> sonstigen Entwicklungstätigkeit.
Ach, das ist doch gar nichts. Andere sind reich geworden, indem sie den
Eiffelturm verkauften - sogar mehrmals, weil es den Opfern hinterher zu
peinlich war, das anzuzeigen. Daß man auch mit Pfusch, dreister Werbung
und Schummeleien Geld verdienen kann, ist nun wirklich nicht neu.
Grüße,
Gunnar
Andreas Riedel
>> Ob ich mich ob der Portabilität verrenke oder nicht kommt auf die
>> Anwendung an. Ob mein MP3-Abspieler oder die Scripts in
>> /usr/local/etc/rc.d besonders portabel sind oder nicht ist mir
>> relativ Brot, bei Dingen die ich weggebe ist mir Portabilität dagegen
>> einiges an Aufwand wert.
>
> Oder man sagt explizit dazu, daß es z.B. auf jeden Fall eine bash
> benötigt, und dann steht auch #!/bin/bash in der ersten Zeile. IMO hat
> das dann, wenn man die Abhängigkeit _dokumentiert_, den gleichen
> Stellenwert wie z.B. ein Programm, das zwingend irgendeine Library
> voraussetzt.
Ack. Allerdings sollte das in beiden Fällen einen echten Mehrwert
bringen. Wenn jemand eine zusätzliche (non-standard) Library dazulinkt,
nur um zwei Codezeilen zu sparen, ist das genauso Blödsinn, wie wenn man
aus dem selben Grund bash statt sh verwendet. Andererseits ist es oft
nicht sinnvoll, das Rad neu zu erfinden - man muß also immer Aufwand und
Nutzen abwägen.
> Stillschweigendes Voraussetzen einer bestimmten Shell ist natürlich
> nicht die feine Art.
Ack. Besonders schlimm ist, wenn #!/bin/sh dasteht, aber in Wirklichkeit
bash gemeint ist.
> BTW, hat eigentlich schonmal jemand ausprobiert, was mit einem
> üblichen GNU/Linux passiert (Initskripte etc.), wenn man statt der
> bash als /bin/sh eine andere (POSIX-/SUSv2-)Shell verwendet?
Ich nicht. Aber ich halte es für keinen Mangel, wenn ein System nicht
mehr funktioniert, nachdem man in /bin oder /sbin herumgepfuscht hat.
Imho ist es durchaus legitim, daß Systemscripte die Systembinaries auch
ausreizen.
Helmut Schellong
>
> Helmut Schellong schrieb:
> >> Will man natürlich nicht. Muss man aber dennoch oft. Wenn ich einem
> >
> > MUSS man wirklich?
>
> Letzteres wohl weniger, aber das Vorhandensein irgend einer Shell außer
> sh oder csh vorauszusetzen ist reichlich gewagt.
Siehe unten.
> > Ich habe mal über die Anzahl von aktuell konkret vorhandenen
> > Unix-Installationen nachgedacht, und ich komme zu der Schätzung,
> > daß wohl 999 von 1000 Installationen mindestens eine pdksh
> > zur Verfügung haben.
>
> Ein Rechner, der nicht von mir administriert wird:
>
> rian@odoaker rian $ ksh
> bash: ksh: command not found
> rian@odoaker rian $ cat /etc/redhat-release
> Red Hat Linux release 6.2 (Zoot)
>
> Auch bei FreeBSD muß man die ksh erst nachinstallieren,
Oh, moment, das habe ich aber eingeschlossen!
Auch ich habe unter SuSE-Linux neulich kurz Yast aufgerufen
und pdksh installiert.
Wenn das von den Original-CDs her geht, ist es für mich
ganz klar 'vorhanden/verfügbar'.
Auch unter allen SCO-Systemen ist 'perl' *nicht*
automatisch zwangsinstalliert, man kann von Skunkware-CD
nachinstallieren.
Das heißt aber nicht, daß 'perl' unter diesen Systemen nicht
zur Verfügung stünde.
Nur wenn man www.gnu.org aufsuchen, downloaden und kompilieren
muß, würde ich von 'nicht vorhanden' sprechen.
> > Wenn nun auf pdksh-Level programmiert würde und dieser eine
> > von 1000 Fällen mal einträte, würde eben dieser eine User
> > 'auf den Bauch fallen' - na und.
>
> Diese Einstellung kennen wir von Dir bereits.
1 von 1000 - dazu stehe ich wirklich.
> > Falls ich mal die bsh mit Makefile und configure anböte,
> > wäre configure garantiert für ksh93 geschrieben.
>
> Configure-Scripts sind eigentlich das klassische Beispiel für eine
> Anwendung, bei der Portabilität extrem wichtig ist. Aber wir merken uns:
> Wer bsh installiert, braucht trotzdem noch ksh93. Wenn auch ungewollt -
> Du wirst langsam ehrlich.
'wirst'?
Ich habe niemals behauptet, bsh sei auch nur annähernd so weit
verbreitet wie ksh.
Ich habe hierzu überhaupt gar keine Behauptungen aufgestellt,
sondern hatte lediglich einmal während einer Diskussion gesagt,
daß bsh einige tausend mal down-geladen wurde und daß bsh in
der Industrie Verwendung findet.
Wer bsh installiert, braucht nichts anderes dazu, ja selbst
'installieren' ist schon zuviel gesagt.
Wer bsh per configure und Makefile *kompiliert*, ja, der braucht
eine andere Shell und make/gmake und einen C-Compiler.
(Mal davon abgesehen, daß bsh nicht OpenSource ist.)
> > Allerdings, wenn irgendein Skript ohne Syntax-Verrenkungen
> > für sh schreibbar wäre, würde auch ich es durchaus bei diesem
> > Level belassen.
>
> Ob ich mich ob der Portabilität verrenke oder nicht kommt auf die
> Anwendung an. Ob mein MP3-Abspieler oder die Scripts in
> /usr/local/etc/rc.d besonders portabel sind oder nicht ist mir relativ
> Brot, bei Dingen die ich weggebe ist mir Portabilität dagegen einiges an
> Aufwand wert.
Auch ich sehe da einen gesteigerten Wert in Portabilität,
jedoch absolute 100%-Portabilität halte ich so gut wie nie
für erforderlich.
Man kann's auch übertreiben.
> > Sämtliche technische Dinge auf der Welt erneuern sich
> > permanent. Neues kommt auf, eine Weile ist das Alte und das
> > Neue da, aber dann verkrümelt sich das Alte und nur noch das
> > Neue bleibt - Ausnahme: die sh-Skripte, sogar mit grauseligen
> > Syntax-Purzelbäumen.
>
> Unter Unix hat portables Programmieren Tradition. Das ist auch aus der
> Not geboren - es gibt nun mal "hunderte" Unices, und man will seine
> Programme nicht nur einer Minderheit zugänglich machen. Das gilt nicht
> nur für Shellscripts, auch für andere Programme.
Minderheit - das will auch ich nicht.
Jedoch sehe ich 999 von 1000 nicht als Minderheit an ...
Helmut Schellong
> > sonstigen Entwicklungstätigkeit.
>
> Ach, das ist doch gar nichts. Andere sind reich geworden, indem sie den
> Eiffelturm verkauften - sogar mehrmals, weil es den Opfern hinterher zu
> peinlich war, das anzuzeigen. Daß man auch mit Pfusch, dreister Werbung
> und Schummeleien Geld verdienen kann, ist nun wirklich nicht neu.
Jahrzehntelang?
Gunnar Ritter
> Gunnar Ritter wrote:
>> Daß man auch mit Pfusch, dreister Werbung und Schummeleien Geld
>> verdienen kann, ist nun wirklich nicht neu.
>
> Jahrzehntelang?
Ja. Man macht sich eben unentbehrlich, indem man Code unterschiebt,
den niemand sonst warten kann; das Konzept ist uralt. Mit »bsh« hast
Du es in markanter Weise umgesetzt; niemand außer Dir kann oder
möchte Skripte dafür schreiben, und selbst wenn, er wäre immer noch
in hohem Maße von Dir abhängig. Gut, daß wir das längst wissen und
hier jeden vor dieser Falle warnen können.
Grüße,
Gunnar
Helmut Schellong
Mit Hilfe der bsh-Doku kann das sogar meine Schwester, die
einen Büroberuf gelernt hat ...
Da fällt einem nix mehr ein.
Raphael H. Becker
> > Ich habe jedenfalls erheblich mehr Merkprobleme mit der
> > proprietären und zusätzlich kryptischen Syntax der ksh:
>
> Möchte jemand wissen, wobei Du »Merkprobleme« hast? Bitte melden.
Vielleicht kann da jemand vom Bundesamt fuer Merkbefreiung eine passende
Loesung anbieten? Ich denke, die haben da sehr kompetente Leute.
Gruss
Raphael Becker
--
t(){ while [ -n "$1" ];do T=/tmp/$$.html;lynx -source "http://dict.leo.\
org/?search=$1"|grep search\ result >$T&&w3m -dump $T;rm $T;shift;done;}
[ -n "$1" ]&&t "$@"||while read -ep dict2\> W;do t $W|more; done #by rhb
# http://rhb.swm.uni-mannheim.de/scripts/dict2
Helmut Schellong
>
> Gunnar Ritter <g...@bigfoot.de> wrote:
> > > Ich habe jedenfalls erheblich mehr Merkprobleme mit der
> > > proprietären und zusätzlich kryptischen Syntax der ksh:
> >
> > Möchte jemand wissen, wobei Du »Merkprobleme« hast? Bitte melden.
>
> Vielleicht kann da jemand vom Bundesamt fuer Merkbefreiung eine passende
> Loesung anbieten? Ich denke, die haben da sehr kompetente Leute.
Lästert ihr nur, ihr frechen Schnösel - ich merk mir das...
Andreas Riedel
>> > Ich habe mal über die Anzahl von aktuell konkret vorhandenen
>> > Unix-Installationen nachgedacht, und ich komme zu der Schätzung,
>> > daß wohl 999 von 1000 Installationen mindestens eine pdksh
>> > zur Verfügung haben.
>>
>> Ein Rechner, der nicht von mir administriert wird:
>> Auch bei FreeBSD muß man die ksh erst nachinstallieren,
>
> Oh, moment, das habe ich aber eingeschlossen!
> Auch ich habe unter SuSE-Linux neulich kurz Yast aufgerufen
> und pdksh installiert.
> Wenn das von den Original-CDs her geht, ist es für mich
> ganz klar 'vorhanden/verfügbar'.
Das nutzt mir nichts, wenn ich den Rechner nicht administriere. Da bin
ich mehr oder minder auf die installierten Dinge angewiesen.
> Auch unter allen SCO-Systemen ist 'perl' *nicht*
> automatisch zwangsinstalliert, man kann von Skunkware-CD
> nachinstallieren.
> Das heißt aber nicht, daß 'perl' unter diesen Systemen nicht
> zur Verfügung stünde.
Hier geht es um Unix, nicht um DOS. Und da ist es durchaus nicht
selbstverständlich, daß der Anweder das root-Passwort hat und beliebig
Software installieren darf. Wenn von "Systemen" gesprochen wird, stelle
ich mir deshalb eigentlich immer Rechner vor. Perl ist auf nahezu jedem
Rechner installiert. Auf nahezu jedem Rechner gibt es auch eine Shell,
die weit mächtiger als sh und csh ist. Nur kann man leider keine
bestimmte voraussetzen.
Aber selbst bei Perl muß man sich im Klaren darüber sein, daß es
bestimmt einige Systeme gibt, auf denen das nicht installiert ist. Der
Mehrwert muß diesen Nachteil erstmal ausgleichen.
Juergen Ilse
Helmut Schellong <sche...@t-online.de> wrote:
>> Du musst ein Gott sein - sogar die Überheblichkeit und der Grössenwahn
>> könnten nicht besser getroffen sein. Wo ist der Tempel, in dem man dich
>> anbeten kann?
> Willst Du ein Pilger sein?
> Das geht, darauf bin ich eingerichtet.
> Du mußt auf den Knien zu meinem Thron rutschen
> und dabei mehrmals laut und vernehmlich ausrufen:
> El Supremo, El Supremo, ...
Fuer diejenigen, die das nicht tun wollen und sich statt dessen ueber
die Besonderheiten, Macken und Eigentuemlichkeiten der "bsh" von Helumut
informieren moechten, steht mittlerweile unter der URL:
http://members.pop-hannover.de/~ilse/bsh-programming-harmful.html
eine Beschreibung der bsh im Vergleich zu "ueblichen" unix-shells zur
Verfuegung. Der Text stammt von Gunnar Ritter, die (quick&dirty) Umset-
zung nach HTML stammt von mir.
Gunnar Ritter
> Lästert ihr nur, ihr frechen Schnösel - ich merk mir das...
Such mal einen Psychiater auf. Du scheinst massive Störungen in Deiner
Realitätseinschätzung zu haben und größenwahnsinnig zu werden.
Grüße,
Gunnar
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
>> > Ich habe jedenfalls erheblich mehr Merkprobleme mit der
>> > proprietären und zusätzlich kryptischen Syntax der ksh:
>>
>> Möchte jemand wissen, wobei Du »Merkprobleme« hast? Bitte melden.
>
> Vielleicht kann da jemand vom Bundesamt fuer Merkbefreiung eine passende
> Loesung anbieten? Ich denke, die haben da sehr kompetente Leute.
Oh, hoffentlich. Ich war schon immer der Ansicht, daß »bsh« mitsamt
Autor eigentlich ein Fall für dag° ist. Da ist das Ding weit mehr
on-topic als hier.
Grüße,
Gunnar
Gunnar Ritter
> Mit Hilfe der bsh-Doku [...]
»bsh-Doku«? Das ist doch der lustige Text mit den vielen
Ausrufungszeichen, in dem Sätze wie
| Umlenkungen, die ein Vorauslesen erfordern, über die Argumente eines
| 'normalen' Kommandos hinaus, kann die bsh nicht.
| Schleifen, if-elif-else-fi und case-esac sind bei solcher
| Zeilenverteilung problematisch aber durchaus teilweise funktionabel.
stehen. Den muß ein intelligentes Wesen ja nur von weitem sehen, um
zu wissen, was es von Dir zu halten hat.
Grüße,
Gunnar
Juergen Ilse
Andreas Riedel <andreas...@hrz.tu-chemnitz.de> wrote:
> Helmut Schellong schrieb:
>>> Will man natürlich nicht. Muss man aber dennoch oft. Wenn ich einem
>>> Kollegen per Email ein Skript schicke, und nicht genau weiss, was für
>>> ein System er verwendet, bzw. was für Shells auf seinem System
>>> vorhanden sind, bin ich auf der sicheren Seite, wenn es ein
>>> Bourne-Skript ist. Und dann verwende ich lieber ein oder zweimal ein
>>> hässliches Konstrukt, als dass ich erst lang und breit erklären muss,
>>> auf welchem System das Skript mit welcher Shell in welcher Version
>>> läuft. Man muss immer davon ausgehen, dass viele Unix-User über keine
>>> Programmier-Kenntnisse verfügen, und auch nicht mal den Unterschied
>>> zwischen einer Bourne- oder C-Shell kennen
>> MUSS man wirklich?
> Letzteres wohl weniger, aber das Vorhandensein irgend einer Shell außer
> sh oder csh vorauszusetzen ist reichlich gewagt.
Ich persoenlich halte es heutzutage schon fuer gewagt, bei "nicht BSD"
Systemen unbedingt eine csh vorauszusetzen ...
Und zu der Frage, ob man davon ausgehen muss, dass ein Anwender eines
unix-Systems evt. nicht weiss, welche shells installiert sind und wo die
Unterschiede liegen: davon muss man wohl ausgehen (ein "nur Anwender muss
das evt. auch nicht unbedingt besser wissen, der Admin sollte es besser
wissen, weiss es aber oft nicht besser ...).
>> Ich habe mal über die Anzahl von aktuell konkret vorhandenen
>> Unix-Installationen nachgedacht, und ich komme zu der Schätzung,
>> daß wohl 999 von 1000 Installationen mindestens eine pdksh
>> zur Verfügung haben.
> Ein Rechner, der nicht von mir administriert wird:
> rian@odoaker rian $ ksh
> bash: ksh: command not found
> rian@odoaker rian $ cat /etc/redhat-release
> Red Hat Linux release 6.2 (Zoot)
Ist bei vielen Linux-Distributionen normal. Ich bevorzuge es zwar im
Zweifelsfall auch shells zu installieren, die ich nicht oder nur selten
benutze (so viel Platz nehmen die i.a. nicht weg, und sie ersparen mir
Arbeit, wenn ich z.B. auf Software stosse, die mit einem installations-
script fuer genau diese shell kommen, wie z.B. beim Newsserver diablo,
der mit csh-scripten daherkommt ...).
> Auch bei FreeBSD muß man die ksh erst nachinstallieren, hier habe ich
> das eigentlich nur wegen dieser NG getan. Auf den Rechnern in meiner
> Reichweite ist die bash wesentlich verbreiteter (aber zu 99,9%-Aussagen
> werde ich mich gewiß nicht hinreißen lassen), die verwende ich meist,
> wenn mir sh mal nicht reicht und Portabilität nicht soo wichtig ist.
die ksh duerfte unter linux nicht wesentlich verbreiteter sein als unter
[Open|Free|Net]-BSD, nur ist bei *BSD ueblicherweise (im Gegensatz zu Linux)
per default immer eine csh dabei waehrend bei Linux die csh exotisch und
die bash DIE Standard-shell ist.
>> Wenn nun auf pdksh-Level programmiert würde und dieser eine
>> von 1000 Fällen mal einträte, würde eben dieser eine User
>> 'auf den Bauch fallen' - na und.
> Diese Einstellung kennen wir von Dir bereits.
Wenn man mit nur wenig Mehraufwand ein "bourne-shell" kompatibles script
draus machen koennte, ist es in den meisten Faellen Unfug auf ksh-Spezi-
alitaeten zu bestehen ...
>> Falls ich mal die bsh mit Makefile und configure anböte,
>> wäre configure garantiert für ksh93 geschrieben.
> Configure-Scripts sind eigentlich das klassische Beispiel für eine
> Anwendung, bei der Portabilität extrem wichtig ist. Aber wir merken uns:
> Wer bsh installiert, braucht trotzdem noch ksh93. Wenn auch ungewollt -
> Du wirst langsam ehrlich.
Das Bild was sich daraus dann bildet ist zumindest teilweise erschreckend.
>> Allerdings, wenn irgendein Skript ohne Syntax-Verrenkungen
>> für sh schreibbar wäre, würde auch ich es durchaus bei diesem
>> Level belassen.
> Ob ich mich ob der Portabilität verrenke oder nicht kommt auf die
> Anwendung an. Ob mein MP3-Abspieler oder die Scripts in
> /usr/local/etc/rc.d besonders portabel sind oder nicht ist mir relativ
> Brot, bei Dingen die ich weggebe ist mir Portabilität dagegen einiges an
> Aufwand wert.
Das werden die meisten wohl so sehen (leider nicht alle) ...
>> Sämtliche technische Dinge auf der Welt erneuern sich
>> permanent. Neues kommt auf, eine Weile ist das Alte und das
>> Neue da, aber dann verkrümelt sich das Alte und nur noch das
>> Neue bleibt - Ausnahme: die sh-Skripte, sogar mit grauseligen
>> Syntax-Purzelbäumen.
> Unter Unix hat portables Programmieren Tradition. Das ist auch aus der
> Not geboren - es gibt nun mal "hunderte" Unices, und man will seine
> Programme nicht nur einer Minderheit zugänglich machen. Das gilt nicht
> nur für Shellscripts, auch für andere Programme.
Korrekt.
Juergen P. Meier
>
>die ksh duerfte unter linux nicht wesentlich verbreiteter sein als unter
>[Open|Free|Net]-BSD, nur ist bei *BSD ueblicherweise (im Gegensatz zu Linux)
>per default immer eine csh dabei waehrend bei Linux die csh exotisch und
>die bash DIE Standard-shell ist.
Wobei die bash hinreichend bourne-shell aehnlich ist, um #!/bin/sh scripte
ordentlich ausfuehren zu koennen, so das hinten das rauskommt, was
sich der author des scripts gedacht hat, als er fuer eine bourne-shell
geschrieben hat. Darum ist bei den meisten linux-distributionen /bin/sh
auch ein link auf /bin/bash.
Andere systeme haben ebenfalls oft keine plain old bourne-shell in
/bin/sh. z.b. DG/UX)
>>> Falls ich mal die bsh mit Makefile und configure anböte,
>>> wäre configure garantiert für ksh93 geschrieben.
>> Configure-Scripts sind eigentlich das klassische Beispiel für eine
>> Anwendung, bei der Portabilität extrem wichtig ist. Aber wir merken uns:
>> Wer bsh installiert, braucht trotzdem noch ksh93. Wenn auch ungewollt -
>> Du wirst langsam ehrlich.
>
>Das Bild was sich daraus dann bildet ist zumindest teilweise erschreckend.
ACK.
>>> Allerdings, wenn irgendein Skript ohne Syntax-Verrenkungen
>>> für sh schreibbar wäre, würde auch ich es durchaus bei diesem
>>> Level belassen.
>> Ob ich mich ob der Portabilität verrenke oder nicht kommt auf die
>> Anwendung an. Ob mein MP3-Abspieler oder die Scripts in
>> /usr/local/etc/rc.d besonders portabel sind oder nicht ist mir relativ
>> Brot, bei Dingen die ich weggebe ist mir Portabilität dagegen einiges an
>> Aufwand wert.
>
>Das werden die meisten wohl so sehen (leider nicht alle) ...
Wer das nicht so sieht, gibt entweder selten was an andere, oder macht
sich schnell unbeliebt.
Juergen
--
J...@lrz.fh-muenchen.de - "This World is about to be Destroyed!"
Sven Mascheck
> [Linux: /bin/sh -> bash] Andere systeme haben ebenfalls oft keine
> plain old bourne-shell in /bin/sh. z.b. DG/UX)
Warum so weit ausholen? HP-UX, AIX, Irix (ab 6.3). (Hatten wir doch erst.)
Tobias Richter
>"Raphael H. Becker" wrote:
>> Gunnar Ritter <g...@bigfoot.de> wrote:
>> > > Ich habe jedenfalls erheblich mehr Merkprobleme mit der
>> > > proprietären und zusätzlich kryptischen Syntax der ksh:
>> >
>> > Möchte jemand wissen, wobei Du »Merkprobleme« hast? Bitte melden.
>>
>> Vielleicht kann da jemand vom Bundesamt fuer Merkbefreiung eine passende
>> Loesung anbieten? Ich denke, die haben da sehr kompetente Leute.
>
>Lästert ihr nur, ihr frechen Schnösel - ich merk mir das...
Ich war doch glatt so naiv mir beim ersten Lesen ein Smiley dazu zu
denken und dabei etwas Sympathie zu empfinden.
<3B814602...@t-online.de> hat mich dann wieder geheilt.
Jetzt weiss ich auch warum man drei Homepage-URLs und drei
E-Mail-Adressen in der .sig haben muss.
F'up wg. OT.
t.
Juergen P. Meier
/bin/sh bei dg/ux ist nichtmal ne ksh. Und die /bin/sh von OSF/1
ist auch eine Krankheit.
Bei minix scheint /bin/sh eine msh zu sein. (was ich nicht mehr
nachpruefen kann.)
Felix von Leitner
> Du kannst Dein Umfeld noch so oft als »professionell« bezeichnen, es
> ändert Deine Position als Witzfigur und Gruppenkasper nicht im
> geringsten. Wenn Du behauptetest, Napoleon oder der Kaiser von China
> zu sein, wäre das exakt genauso glaubhaft.
Wieso zweifelst du seine Glaubwürdigkeit an? Ich für meinen Teil glaube
ihm sofort, daß die Leute ihm seinen Scheiß abkaufen. Die Leute wollen
verarscht werden. Sie setzen auch gerne Windows ein, oder R/3. Oder
gar beides! In diesem Kontext kann ich mir die bsh hervorragend
vorstellen. Lauter Blinde und eine bsh, und sie produzieren absolut
unwartbaren Müll, um ihre Kunden von sich abhängig zu machen.
Tja, wer's nötig hat...
Ich für meinen Teil habe diese Art der Job Security nicht nötig, um
ausreichend Geld zu verdienen. Aber als Autor der schlechtesten Shell
der Welt muß man wahrscheinlich zu solchen Maßnahmen greifen.
Felix
Sven Mascheck
>>> [Linux: /bin/sh -> bash] Andere systeme haben ebenfalls oft keine
>>> plain old bourne-shell in /bin/sh. z.b. DG/UX)
>> Warum so weit ausholen? HP-UX, AIX, Irix (ab 6.3).
(Anregung bzgl. der kommerziellen Unixe aufgegriffen)
> /bin/sh bei dg/ux ist nichtmal ne ksh.
(Auf die Gefahr einer Rekursion hin) Wie ja auch früher Free- und
NetBSD (sowie BSDI) mit einer Shell basierend auf ash(1), der
»Almquist Shell«(?). Als was man den aktuellen Stand der /bin/sh
auf den beiden freien BSDs genauer bezeichnen würde, weiß ich nicht.
Weder die Manpage, noch das FreeBSD Handbook gehen darauf ein.
Wahrscheinlich stecken schlicht zahlreiche Bugfixes sowie dies und
das an POSIX.2-Konformität drin.
OpenBSD hat ja hingegen die pdksh(1) (AFAIK: mehr Betonung auf POSIX.2
und zumindest früher deutlich besser »maintained« als die ash(1)).
> Und die /bin/sh von OSF/1 ist auch eine Krankheit.
Sieht aus wie eine normale, vielleicht etwas ältere Bourne Shell?
Den ${1+"$@"} Bug hat sie auf OSF1/V4 jedenfalls nicht mehr.
Aber der Shell-Bugs gibt es ja viele. Was war denn auffällig?
> Bei minix scheint /bin/sh eine msh zu sein. (was ich nicht mehr
> nachpruefen kann.)
Die hatte ich vor einiger Zeit mit sehr wenigen Anpassungen auch auf
Solaris compiliert. Unter <http://www.cs.vu.nl/~ast/minix.html#getminix>
fand sich sogar ein komfortabler Link (der aber gerade eben war).
Sven
Juergen P. Meier
>Juergen P. Meier <J...@lrz.fh-muenchen.de> wrote:
>> Und die /bin/sh von OSF/1 ist auch eine Krankheit.
>
>Sieht aus wie eine normale, vielleicht etwas ältere Bourne Shell?
>Den ${1+"$@"} Bug hat sie auf OSF1/V4 jedenfalls nicht mehr.
>Aber der Shell-Bugs gibt es ja viele. Was war denn auffällig?
OSF1/V2 - Muss ich mehr sagen? *g*
Gunnar Ritter
> Thus spake Gunnar Ritter (g...@bigfoot.de):
>> Du kannst Dein Umfeld noch so oft als »professionell« bezeichnen, es
>> ändert Deine Position als Witzfigur und Gruppenkasper nicht im
>> geringsten. Wenn Du behauptetest, Napoleon oder der Kaiser von China
>> zu sein, wäre das exakt genauso glaubhaft.
>
> Wieso zweifelst du seine Glaubwürdigkeit an? Ich für meinen Teil glaube
> ihm sofort, daß die Leute ihm seinen Scheiß abkaufen.
Das bestreite ich auch nicht. Aber wenn »professionell« irgendeine
positive Konnotation haben sollte, paßt das Wort hier nicht.
Grüße,
Gunnar
Gunnar Ritter
> Sven Mascheck <sven.m...@student.uni-ulm.de> wrote:
>>Juergen P. Meier <J...@lrz.fh-muenchen.de> wrote:
>>> Und die /bin/sh von OSF/1 ist auch eine Krankheit.
>>
>>Sieht aus wie eine normale, vielleicht etwas ältere Bourne Shell?
>>Den ${1+"$@"} Bug hat sie auf OSF1/V4 jedenfalls nicht mehr.
Die Bezeichnung »Bug« scheint mir fehl am Platze. Hier hat man mal
(wann eigentlich genau - SVr3, SVr4 - vielleicht eine Übernahme aus
der ksh, die es 1986 schon so machte?) eine Änderung vorgenommen, um
»"$@"« anders als »"$sonstwas"« zu nichts anstatt zum leeren String
expandieren zu lassen. Auch wenn das vielleicht intuitiver ist, es
ist nicht selbstverständlich.
>>Aber der Shell-Bugs gibt es ja viele. Was war denn auffällig?
>
> OSF1/V2 - Muss ich mehr sagen? *g*
Ja, bitte (oder einen Link o.ä.).
Grüße,
Gunnar
Felix von Leitner
> > ihm sofort, daß die Leute ihm seinen Scheiß abkaufen.
> Das bestreite ich auch nicht. Aber wenn »professionell« irgendeine
> positive Konnotation haben sollte, paßt das Wort hier nicht.
Professionell heißt lediglich, daß er es beruflich betreibt.
D.h. mehr als daß er Umweltschützer gefunden hat, die ihm für die
Entsorgung seines Sondermülls finanziell unter die Arme greifen, kann
man da erst einmal nicht draus schließen. Und das finde ich gut, ja
geradezu vorbildlich. Nur scheint er das irgendwie falsch verstanden zu
haben.
Felix
Helmut Schellong
Nö, trifft alles nicht zu.
Während ihr lästert, habe ich gearbeitet und die Compile-Funktion
der REs bei Zeichenklassen fast um den Faktor 3 beschleunigt.
Ist jetzt 7-fach bzw. 15-fach schneller als die RE aus dietlibc.
Helmut Schellong
>
> Hallo,
>
> Helmut Schellong <sche...@t-online.de> wrote:
> >> Du musst ein Gott sein - sogar die Überheblichkeit und der Grössenwahn
> >> könnten nicht besser getroffen sein. Wo ist der Tempel, in dem man dich
> >> anbeten kann?
> > Willst Du ein Pilger sein?
> > Das geht, darauf bin ich eingerichtet.
> > Du mußt auf den Knien zu meinem Thron rutschen
> > und dabei mehrmals laut und vernehmlich ausrufen:
> > El Supremo, El Supremo, ...
>
> Fuer diejenigen, die das nicht tun wollen und sich statt dessen ueber
> die Besonderheiten, Macken und Eigentuemlichkeiten der "bsh" von Helumut
> informieren moechten, steht mittlerweile unter der URL:
>
> http://members.pop-hannover.de/~ilse/bsh-programming-harmful.html
>
> eine Beschreibung der bsh im Vergleich zu "ueblichen" unix-shells zur
> Verfuegung. Der Text stammt von Gunnar Ritter, die (quick&dirty) Umset-
> zung nach HTML stammt von mir.
Und
http://www.schellong.com/bsh-programming.htm
enthält meine Stellungnahmen dazu.
Felix von Leitner
> Nö, trifft alles nicht zu.
> Während ihr lästert, habe ich gearbeitet und die Compile-Funktion
> der REs bei Zeichenklassen fast um den Faktor 3 beschleunigt.
> Ist jetzt 7-fach bzw. 15-fach schneller als die RE aus dietlibc.
Bei Gelegenheit kannst du dir ja mal erklären lassen, was eine extended
regular expression ist, damit du dich nicht immer so lächerlich machst.
Helmut Schellong
Die muß man aber per Flag explizit aktivieren, was ich nicht tat.
Gunnar Ritter
>> http://members.pop-hannover.de/~ilse/bsh-programming-harmful.html
>>
>> eine Beschreibung der bsh im Vergleich zu "ueblichen" unix-shells zur
>> Verfuegung. Der Text stammt von Gunnar Ritter, die (quick&dirty) Umset-
>> zung nach HTML stammt von mir.
>
> Und
>
> http://www.schellong.com/bsh-programming.htm
>
> enthält meine Stellungnahmen dazu.
Ich habe Dir nicht gestattet, meinen Text komplett zu zitieren. Ändere
das umgehend. - Zu Deinen Anmerkungen ist nicht viel zu sagen, sie sind
lächerlich, wie man es von Dir gewohnt ist; ansonsten wurde dazu alles
sachliche gesagt.
Grüße,
Gunnar
Gunnar Ritter
> Während ihr lästert, habe ich gearbeitet und die Compile-Funktion
> der REs bei Zeichenklassen fast um den Faktor 3 beschleunigt.
> Ist jetzt 7-fach bzw. 15-fach schneller als die RE aus dietlibc.
Solange das Closed Source ist, die zudem von jemandem stammt, dem der
Ruf eines Pfuschers im ganzen Usenet vorauseilt, geht mir das komplett
am Arsch vorbei. Im übrigen ist RE-Code an und für sich hier off-topic,
such Dir eine andere Newsgroup, um mit Deinen C-Kunststückchen Clown
zu spielen.
Grüße,
Gunnar
Helmut Schellong
Wer hat denn dies Thema (RE/dietlibc) hier eingebracht?!
Gunnar Ritter
>> Im übrigen ist RE-Code an und für sich hier off-topic, such Dir eine
>> andere Newsgroup, um mit Deinen C-Kunststückchen Clown zu spielen.
>
> Wer hat denn dies Thema (RE/dietlibc) hier eingebracht?!
Du, in diesen Thread. Alles andere ist Schnee von vorvorgestern.
Grüße,
Gunnar
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> wrote:
>
> >> http://members.pop-hannover.de/~ilse/bsh-programming-harmful.html
> >>
> >> eine Beschreibung der bsh im Vergleich zu "ueblichen" unix-shells zur
> >> Verfuegung. Der Text stammt von Gunnar Ritter, die (quick&dirty) Umset-
> >> zung nach HTML stammt von mir.
> >
> > Und
> >
> > http://www.schellong.com/bsh-programming.htm
> >
> > enthält meine Stellungnahmen dazu.
>
> Ich habe Dir nicht gestattet, meinen Text komplett zu zitieren. Ändere
> das umgehend.
Sobald öffentliche, explizite Angriffstexte mit entsprechender,
klar einseitiger Tendenz bestehen, die 'bsh' gezielt in den Schmutz
ziehen sollen, mittels einiger weniger Schwachpunkte, die meist
im voraus dokumentiert waren und sind, mittels einiger Behauptungen, die
schlichtweg unrichtig sind, und unter gezieltem gleichzeitigen
Verschweigen sehr vieler Pluspunkte - NEIN.
Auf eine Schmähschrift darf man mit einer Gegendarstellung reagieren.
Helmut Schellong
Das gleiche Argument hätte ich benutzen können als dies Thema in
einen anderen Thread von jemand anderem (unaufgefordert) eingebracht
wurde.
Andere: genehm - Von mir: nicht genehm ...
Sven Mascheck
> [ "$@" vs. ${1+"$@"} Konvention ]
> Hier hat man mal (wann eigentlich genau - SVr3, SVr4 - vielleicht
> eine Übernahme aus der ksh, die es 1986 schon so machte?) eine
> Änderung vorgenommen, [...]
Auf einem »MUNIX, SVR3.1« benutzt die Bourne Shell die neue Konvention.
Sven
Gunnar Ritter
>> Ich habe Dir nicht gestattet, meinen Text komplett zu zitieren. Ändere
>> das umgehend.
>
> Sobald öffentliche, explizite Angriffstexte mit entsprechender,
> klar einseitiger Tendenz bestehen, die 'bsh' gezielt in den Schmutz
> ziehen sollen, mittels einiger weniger Schwachpunkte, die meist
> im voraus dokumentiert waren und sind, mittels einiger Behauptungen, die
> schlichtweg unrichtig sind, und unter gezieltem gleichzeitigen
> Verschweigen sehr vieler Pluspunkte - NEIN.
Die unerlaubte vollständige Wiedergabe meines Textes durch Dich
stellt eine Verletzung meiner Rechte gemäß §§ 15 und 16 UrhG dar,
insbesondere, da ich Deine Kommentare als »Entstellung des Werkes«
gemäß § 14 ansehe. Du darfst Ausschnitte gemäß § 51 Abs. 2 »in einem
durch den Zweck gebotenen Umfang« zitieren, es steht jedoch außer
Frage, daß die Wiedergabe kompletter Absätze mit Bemerkungen wie
»das stimmt halbwegs« nicht darunter fällt.
> Auf eine Schmähschrift darf man mit einer Gegendarstellung reagieren.
Gegendarstellungen gibt es nur im journalistisch-redaktionellen
Bereich. Insbesondere liegt hier keine Periodizität vor.
Grüße,
Gunnar
Felix von Leitner
Ach, es ist dir auch schon aufgefallen, daß du hier nur un(an)genehme
Scheiße postest? Ja warum tust du es denn dann noch?!
Helmut Schellong
Gleiches Recht für alle...
Sven Mascheck
> Juergen P. Meier <J...@lrz.fh-muenchen.de> wrote:
>> Und die /bin/sh von OSF/1 ist auch eine Krankheit.
> Den ${1+"$@"} Bug hat sie auf OSF1/V4 jedenfalls nicht mehr.
Ohje, ich bitte um Verzeihung: falsch aus dem Gedächtnis geschrieben.
Sie hat ihn noch.
Gunnar Ritter
Wie aktuell ist OSF1/V4? Sollte man das bei Skripten noch berücksichtigen?
Grüße,
Gunnar
Helmut Schellong
Es gibt grundsätzlich ein Recht auf Gegendarstellung/Entgegenhaltung,
in dem die spezielle Gegendarstellung im Rahmen des Presserechts
enthalten ist:
Die Presserecht-Gegendarstellung zwingt den Medienhersteller,
in der nächsterreichbaren Ausgabe die Gegendarstellung kostenlos
und ohne Rücksicht auf deren Wahrheitsgehalt an gleicher Stelle
(z.B. Titelseite) bis hin zum gleichen Umfang zu veröffentlichen.
Hieraus ergibt sich zwangsläufig die besagte Periodizität.
Wer ein Pamphlet herstellt, das eine Person und dessen Produkt
vom tendenziösen Inhalt her öffentlich verunglimpfen soll,
hat seinen Zitatschutz aus dem UrhG bezüglich dieses Textes
und der Zielperson verwirkt.
Man hat immer das Recht, schnellstmöglich Schaden zu begrenzen
oder abzuwenden, wobei man sich zwangsläufig an den unmittelbaren
potentiellen Schadenverursacher -das Pamphlet- halten muß.
Als Beispiel kann man Götz George nennen, der nach seiner
Kritik in der Sendung "Wetten daß" alle seine 27 Prozesse
auf Schadenersatz ohne Abstriche zu 100% gewonnen hat;
weil 27 Zeitschriften leichtfertig meinten, sie dürften
irgendwas für ihn Nachteiliges nach seinem Auftritt in
der Sendung öffentlich berichten.
Fazit: Vorsichtig sein mit öffentlichen Herabsetzungen und
Verunglimpfungen - und persönlichen Beleidigungen.
Eckhard Sebastian Maass
> Auf eine Schmähschrift darf man mit einer Gegendarstellung reagieren.
Sure. Aber kennzeichne deine Gegendarstellung mal besser ... ich hab die
mir mit w3m angeschaut - dein Text war von Gunnars nicht unterscheidbar.
Die Unterschiede nur durch '<font color= ...>' zu kennzeichnen ist ...
schwach, schwaches HTML.
CU,
SEcki
--
God is Dead. -- Nietzsche
Nietzsche is Dead. -- God
Nietzsche is God. -- The Dead
Christian Weisgerber
> (Auf die Gefahr einer Rekursion hin) Wie ja auch früher Free- und
> NetBSD (sowie BSDI) mit einer Shell basierend auf ash(1), der
> »Almquist Shell«(?). Als was man den aktuellen Stand der /bin/sh
> auf den beiden freien BSDs genauer bezeichnen würde, weiß ich nicht.
> Weder die Manpage, noch das FreeBSD Handbook gehen darauf ein.
> Wahrscheinlich stecken schlicht zahlreiche Bugfixes sowie dies und
> das an POSIX.2-Konformität drin.
Genau. Wobei die FreeBSD und NetBSD-Varianten nicht untereinander
abgeglichen sind. Besonders auffälliger Unterschied: NetBSD sh(1)
hat test(1) als Builtin, FreeBSD nicht.
> OpenBSD hat ja hingegen die pdksh(1) (AFAIK: mehr Betonung auf POSIX.2
> und zumindest früher deutlich besser »maintained« als die ash(1)).
Ja, ash ist schon ewig ein Waisenkind. Allerdings tut sich upstream
bei pdksh auch nicht mehr viel.
In letzter Zeit bereitet uns pdksh bei OpenBSD etwas Kummer. Außer
einem obskuren, schwer behebbaren Fehler, dessen Details ich nochmal
nachfragen müsste, schmiert sie beim Bauen einiger größerer libtool-
basierter Projekte auch manchmal ab, z.B. KDE und Ethereal. Inzwischen
verwenden die OpenBSD-Ports zsh für diese Pakete.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Gunnar Ritter
> Gunnar Ritter wrote:
>> Helmut Schellong <sche...@t-online.de> wrote:
>> >> Ich habe Dir nicht gestattet, meinen Text komplett zu zitieren. Ändere
>> >> das umgehend.
>> >
>> > Sobald öffentliche, explizite Angriffstexte mit entsprechender,
>> > klar einseitiger Tendenz bestehen, die 'bsh' gezielt in den Schmutz
>> > ziehen sollen, mittels einiger weniger Schwachpunkte, die meist
>> > im voraus dokumentiert waren und sind, mittels einiger Behauptungen, die
>> > schlichtweg unrichtig sind, und unter gezieltem gleichzeitigen
>> > Verschweigen sehr vieler Pluspunkte - NEIN.
>>
>> Die unerlaubte vollständige Wiedergabe meines Textes durch Dich
>> stellt eine Verletzung meiner Rechte gemäß §§ 15 und 16 UrhG dar,
>> insbesondere, da ich Deine Kommentare als »Entstellung des Werkes«
>> gemäß § 14 ansehe. Du darfst Ausschnitte gemäß § 51 Abs. 2 »in einem
>> durch den Zweck gebotenen Umfang« zitieren, es steht jedoch außer
>> Frage, daß die Wiedergabe kompletter Absätze mit Bemerkungen wie
>> »das stimmt halbwegs« nicht darunter fällt.
>> [...]
> Wer ein Pamphlet herstellt, das eine Person und dessen Produkt
> vom tendenziösen Inhalt her öffentlich verunglimpfen soll,
Wir sprechen hier nicht über ein Pamphlet, sondern um einen absolut
sachlichen Text, der die Gefährlichkeit Deiner Software anhand einer
Reihe konkreter Belege nachweist und abschließend vor ihrem Einsatz
warnt. Ich verunglimpfe Deine Person darin in keiner Weise. Wenn Du
anderer Ansicht bist, belege das mit konkreten Zitaten.
> hat seinen Zitatschutz aus dem UrhG bezüglich dieses Textes
> und der Zielperson verwirkt.
Möchtest Du das vor Gericht abklären lassen? Im übrigen habe ich nichts
dagegen, daß Du Dich zu dem Text äußerst, das ist in der Tat Dein gutes
Recht. Du kannst gerne einen Link dazu setzen und die Passagen, auf die
Du unmittelbar eingehst, zitieren. Es geht um die Form der Übernahme,
nicht um das, was Du dazu sagst.
Ich setze Dir jetzt eine Frist bis Freitag, 12 Uhr; wenn Du den Text bis
dahin nicht entsprechend abgeändert hast, behalte ich mir die Einleitung
rechtlicher Maßnahmen vor.
Zum Thema »Gegendarstellung« solltest Du Dir im übrigen einmal
<http://www.rechtsanwalt.de/gegendarstellung.html> durchlesen.
Grüße,
Gunnar
Dirk Stander
> Sven Mascheck <sven.m...@student.uni-ulm.de> wrote:
> Genau. Wobei die FreeBSD und NetBSD-Varianten nicht untereinander
> abgeglichen sind. Besonders auffälliger Unterschied: NetBSD sh(1)
> hat test(1) als Builtin, FreeBSD nicht.
>> OpenBSD hat ja hingegen die pdksh(1) (AFAIK: mehr Betonung auf POSIX.2
>> und zumindest früher deutlich besser »maintained« als die ash(1)).
[..]
> In letzter Zeit bereitet uns pdksh bei OpenBSD etwas Kummer. Außer
> einem obskuren, schwer behebbaren Fehler, dessen Details ich nochmal
> nachfragen müsste,
Ups, bitte poste mal einen Pointer.
> schmiert sie beim Bauen einiger größerer libtool-
> basierter Projekte auch manchmal ab, z.B. KDE und Ethereal. Inzwischen
> verwenden die OpenBSD-Ports zsh für diese Pakete.
Ich sehe bei Ethereal nichts ungewöhnliches.
TIA, Gruß Dirk :.
Sven Mascheck
> Wie aktuell ist OSF1/V4? Sollte man das bei Skripten noch berücksichtigen?
Ich frage mich auch oft, wieviel Installationen es davon überhaupt
noch geben mag. In comp.unix.tru64 findet sich durchaus Traffic.
»Tru64« ist der Marketing Name seit DEC von Compaq gekauft wurde
(Ende '99?), vorher war es »Digital Unix«.
(In comp.unix.osf.osf1 hingegen ist es schon deutlich weniger Traffic.)
Das erste »V4« stammt wohl von 96,
V4.0B (Rev. 564): 2/98,
V4.0F (Rev. 1229): 12/99. (ist offiziell Y2K)
V5 wohl ab 8/99, aber das kenne ich nicht.
Es gibt auf OSF1 ja noch eine POSIX Shell als /usr/bin/posix/sh,
die sich dann als ksh-M88f bezeichnet.
»getconf _CS_PATH« funktioniert auf V4 aber übrigens nicht:
getconf: specified variable is not valid on this system
Exotisch: Wenn BIN_SH mit »xpg4« gesetzt ist, ersetzt sich eine
neu aufgerufene /bin/sh durch die POSIX Shell - also sowohl bei
»/bin/sh script«, wie auch über den #! Mechanismus (»./script«).
Man kann BIN_SH sogar auch noch auf »svr4« setzen, aber diese
Shell ist nicht unbedingt in einer Installation enthalten.
DEC konnte sich wohl noch nie für eine modernere Bourne Shell oder
gar eine POSIX Shell als Default entscheiden, auf Ultrix war das ja
sh(1) vs. sh5(1) (5 für System V).
Sven
Gunnar Ritter
> »getconf _CS_PATH« funktioniert auf V4 aber übrigens nicht:
> getconf: specified variable is not valid on this system
Funktioniert »getconf PATH«? Standard und Rationale sind an dieser
Stelle nicht so ganz eindeutig.
Grüße,
Gunnar
Sven Mascheck
(Verzeihung: ich hatte CS_PATH, ohne führenden »_« nicht ebenso ausprobiert.
Alle anderen Systeme die ich kenne, akzeptieren es mit _ und v.a.: laut
<3AC3B9FC....@bigfoot.de> steht es in ISO/IEC 9945-2:1993 ja ebenso)
Aber mit diesem führt es zum gleichen Resultat wie mit PATH: Nur »/usr/bin«.
Wie die Posix Shell liegt das Posix make jedoch in /usr/bin/posix/,
und außer mit dem absoluten Pfad hilft make(1p) nicht weiter.
(Setzen von BIN_SH der Vollständigkeit halber ändert auch nichts.)
In getconf(1) werden CS_PATH und PATH mit »A value for the PATH environment
variable that finds all standard utilities« umschrieben.
_POSIX_VERSION ist 199506, _XOPEN_XCU_VERSION ist 4.
Und in standards(5) oder getconf(1) findet sich nichts weiteres.
Nicht das es wichtig wäre, aber warum DEC da wohl ein Extra-Süppchen
gekocht hat...
Sven
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
>> Sven Mascheck <sven.m...@student.uni-ulm.de> wrote:
>>> »getconf _CS_PATH« funktioniert auf V4 aber übrigens nicht:
>>> getconf: specified variable is not valid on this system
>
>> Funktioniert »getconf PATH«? Standard und Rationale sind an dieser
>> Stelle nicht so ganz eindeutig.
>
> (Verzeihung: ich hatte CS_PATH, ohne führenden »_« nicht ebenso ausprobiert.
> Alle anderen Systeme die ich kenne, akzeptieren es mit _ und v.a.: laut
> <3AC3B9FC....@bigfoot.de> steht es in ISO/IEC 9945-2:1993 ja ebenso)
Ja, in der Rationale. Im eigentlichen Standardtext zu getconf stand
IIRC (habs gerade nicht zur Hand) so was ähnliches wie in getconf(XCU),
SUSv2, und danach könnte man davon ausgehen, daß nur »getconf PATH« zu
akzeptieren wäre. Wie gesagt, nicht ganz eindeutig.
> Nicht das es wichtig wäre, aber warum DEC da wohl ein Extra-Süppchen
> gekocht hat...
Ich tippe auf simple Unachtsamkeit. Wer Standard und Rationale kennt,
wird der Einfachheit halber alle Schreibweisen implementieren.
Grüße,
Gunnar
Sven Mascheck
>> [...] warum DEC da wohl ein Extra-Süppchen gekocht hat...
> Ich tippe auf simple Unachtsamkeit. [Schreibweisen]
Ja, wobei ich eigentlich den Wert von CS_PATH/PATH meinte, vor allem
wegen make(1p). Der BIN_SH Mechanismus ist hingegen wohl für Shell
Programmierer gedacht? - Vielleicht zum Testen von Umstellungen u.ä.,
da ja schließlich sogar der #! Mechanismus betroffen ist...
Helmut Schellong
>
> * Helmut Schellong <sche...@t-online.de>:
> > Auf eine Schmähschrift darf man mit einer Gegendarstellung reagieren.
>
> Sure. Aber kennzeichne deine Gegendarstellung mal besser ... ich hab die
> mir mit w3m angeschaut - dein Text war von Gunnars nicht unterscheidbar.
> Die Unterschiede nur durch '<font color= ...>' zu kennzeichnen ist ...
> schwach, schwaches HTML.
Bei einer .htm-Datei mit doctype-Eintrag kann man aber
davon ausgehen, daß mit einem adäquaten Programm betrachtet wird.
Es muß einem klar sein, daß z.B. Lynx sehr viel Information
vorenthält.
Der <font>-Tag ist HTML3.2.
Gerade das sind ja die üblichen Mittel, um in HTML
optische Abgrenzungen zu erzielen.
Raphael H. Becker
> Es muß einem klar sein, daß z.B. Lynx sehr viel Information
> vorenthält.
> Der <font>-Tag ist HTML3.2.
> Gerade das sind ja die üblichen Mittel, um in HTML
> optische Abgrenzungen zu erzielen.
Schonmal den Unterschied zwischen logischer und physischer Textformatierung
gesehen? Schonmal dran gedacht, welche Farbe ein Blinder sieht, der sich
seine Webseiten vorlesen laesst?
Gruss
Raphael Becker
--
t(){ while [ -n "$1" ];do T=/tmp/$$.html;lynx -source "http://dict.leo.\
org/?search=$1"|grep search\ result >$T&&w3m -dump $T;rm $T;shift;done;}
[ -n "$1" ]&&t "$@"||while read -ep dict2\> W;do t $W|more; done #by rhb
# http://rhb.swm.uni-mannheim.de/scripts/dict2
Ulf Volmer
> Der <font>-Tag ist HTML3.2.
> Gerade das sind ja die üblichen Mittel, um in HTML
> optische Abgrenzungen zu erzielen.
Du möchtest aber keine optische Trennung,
sondern eine strukturelle.
ps: Du hast es tatsächlich aus dem bsh- Filter geschafft.
Ob das anhält?
ulf
Juergen P. Meier
>Eckhard Sebastian Maass wrote:
>>
>> * Helmut Schellong <sche...@t-online.de>:
>> > Auf eine Schmähschrift darf man mit einer Gegendarstellung reagieren.
>>
>> Sure. Aber kennzeichne deine Gegendarstellung mal besser ... ich hab die
>> mir mit w3m angeschaut - dein Text war von Gunnars nicht unterscheidbar.
>> Die Unterschiede nur durch '<font color= ...>' zu kennzeichnen ist ...
>> schwach, schwaches HTML.
>
>Bei einer .htm-Datei mit doctype-Eintrag kann man aber
>davon ausgehen, daß mit einem adäquaten Programm betrachtet wird.
>Es muß einem klar sein, daß z.B. Lynx sehr viel Information
>vorenthält.
>Der <font>-Tag ist HTML3.2.
>Gerade das sind ja die üblichen Mittel, um in HTML
>optische Abgrenzungen zu erzielen.
Bei w3m wuerde er ja sogar dem farb-tag folgen, wenn es denn die
terminfo ihm erlauben wuerde. Da ich hier jedoch nur eine 2-farbige
(weis und schwarz) habe, und es wenig sinn macht, gunnar's text
in schwarz-auf-schwarz darzustellen, hast du damit verloren.
Es gibt viel aeltere methoden, zitierten Text hervorzuheben, ohne
Bunte Farben zu verwenden.
Juergen
--
J...@lrz.fh-muenchen.de - "This World is about to be Destroyed!"
Andreas Riedel
>> > Auf eine Schmähschrift darf man mit einer Gegendarstellung reagieren.
>>
>> Sure. Aber kennzeichne deine Gegendarstellung mal besser ... ich hab die
>> mir mit w3m angeschaut - dein Text war von Gunnars nicht unterscheidbar.
>> Die Unterschiede nur durch '<font color= ...>' zu kennzeichnen ist ...
>> schwach, schwaches HTML.
>
> Bei einer .htm-Datei mit doctype-Eintrag kann man aber
> davon ausgehen, daß mit einem adäquaten Programm betrachtet wird.
html2ps -> sw-Drucker, Braille-Zeile, ...
> Es muß einem klar sein, daß z.B. Lynx sehr viel Information
> vorenthält.
> Der <font>-Tag ist HTML3.2.
> Gerade das sind ja die üblichen Mittel, um in HTML
> optische Abgrenzungen zu erzielen.
Es gibt in HTML das Tag <cite>. Das ist für Zitate vorgesehen. Erst wenn
das verwendet wird, liegt es in der Verantwortung des Betrachters, ein
Zitat als solches zu erkennen.
Farben und ähnlichen Kram kann man zusätzlich verwenden, so man will.
Aber wenn die Beschreibungssprache ein Mittel zur Kennzeichnung von
Zitaten bietet und man verwendet das nicht, hat man seine Zitate nicht
gekennzeichnet.
Gruß
Andreas
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Helmut Schellong
>
> Helmut Schellong schrieb:
> >> > Auf eine Schmähschrift darf man mit einer Gegendarstellung reagieren.
> >>
> >> Sure. Aber kennzeichne deine Gegendarstellung mal besser ... ich hab die
> >> mir mit w3m angeschaut - dein Text war von Gunnars nicht unterscheidbar.
> >> Die Unterschiede nur durch '<font color= ...>' zu kennzeichnen ist ...
> >> schwach, schwaches HTML.
> >
> > Bei einer .htm-Datei mit doctype-Eintrag kann man aber
> > davon ausgehen, daß mit einem adäquaten Programm betrachtet wird.
>
> html2ps -> sw-Drucker, Braille-Zeile, ...
>
> > Es muß einem klar sein, daß z.B. Lynx sehr viel Information
> > vorenthält.
> > Der <font>-Tag ist HTML3.2.
> > Gerade das sind ja die üblichen Mittel, um in HTML
> > optische Abgrenzungen zu erzielen.
>
> Es gibt in HTML das Tag <cite>. Das ist für Zitate vorgesehen. Erst wenn
> das verwendet wird, liegt es in der Verantwortung des Betrachters, ein
> Zitat als solches zu erkennen.
>
> Farben und ähnlichen Kram kann man zusätzlich verwenden, so man will.
> Aber wenn die Beschreibungssprache ein Mittel zur Kennzeichnung von
> Zitaten bietet und man verwendet das nicht, hat man seine Zitate nicht
> gekennzeichnet.
Na gut, dann werde ich auch noch ZEICHEN davorsetzen,
und <cite> mal per Hand einsetzen/probieren.
Sven Mascheck
[ OSF1/V4: /bin/sh benutzt alte "$@" Konvention, $BIN_SH erlaubt
Auswahl zwischen Shells, getconf(1) gibt POSIX PATH nicht aus.]
> V5 wohl ab 8/99, aber das kenne ich nicht.
PS: Alles unverändert
Christian Weisgerber
> > In letzter Zeit bereitet uns pdksh bei OpenBSD etwas Kummer. Außer
> > einem obskuren, schwer behebbaren Fehler, dessen Details ich nochmal
> > nachfragen müsste,
>
> Ups, bitte poste mal einen Pointer.
»set -e« ist kaputt. pdksh terminiert, wenn die linke Seite von
»&&« keinen Erfolg liefert.
set -e
for i in foo bar baz; do
echo "$i"
test "$i" = "bar" && echo "have a drink"
done
Hier bricht pdksh im ersten Durchlauf ab. In normalen Skripten fällt
das mangels »-e« nicht auf, wohl aber in Shell-Fragmenten in
Makefiles, die alle mit »-e« ausgeführt werden.
Norbert Narten
>
> Lästert ihr nur, ihr frechen Schnösel - ich merk mir das...
>
> --
> Mit freundlichen Grüßen
> Helmut Schellong po...@schellong.de po...@schellong.com
> http://www.schellong.de http://www.schellong.com
> http://home.t-online.de/home/schellong sche...@t-online.de
Fehlt da nicht irgendwo ein ;-) ... ???
--
Norbert
******************************
e-Mail: N.Na...@netcologne.de
e-Mail: nor...@narten.de
******************************
----------------------------------------------------------------
"Man kennt nur die dinge, die man zaehmt", sagte der Fuchs. "Die
Menschen haben keine Zeit mehr, irgend etwas kennenzulernen. Sie
kaufen sich alles fertig in den Geschaeften. Aber da es keine
Kauflaeden fuer Freunde gibt, haben die Leute keine Freunde
mehr. Wenn du einen Freund willst, so zaehme mich!"
Der Kleine Prinz
----------------------------------------------------------------