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.