100 dateien auf einmal erzeugen
Ronny Egner
wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
erzeugen ?
Gruß Ronny
Juergen Salk
> wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
> erzeugen ?
n=100
i=0
while [ $i -lt $n ];
do
i=$((i+1))
touch file.$i
done
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
Gunnar Ritter
> wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
> erzeugen ?
awk </dev/null 'BEGIN {
i = 0
while (i < 100)
printf("%02d\n", i++)
}' |
while read i
do
>$i
done
<http://www.sockenseite.de/usenet/plenken.html>
Grüße,
Gunnar
Gunnar Ritter
> wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
> erzeugen ?
awk </dev/null 'BEGIN {
Helmut Schellong
>
> Hallo,
>
> wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
> erzeugen ?
<bsh>
for n from 20 by 10 to 1000 repeat
do nop >fname.$n; done
</bsh>
--
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
Andreas Kretschmer
> Hallo,
> wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
> erzeugen ?
for i in `seq 100` ; do touch file.$i ; done
Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines frei-
laufenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert
frei von Micro$oft'schen Viren. (#97922 http://counter.li.org)
Was, Sie wissen nicht, wo Kaufbach ist? : N 51.05082°, E 13.56889° ;-)
Joerg Plate
touch `seq -f "file.%03g" 100`
--
"I'm working on it." <http://www.psyche.kn-bremen.de/>
jsaul
> wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
> erzeugen ?
#!/usr/bin/sh
i=0
until [ $((i++)) = 100 ]
do
touch datei.$i
done
Gruß,
jsaul
--
http://www.jsaul.de
Gunnar Ritter
>> for i in `seq 100` ; do touch file.$i ; done
> Wenn schon seq....
Richtig, »seq« ist ein Tool, das man ausrotten sollte. Der halbwegs
kompetente Programmierer erledigt dessen Aufgaben portabel und ggf.
auch viel flexibler mit ein paar Zeilen awk.
Grüße,
Gunnar
Helmut Schellong
>
> Ronny Egner wrote:
> >
> > Hallo,
> >
> > wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
> > erzeugen ?
>
> <bsh>
>
> for n from 20 by 10 to 1000 repeat
> do nop >fname.$n; done
#Mit Buchstaben:
n=$1
von=$((36#taa))
bis=$((36#taa+n-1))
for fnam from $von to $bis repeat
do nop >$((36#, fnam)); done
Andreas Kretschmer
>> for i in `seq 100` ; do touch file.$i ; done
> Wenn schon seq....
> touch `seq -f "file.%03g" 100`
ich hab's geahnt ;-)
Gunnar Ritter
> #!/usr/bin/sh
> [...]
> until [ $((i++)) = 100 ]
Warst Du nicht das Wesen, das hier vor wenigen Wochen herumpolterte,
man solle auf die eingeschränkte Portabilität solcher Konstrukte durch
explizite Nennung entsprechender Shells hinweisen? Habe ich das jetzt
als späte Einsicht oder doch nur als Selbstgerechtigkeit aufzufassen?
Grüße,
Gunnar
jsaul
> jsaul <news...@jsaul.de> wrote:
>
>> #!/usr/bin/sh
Du hast die Wahl zwischen:
ksh93, zsh, pdksh, bash
Diese Liste erhebt keinen Anspruch auf Vollständigkeit. Und falls du POSIX
und/oder SUSv2 lesen wolltest, hast du Pech gehabt.
>> [...]
>> until [ $((i++)) = 100 ]
>
> Warst Du nicht das Wesen, das hier vor wenigen Wochen herumpolterte,
> man solle auf die eingeschränkte Portabilität solcher Konstrukte durch
> explizite Nennung entsprechender Shells hinweisen? Habe ich das jetzt
Dann tu du es doch. Hindert dich niemand dran. Habe ich jetzt für dich
getan (s.o.). Falls dir noch weitere einfallen sollten, füge sie hinzu,
wenn du willst. Hast du sonst noch was daran auszusetzen?
> als späte Einsicht oder doch nur als Selbstgerechtigkeit aufzufassen?
Weil heute Sonntag ist, darfst du dir eins aussuchen.
Stefan Kanthak
> Ronny Egner wrote:
> >
> > Hallo,
> >
> > wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
> > erzeugen ?
>
> <bsh>
>
> for n from 20 by 10 to 1000 repeat
> do nop >fname.$n; done
>
> </bsh>
>
Soll das HTML sein? Nach welchem W3C-Standard?
Shell-Skript ist's auch nicht!
Du bist OffTopic!
not amused
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
>
> "Helmut Schellong" <sche...@t-online.de> schrieb:
>
> > Ronny Egner wrote:
> > >
> > > Hallo,
> > >
> > > wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
> > > erzeugen ?
> >
> > <bsh>
> >
> > for n from 20 by 10 to 1000 repeat
> > do nop >fname.$n; done
> >
> > </bsh>
> >
>
> Soll das HTML sein? Nach welchem W3C-Standard?
>
> Shell-Skript ist's auch nicht!
>
> Du bist OffTopic!
Das ist eine in Newsgroups übliche Art, einen Posting-Abschnitt
zu kennzeichnen.
Beispielsweise
<offtopic>
...
</offtopic>
<haarspalterei>
...
</haarspalterei>
usw.
Hier verwendet, um darauf hinzuweisen, daß der Text zwischen <bsh>
und </bsh> Skript-Text für die OnTopic-Shell 'bsh' ist.
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
>> jsaul <news...@jsaul.de> wrote:
>>> until [ $((i++)) = 100 ]
>>
>> Warst Du nicht das Wesen, das hier vor wenigen Wochen herumpolterte,
>> man solle auf die eingeschränkte Portabilität solcher Konstrukte durch
>> explizite Nennung entsprechender Shells hinweisen? [...]
>
> Dann tu du es doch. Hindert dich niemand dran.
Aber auf Systemen, die nur über Bourne-Shell verfügen, funktioniert
es *leider* nicht. Aber da muss auch drauf hingewiesen werden, denn
dies ist eine NG mit *technischem* Anspruch.
<998436.3...@jsaul.de>
Man kann doch nicht einfach Code in den Raum stellen, und dann nach
dem Motto "Herauszufinden, unter welcher Shell der Code läuft,
überlasse ich dem interessierten Leser zur Übung". Wenn es
Bourne-Code ist, habe ich ja noch Verständnis. Aber Code, der unter
Bourne *nicht* läuft, *muss* auch als solcher gekennzeichnet werden
(spätestens beim Implementieren!). Außerdem erhöht das die
Nützlichkeit solcher Postings, denn gerade darum geht es doch in
NG's. Und nicht darum, sich in Oberlehrermanier zu ereifern [...]
<1111825.8...@jsaul.de>
Gelungene Selbstdemontagen, ein Vergnügen für die ganze Familie. Mehr
Popcorn!
Grüße,
Gunnar
jsaul
> Gelungene Selbstdemontagen, ein Vergnügen für die ganze Familie. Mehr
> Popcorn!
Danke für deine detaillierte Recherche. Aber wenn du schon aus Postings von
mir zitierst, mache dies auch deutlich, indem du in wie allgemein üblicher
Weise zitierst, z.B. durch voranstellen von "> " und nicht durch Einrücken
um einen Tabulator. Dann schon lieber rot einfärben!
Desweiteren weise ich dich darauf hin, dass ich explizit
#!/usr/bin/sh
geschrieben habe. Was sicher an sich noch nicht zwingend darauf schließen
läßt, dass es *nicht* um eine Bourne-Shell handeln kann, da z.B. ein ganz
Schlauer einen Link auf /bin/sh gesetzt haben könnte. Daher habe ich
bereits in <1207282.4...@jsaul.de> ergänzend angemerkt, dass meine
Lösung z.B. unter ksh93, zsh, pdksh und bash läuft, was du aber weder
richtig noch falsch zitiert hast. Aber die Behauptung, meine Lösung sei
Bourne-kompatibel, willst du mir doch wohl nicht unterjubeln wollen?
Dass du über deine AWK-Lösung in <3B9172DD....@bigfoot.de> selbst
nicht begeistert bist, gestehe ich dir gern zu. Ich habe zwar nicht's gegen
AWK, ganz im Gegenteil, aber deine Lösung ist eher zum abgewöhnen. Portabel
gewiss, aber zu welchem Preis? Deinen guten Willen hast du damit aber
bewiesen, und darauf kam es ja an.
Im übrigen finde ich es höchst beneidenswert, für was für Dinge du an einem
Sonntag Nachmittag Zeit zu haben scheinst. Herzlichen Glückwunsch!
Gunnar Ritter
> Danke für deine detaillierte Recherche. Aber wenn du schon aus Postings von
> mir zitierst, mache dies auch deutlich, indem du in wie allgemein üblicher
> Weise zitierst, z.B. durch voranstellen von "> " und nicht durch Einrücken
> um einen Tabulator. Dann schon lieber rot einfärben!
Lies »Email Quotes and Inclusion Conventions« im Jargon File. Gegen
»> « spricht an dieser Stelle, daß man es i.A. zum Quoten unmittelbar
vorangegangener Postings benutzt.
NB: Dies ist eine Erläuterung für Dich als Anfänger. Wenn Du weiter
darüber diskutieren willst, such Dir eine geeignetere Gruppe.
> Daher habe ich bereits in <1207282.4...@jsaul.de> ergänzend
> angemerkt, dass meine Lösung z.B. unter ksh93, zsh, pdksh und bash
> läuft, was du aber weder richtig noch falsch zitiert hast.
Warum sollte ich das denn zitieren? Erstens sehe ich das selbst, und
zweitens interessiert es mich doch gar nicht, oder glaubst Du im Ernst,
daß ich der Lauffähigkeit Deines laienhaften Codes (unnötig unportabel,
mehr fork()/exec() als nötig, numerische != alphabetische Sortierfolge)
irgendeinen konkreten Wert beimesse? Nein, ich will der Öffentlichkeit
einfach nur demonstrieren, was sie von Deinem blöden Herumgeprolle über
Portabilität zu halten hat.
> Dass du über deine AWK-Lösung in <3B9172DD....@bigfoot.de> selbst
> nicht begeistert bist, gestehe ich dir gern zu. Ich habe zwar nicht's gegen
> AWK, ganz im Gegenteil, aber deine Lösung ist eher zum abgewöhnen. Portabel
> gewiss, aber zu welchem Preis?
Zu gar keinem. Der Code ist schnell, flexibel und für einen Menschen
auch prima zu lesen - daß das für Pseudonyme offenbar nicht zu gelten
scheint, interessiert mich nicht besonders. Und zum Schluß zeigt Dir
der Onkel noch eine Fassung, aus der Du eine Menge lernen kannst:
awk </dev/null 'BEGIN {
while (i < 100)
printf("./%02d\n", i++)
}' | xargs touch
So, jsaul, jetzt aber schnell ins Bettchen, sonst versäumst Du zuviel
Schlaf und wirst nie ein ordentlicher Programmierer. Du kannst Dich ja
mal wieder melden, falls Du in ein paar Jahren wirklich was von der
Sache verstehen solltest.
Grüße,
Gunnar
Matthias Andree
> <bsh>
Niemand wird Deine bsh für so ein triviales Problem kaufen. Verzieh Dich.
--
Matthias Andree
Outlook (Express) users: press Ctrl+F3 for the full source code of this post.
begin dont_click_this_virus.exe
end
Matthias Andree
> wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
> erzeugen ?
##############################
# n sei die Zahl der zu erzeugenden Dateien, hier 42. Angelegt werden
n=42
i=1
while [ $i -le $n ] ; do
touch $i || break # wir nehmen einfach die Zahl als Dateiname
# wenn was schiefgeht, ist hier Ende der Schleife (break)
i=$(expr $i + 1) # oder i=$((i+1))
done
##############################
Dürfte mit jeder gewaschenen Bourne-Shell funktionieren, ash, bash, ksh,
zsh fressen das Zeug jedenfalls.
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> writes:
>
> > <bsh>
>
> Niemand wird Deine bsh für so ein triviales Problem kaufen. Verzieh Dich.
kaufen ???
jsaul
> "Ronny Egner" <Ronny...@gmx.de> writes:
>
>> wie kann ich eine Anzahl von "n" Dateien per for-Schleife oder ähnlichem
>> erzeugen ?
>
> ##############################
> # n sei die Zahl der zu erzeugenden Dateien, hier 42. Angelegt werden
> n=42
> i=1
> while [ $i -le $n ] ; do
> touch $i || break # wir nehmen einfach die Zahl als Dateiname
> # wenn was schiefgeht, ist hier Ende der Schleife
> # (break)
> i=$(expr $i + 1) # oder i=$((i+1))
> done
> ##############################
>
> Dürfte mit jeder gewaschenen Bourne-Shell funktionieren, ash, bash, ksh,
^^^^^^^^^^^
> zsh fressen das Zeug jedenfalls.
Falsch. ash, bash, ksh, zsh & Co. "fressen" es zwar, damit ist es aber
nicht Bourne-kompatibel:
i=$(expr $i + 1)
Das willst du uns doch wohl nicht etwa als Bourne verkaufen, oder?
i=$((i+1))
Das etwa auch? Wenn man »Bourne« sagt, sollte man auch 'ne /ungefähre/
Vorstellung davon haben, was das ist. Zumindest hier in dieser NG. Und wenn
man mit »Bourne« im Munde über andere herzieht, _dann_ erst recht.
i=`expr $i + 1`
Das wär's gewesen.
"triviales Problem" (<m3zo8di...@emma1.emma.line.org>), /das/ stimmt
allerdings.
Was ist eigentlich eine "gewaschene" Bourne-Shell?
Christian Weisgerber
> Richtig, »seq« ist ein Tool, das man ausrotten sollte.
Das sei dahingestellt, aber seq ist vor allem ein unportables
GNU-Gewächs.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Raphael H. Becker
> Matthias Andree wrote:
> > Helmut Schellong <sche...@t-online.de> writes:
> > > <bsh>
> > Niemand wird Deine bsh für so ein triviales Problem kaufen. Verzieh Dich.
> kaufen ???
Mieten?
Gruss
Raphael "f'up2p" 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
Sven Mascheck
> Desweiteren weise ich dich darauf hin, dass ich explizit
> #!/usr/bin/sh ^^^^^^^^
> geschrieben habe. Was sicher an sich noch nicht zwingend darauf schließen
> läßt, dass es *nicht* um eine Bourne-Shell handeln kann, da z.B. ein ganz
> Schlauer einen Link auf /bin/sh gesetzt haben könnte. ^^^^
^^^^^^^^ ^^^^^^
Auf praktisch allen kommerziellen Systemen ist /bin/sh identisch
mit /usr/bin/sh (und beide existent), mal abgesehen davon, bei
welchen das jetzt Kornshells wären.
Daß »/usr/bin/sh« auf vielen freien Unixen per default nicht existiert
- selbst in Verbindung mit der obigen, äußerst gewundenen Formulierung -
sagt doch letztendlich gar nichts.
Gunnar Ritter
> Was ist eigentlich eine "gewaschene" Bourne-Shell?
Wie ein denkender Mensch schon vor dem Verfassen einer Flame aus dem
Kontext erschlossen haben sollte, etwas, das das bekrittelte Konstrukt
ausführen kann. Eigentlich könntest Du inzwischen gelernt haben, in
solchen Fällen vorsichtiger zu sein, schließlich ist es nicht das erste
Mal, daß Du bei diesem Thema eine subtile Andeutung nicht verstehst.
Ach jsaul, wenn Deine Trollereien wenigstens gelegentlich mal geistreich
wären, aber so ... Du taugst bestenfalls als Bot-Futter.
Grüße,
Gunnar
jsaul
> Auf praktisch allen kommerziellen Systemen ist /bin/sh identisch
> mit /usr/bin/sh (und beide existent), mal abgesehen davon, bei
> welchen das jetzt Kornshells wären.
In der Tat. /bin ist zumindest unter SunOS sogar nur ein Link auf /usr/bin
> Daß »/usr/bin/sh« auf vielen freien Unixen per default nicht existiert
> - selbst in Verbindung mit der obigen, äußerst gewundenen Formulierung -
> sagt doch letztendlich gar nichts.
ACK. Ich war davon ausgegangen, dass /bin/sh allgemein eine Bourne-Shell ist,
bzw. Skripte mit #!/bin/sh Bourne-Shell-konform seien bzw. sein sollten.
Daher habe ich zur vermeintlichen Unterscheidung /usr/bin/sh verwendet, damit
ich hinterher nicht darstehe, als würde ich Konstrukte wie $((i++)) etc. als
Bourne-konform verkaufen wollen... Ist nicht eindeutig, das sehe ich ein,
ohne zusätzliche Erläuterung ist es schnell ein Schuss in den Ofen.
Gibt es eigentlich irgendeinen "Standard"-Pfad, an dem eine POSIX-Shell
erwartet werden darf? Damit will ich jetzt _nicht_ sagen, dass mein Skript
POSIX-konform wäre...
jsaul
> daß ich der Lauffähigkeit Deines laienhaften Codes (unnötig unportabel,
Ist denn z.B. der Code von Jürgen Salk auch "laienhaft"? Nein, ich will
meinen Code nicht dahinter verstecken. Ich demonstriere nur gerade, dass
offenbar Realnamen vs. "Pseudonyme" für Leute wie dich wichtigere Kriterien
sind als die Qualität eines Codes. Ach ja, und zu der Meisterleistung unter
<m366b1j...@emma1.emma.line.org> schweigst du dich ja ganz aus. Du
weißt warum. Es ist echt zum Kaputtlachen.
>> Dass du über deine AWK-Lösung in <3B9172DD....@bigfoot.de> selbst
>> nicht begeistert bist, gestehe ich dir gern zu. Ich habe zwar nicht's
>> gegen AWK, ganz im Gegenteil, aber deine Lösung ist eher zum abgewöhnen.
>> Portabel gewiss, aber zu welchem Preis?
>
> Zu gar keinem. Der Code ist schnell, flexibel und für einen Menschen
> auch prima zu lesen - daß das für Pseudonyme offenbar nicht zu gelten
Prima zu lesen? Prima zu /entziffern/ bestenfalls. Und das mit dem
Pseudonym bringst du stereotyp immer genau dann, wenn dir bessere Argumente
ausgegangen sind.
> scheint, interessiert mich nicht besonders. Und zum Schluß zeigt Dir
> der Onkel noch eine Fassung, aus der Du eine Menge lernen kannst:
>
> awk </dev/null 'BEGIN {
> while (i < 100)
> printf("./%02d\n", i++)
> }' | xargs touch
Das will ich ja noch als alternative Lösung akzeptieren. So man denn die
Dateien nur erzeugen will. Und um was anderes ging es ja im ursprünglichen
Posting auch nicht. Aber was soll ich daraus lernen? Habe ich da etwa was
besonders geniales übersehen? Dass du schon printf kannst? i++ beherrschst?
Bin beeindruckt. Was »./« in deinem Konstrukt für einen Sinn macht, weißt
-wenn überhaupt- wohl nur du selbst.
> So, jsaul, jetzt aber schnell ins Bettchen, [...]
Kann es sein, dass du Sonntags immer depressiv wirst, weil keiner mit dir
spielen will?
jsaul
> jsaul <news...@jsaul.de> wrote:
>
>> Was ist eigentlich eine "gewaschene" Bourne-Shell?
>
> Wie ein denkender Mensch schon vor dem Verfassen einer Flame aus dem
> Kontext erschlossen haben sollte, etwas, das das bekrittelte Konstrukt
> ausführen kann. Eigentlich könntest Du inzwischen gelernt haben, in
Ach so ist das. Du willst also sagen, dass eine Bourne-Shell das Konstrukt
i=$(expr $i + 1) # oder i=$((i+1))
verarbeiten kann? Interessant. Und falls nicht, dass "etwas, das das
bekrittelte Konstrukt ausführen kann" selbiges kann? Letzteres festzustellen
setzt, lieber Gunnar, keinerlei geistigen Klimmzüge voraus. Aber was dieses
"etwas" damit zu einer "gewaschenen" Bourne-Shell macht, hast du uns immer
noch nicht verraten.
> solchen Fällen vorsichtiger zu sein, schließlich ist es nicht das erste
> Mal, daß Du bei diesem Thema eine subtile Andeutung nicht verstehst.
Subtile Andeutungen. Was für ein dämliches Geschnattere. Dass die Behauptung
in den Raum geschmissen wird,
i=$(expr $i + 1) # oder i=$((i+1))
würde "mit jeder gewaschenen Bourne-Shell funktionieren", entschuldigst du
auch noch? _Das_ ist allenfalls was für den Schnellkomposter!
Sven Mascheck
> Ich war davon ausgegangen, dass /bin/sh allgemein eine Bourne-Shell ist,
> bzw. Skripte mit #!/bin/sh Bourne-Shell-konform seien bzw. sein sollten.
Traditionell liegt dort halt eine Bourne _kompatible_ _System_ Shell.
(Mit allen Konsequenzen - und nicht mal lt. SUSv2.)
SUSv2 äußerst sich sogar ausdrücklich negativ zum #!-Mechanismus,
(»Shell Introduction« und »Command Search and Execution«), da dieser
ja Unix-spezifisch ist (und in der speziellen Implementation übrigens
deutlich variiert). Spezielle Pfade werden sowieso nicht garantiert.
> Gibt es eigentlich irgendeinen "Standard"-Pfad, an dem eine POSIX-Shell
> erwartet werden darf?
Ausführlich in »PATH für POSIX.2«, <3AC3B9FC....@bigfoot.de>.
In »allerletzter« Konsequenz natürlich ein Henne&Ei Problem.
In der Praxis (siehe OSF1/V4+5) noch laxer gehandhabt.
Juergen Ilse
Matthias Andree <matthia...@gmx.de> wrote:
[...]
> i=$(expr $i + 1) # oder i=$((i+1))
[...]
> Dürfte mit jeder gewaschenen Bourne-Shell funktionieren, ash, bash, ksh,
> zsh fressen das Zeug jedenfalls.
Die ja, ein Posix shell wohl ebenfalls. Allerdings duerfte man mit einer
"richtig alten" Bourne shell Probleme bekommen, weil die evt. das $(...)
nicht schluckt. Wenn man auch noch auf Portabilitaet zu solchen Exempla-
ren Wert legen sollte, ist IMHO eher die Verwendung der (bei Verwendung
von manchen Zeichensaetzen nicht ganz so uebersichtlichen) "Backquotes"
gefragt (also `...` anstellen von $(...)).
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
Juergen P. Meier
>Matthias Andree wrote:
>>
>> Helmut Schellong <sche...@t-online.de> writes:
>>
>> > <bsh>
>>
>> Niemand wird Deine bsh für so ein triviales Problem kaufen. Verzieh Dich.
>
>kaufen ???
Diese Newsgroup ist in keiner weise auf Nichtkomerzielle
Nutzung der hier Diskutierten Shells eingeschraenkt.
Apriori muss man davon ausgehen, das ein Poster, sofern er
das nicht explizit anders darstellt, shellscripte im
Komerziellen Umfeld einsetzt.
Daher muesste er deine shell kaufen.
Die bsh allerdings gibt es bei AIX, Irix und OSF/1 bereits dazu.
Dumm nur, das diese bsh mit deinem Script genau garnichts anzufangen
weis.
Juergen
--
J...@lrz.fh-muenchen.de - "This World is about to be Destroyed!"
Rainer Weikusat
> Was ist eigentlich eine "gewaschene" Bourne-Shell?
<URL:http://www.opengroup.org/onlinepubs/007908799/xcu/chap2.html#tag_001_006_004>
--
stone me
Juergen Salk
>> daß ich der Lauffähigkeit Deines laienhaften Codes (unnötig unportabel,
> Ist denn z.B. der Code von Jürgen Salk auch "laienhaft"?
Leider ja. »>file.$i« wäre besser gewesen als »touch file.$i«. :-/
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
jsaul
> Matthias Andree <matthia...@gmx.de> wrote:
> [...]
>> i=$(expr $i + 1) # oder i=$((i+1))
> [...]
>> Dürfte mit jeder gewaschenen Bourne-Shell funktionieren, ash, bash, ksh,
>> zsh fressen das Zeug jedenfalls.
>
> Die ja, ein Posix shell wohl ebenfalls. Allerdings duerfte man mit einer
> "richtig alten" Bourne shell Probleme bekommen, weil die evt. das $(...)
> nicht schluckt. Wenn man auch noch auf Portabilitaet zu solchen Exempla-
Aber es fängt doch bei der /bin/sh unter SunOS 5.7 schon an, bzw hört auf.
Die schluckt obiges Konstrukt jedenfalls nicht, ohne es wieder auszuspucken.
Ob diese Shell so "richtig alt" ist, vermag ich nicht zu sagen. SunOS 5.7
jedenfalls ist nicht allzu alt. Ja, ich weiß, eine ksh gibt's dort auch,
darum ging es hier aber nicht.
Zeige mir doch mal jemand irgend eine seriöse Doku oder Fachjournal, bei der
obiges Konstrukt als Bourne-konform bezeichnet wird.
Joerg Plate
> »>file.$i« wäre besser gewesen als »touch file.$i«. :-/
--
"I'm working on it." <http://www.psyche.kn-bremen.de/>
Juergen Ilse
Joerg Plate <Pl...@psyche.kn-bremen.de> wrote:
>> »>file.$i« wäre besser gewesen als »touch file.$i«. :-/
> Weil "touch" ein externer Befehl ist?
Nein, weil anscheinend vermutet wurde, dass in dem Fall wo die Datei
bereits existiert eine "Kuerzung" auf Laenge 0 erwuenscht waere.
"touch" wuerde diese Kuerzung im Gegensatz zur empfohlenen Ausgabe-
Umlenkung nicht machen.
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Die Frage ist, ob Du lieber an 3.-Welt-Software für das |Juergen Ilse
vorletzte Jahrzehnt verreckst oder lernst, mit Technik |Internet POP Hannover
umzugehen. Wenn Personal Firewalls die Lösung sind, |Vahrenwalder Str. 205
will ich das verdammte Problem zurück. (RSS in dcsf) |30165 Hannover
Juergen Salk
>> awk </dev/null 'BEGIN {
>> while (i < 100)
>> printf("./%02d\n", i++)
>> }' | xargs touch
> Aber was soll ich daraus lernen?
Vermutlich dass ein Prozess besser ist als 100 Prozesse.
Beste Grüsse - Jürgen
Juergen Salk
[ >file.$i besser als touch file.$i ]
>> Weil "touch" ein externer Befehl ist?
> Nein, weil anscheinend vermutet wurde, dass in dem Fall wo die Datei
> bereits existiert eine "Kuerzung" auf Laenge 0 erwuenscht waere.
Nein, ich dachte in der Tat an Performance. Für den Fall, dass man
eventuell bestehende Dateiinhalte mit »>file« nicht löschen will, gibt
es wohl in den meisten Shells »set -o noclobber«.
--- snip ---
clark$ cat prog1
#!/bin/ksh
n=100
i=0
while [ $i -lt $n ];
do
i=$((i+1))
touch file.$i
done
clark$ time prog1
real 0m1.177s
user 0m0.270s
sys 0m0.230s
clark$ cat prog2
#!/bin/ksh
n=100
i=0
while [ $i -lt $n ];
do
i=$((i+1))
>file.$i
done
clark$ time prog2
real 0m0.340s
user 0m0.010s
sys 0m0.020s
--- snip ---
Beste Grüsse - Jürgen
Eckhard Sebastian Maass
> Richtig, »seq« ist ein Tool, das man ausrotten sollte. Der halbwegs
> kompetente Programmierer erledigt dessen Aufgaben portabel und ggf.
> auch viel flexibler mit ein paar Zeilen awk.
Ich benutze zur Zeit noch sehr häufig seq - wenn'a aber auch mit awk
geht. Gibt's da ein paar Beispiele? So von 1 bis 100 zählen oder das
ganze mit Nullern füllen würde mich interessieren.
Gibt's ein gutes awk-Tutorial für Einsteiger. Mich hat bisher alles, was
mit awk zu tun hatte, erschlagen oder es war zu knapp.
CU,
SEcki
--
God is Dead. -- Nietzsche
Nietzsche is Dead. -- God
Nietzsche is God. -- The Dead
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> wrote:
> >Matthias Andree wrote:
> >>
> >> Helmut Schellong <sche...@t-online.de> writes:
> >>
> >> > <bsh>
> >>
> >> Niemand wird Deine bsh für so ein triviales Problem kaufen. Verzieh Dich.
> >
> >kaufen ???
>
> Diese Newsgroup ist in keiner weise auf Nichtkomerzielle
> Nutzung der hier Diskutierten Shells eingeschraenkt.
> Apriori muss man davon ausgehen, das ein Poster, sofern er
> das nicht explizit anders darstellt, shellscripte im
> Komerziellen Umfeld einsetzt.
>
> Daher muesste er deine shell kaufen.
Nein, müßte er nicht.
Wie kommst Du darauf?
Jens Wahnes
> touch file.$i
> clark$ time prog1
> real 0m1.177s
> user 0m0.270s
> sys 0m0.230s
> >file.$i
> clark$ time prog2
> real 0m0.340s
> user 0m0.010s
> sys 0m0.020s
Interessant finde ich dabei auch folgendes:
<schnipsel>
jewa@wahnes-world:/var/tmp $ time bash -c 'seq 100 | xargs touch'
real 0m0.080s
user 0m0.050s
sys 0m0.030s
jewa@wahnes-world:/var/tmp $ rm [0-9]*
jewa@wahnes-world:/var/tmp $ time bash -c 'n=100; i=0; while [ $i -lt $n ]; do i=$((i+1)); >file.$i; done'
real 0m0.045s
user 0m0.050s
sys 0m0.000s
jewa@wahnes-world:/var/tmp $ rm file.*
jewa@wahnes-world:/var/tmp $ time bash -c 'seq 10000 | xargs touch'
real 0m16.044s
user 0m0.240s
sys 0m15.760s
jewa@wahnes-world:/var/tmp $ rm [0-9]*
jewa@wahnes-world:/var/tmp $ time bash -c 'n=10000; i=0; while [ $i -lt $n ]; do i=$((i+1)); >file.$i; done'
real 0m22.568s
user 0m3.080s
sys 0m19.450s
</schnipsel>
Jens
--
Alle Wege führen an Redmond vorbei.
jsaul
Sicher. Das ist aber auch nichts neues, auch wenn Onkel Gunnar das so
darzustellen versucht. Man _könnte_ auch die Dateien im AWK-Skript
selbst erzeugen, sogar portabel, und auf jegliche Shell-Konstrukte ganz
verzichten. Aber das schreibe ich hier nicht hin, sonst kommt noch
jemand mit OT ;-)
Und man mag zwar gegen die überflüssigen fork()'s wettern, aber in der
Praxis schreibt man ja Shell-Skripte nicht um ihrer selbst Willen,
sondern um damit zu arbeiten (Ausnahmen bestätigen wie immer die
Regel), und da stellen in den seltensten Fällen Aufrufe wie »touch«,
»expr« etc. die Flaschenhälse dar.
Die Zeitersparnis durch das Schreiben leserlicher (ich meine nicht nur
"entzifferbarer") Programme liegt in den allermeisten Fällen um viele
Größenordnungen über der, die sich durch Konstrukte wie das da oben
erreichen läßt. Und wo es auf Schnelligkeit ankommt, wird man meist eh
ein C-Programm schreiben. Man programmiert ja auch z.B. C++ nicht, weil
der resultierende Code besondes schnell wäre, sondern weil man schnell
robusten und vor allem _pflegbaren_ Code schreiben will. Code, den ein
anderer Programmierer idealerweise auf den ersten Blick versteht. Daher
verfolge ich die gleiche Philosophie in meinen Shell-Skripten, warum
auch nicht?
Ach ja, dazu passt denn auch irgendwie folgendes:
go with what you know
write till the job is done
shell, sed, awk, perl or c
doesn't matter to me
just so long as it is fun
and we can get on with the show
(Ray Bush in comp.unix.shell)
Nundenn, let's get on with the show...
Juergen Ilse
Juergen Salk <juerge...@gmx.de> wrote:
> Juergen Ilse <jue...@ilse.asys-h.de> wrote:
> [ >file.$i besser als touch file.$i ]
>>> Weil "touch" ein externer Befehl ist?
>> Nein, weil anscheinend vermutet wurde, dass in dem Fall wo die Datei
>> bereits existiert eine "Kuerzung" auf Laenge 0 erwuenscht waere.
> Nein, ich dachte in der Tat an Performance.
Dann verstehe ich dein Argument nicht. Laut deiner Messung ist zwar
die Ausfuehrungszeit deiner "optimierten" Version nur ein Viertel der
"touch" Variante, aber mal ehrlich: Wer braucht bei Ausfuehrungszeiten
von weniger als 2 Sekunden diesen Performancegewinn? Und vor allem:
Wenn er ihn braucht, warum nimmt er dann nicht am besten gleich ein
angemesseneres tool?
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
>> daß ich der Lauffähigkeit Deines laienhaften Codes (unnötig unportabel,
>
> Ist denn z.B. der Code von Jürgen Salk auch "laienhaft"?
Im konkreten Fall <8mnrm9...@salk.fqdn.th-h.de> ja. Der einzige
Vorteil gegenüber dem Deinigen liegt darin, daß »i=$((i+1))« immer
noch besser als »$((i++))« ist.
> Ach ja, und zu der Meisterleistung unter
> <m366b1j...@emma1.emma.line.org> schweigst du dich ja ganz aus.
Klar, ich muß meine Kritik nicht bei jedem neuen Posting wiederholen,
genausowenig wie ich bei jeder Erwähnung von »$(...)« trotz meiner
allseits bekannten Abneigung gegen dieses Konstrukt öffentlich auf
die Palme springen und mit Kokosnüssen werfen muß. Das wäre affig.
>> scheint, interessiert mich nicht besonders. Und zum Schluß zeigt Dir
>> der Onkel noch eine Fassung, aus der Du eine Menge lernen kannst:
>>
>> awk </dev/null 'BEGIN {
>> while (i < 100)
>> printf("./%02d\n", i++)
>> }' | xargs touch
>
> Das will ich ja noch als alternative Lösung akzeptieren.
Falls sich außer Dir noch jemand dafür interessieren sollte, was Du
von meinem Code akzeptieren willst, melde er sich bitte umgehend.
> Aber was soll ich daraus lernen?
Zuallererst, wie man fork()/exec() bei einem Kommando vermeidet, das
problemlos mehrere Dateinamen als Argumente akzeptiert.
> Habe ich da etwa was besonders geniales übersehen? Dass du schon printf
> kannst? i++ beherrschst?
Der Witz liegt zunächst darin, daß »i++« an dieser Stelle anders als
in der Shell selbst perfekt portabel ist, und dann ist awk | read eine
recht universelle Methode, Bourne-Shell-kompatibel brauchbar schnelle
Zählschleifen zu programmieren. Wenn man Deinen ständigen Beteuerungen,
an diesen Aspekten interessiert zu sein, irgendwelchen Wert beimessen
sollte, müßte Dir der Nutzen einleuchten.
Ganz nebenbei hat printf noch den Vorteil, daß man die alphabetische
Sortierfolge der zu erzeugenden Dateien der numerischen angleichen kann,
aber das deutete ich bereits an.
> Was »./« in deinem Konstrukt für einen Sinn macht,
Das ist sehr simpel:
$ touch 00 01
touch: bad time specification
$
> weißt -wenn überhaupt- wohl nur du selbst.
Das selbst herauszufinden, wäre RTFM gewesen.
Grüße,
Gunnar
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
>> jsaul <news...@jsaul.de> wrote:
>>> Was ist eigentlich eine "gewaschene" Bourne-Shell?
>>
>> Wie ein denkender Mensch schon vor dem Verfassen einer Flame aus dem
>> Kontext erschlossen haben sollte, etwas, das das bekrittelte Konstrukt
>> ausführen kann. Eigentlich könntest Du inzwischen gelernt haben, in
>
> Ach so ist das. Du willst also sagen, dass eine Bourne-Shell das Konstrukt
> i=$(expr $i + 1) # oder i=$((i+1))
> verarbeiten kann?
Vergiß es. Dies ist hier keine Sonderschule, und Du, der Du besser eine
solche zum Thema besuchen solltest (ich denke nur an »$((i++))«), bist
nicht in der Position, andere zu kritisieren. Troll Dich fort.
Alternativ könntest Du ENDLICH mal eine SUCHMASCHINE benutzen und Dich
über den verwandtschaftlichen Zusammenhang von Shells und Shell-Sprachen
informieren.
Grüße,
Gunnar
Gunnar Ritter
> * Gunnar Ritter <g...@bigfoot.de>:
>> Richtig, »seq« ist ein Tool, das man ausrotten sollte. Der halbwegs
>> kompetente Programmierer erledigt dessen Aufgaben portabel und ggf.
>> auch viel flexibler mit ein paar Zeilen awk.
>
> Ich benutze zur Zeit noch sehr häufig seq - wenn'a aber auch mit awk
> geht. Gibt's da ein paar Beispiele?
Folgendes ist eine quick-and-dirty-Implementation von seq, Korrekturen
erwünscht:
progname=`basename $0`
usage() {
echo "usage: $progname [-f format] [-s separator] [-w] [first [step]] last"
exit 2
}
fmt=%g sep='\n' wflag=0 shift=1
while getopts f:s:w0123456789 arg
do
case "$arg" in
f)
fmt="$OPTARG"
;;
s)
sep="$OPTARG"
;;
w)
wflag=1
;;
[0123456789])
shift=2 break
;;
*)
usage
esac
done
shift `expr $OPTIND - $shift`
case "$fmt" in
*%[efg]*%[efg]*)
echo "$progname: invalid format string" >&2
usage
;;
*%[efg]*)
;;
*)
echo "$progname: invalid format string" >&2
usage
esac
first=1
case $# in
1)
;;
2)
first="$1" shift
;;
3)
first="$1" step="$2" shift 2
;;
*)
usage
esac
last="$1"
invinc() {
echo "$progname: invalid step" >&2
exit 2
}
if test "$first" -lt "$last"
then
cmp=\<
if test -n "$step"
then
test "$step" -lt 1 && invinc
else
step=1
fi
else
cmp=\>
if test -n "$step"
then
test "$step" -gt -1 && invinc
else
step=-1
fi
fi
awk </dev/null 'BEGIN {
if ('$wflag' == 1)
format = sprintf("%%0%d%s%s", length("'"$last"'"), \
substr("'"$fmt"'", 2), "'"$sep"'")
else
format = "'"$fmt$sep"'"
i = '"$first"'
while (i '$cmp'= '"$last"') {
printf(format, i)
i += '"$step"'
}
}'
> So von 1 bis 100 zählen oder das ganze mit Nullern füllen würde mich
> interessieren.
Ruf das Skript mit »sh -x« auf und schau Dir den unteren Teil an. Lies
ferner awk(1), printf(3C). Außerdem habe ich in diesem Thread bereits
zwei einfachere Beispiele gepostet.
Grüße,
Gunnar
Gunnar Ritter
> Und man mag zwar gegen die überflüssigen fork()'s wettern, aber in der
> Praxis schreibt man ja Shell-Skripte nicht um ihrer selbst Willen,
> sondern um damit zu arbeiten (Ausnahmen bestätigen wie immer die
> Regel), und da stellen in den seltensten Fällen Aufrufe wie »touch«,
> »expr« etc. die Flaschenhälse dar.
Wenn Du in Deiner bescheidenen Kinderstube keine Performanceprobleme
ausgerechnet mit »expr« hast, ist das zwar schön für Dich, aber noch
lange nichts von öffentlicher Relevanz. Daß Du mit der Shell nur
Pipifax machst, heißt noch nicht, daß das andere ebenfalls tun.
Klar, Loser können mit Loser-Skripten etwas anfangen, deshalb heißen
sie ja so.
Grüße,
Gunnar
Gunnar Ritter
> [...], aber mal ehrlich: Wer braucht bei Ausfuehrungszeiten von weniger
> als 2 Sekunden diesen Performancegewinn?
Ich. Mich interessiert das spätestens dann, wenn ich ein Skript daraus
mache und es täglich interaktiv benutze.
> Und vor allem: Wenn er ihn braucht, warum nimmt er dann nicht am besten
> gleich ein angemesseneres tool?
Wieso sollte er nicht die Shell nehmen? Mit ein bißchen Nachdenken kommt
man doch problemlos zu besserem Code, ohne irgendeinen Vorteil der Shell
(Portabilität, Flexibilität) einbüßen zu müssen. Wenn das nicht möglich
wäre, würde ich Dir zustimmen, aber eine Rechtfertigung für hingehunzte
Skripte kann man daraus nicht machen.
Grüße,
Gunnar
Gunnar Ritter
> case "$fmt" in
> *%[efg]*%[efg]*)
> echo "$progname: invalid format string" >&2
> usage
> ;;
> *%[efg]*)
> ;;
> *)
> echo "$progname: invalid format string" >&2
> usage
> esac
Diesen Abschnitt streiche man mal doch besser.
Grüße,
Gunnar
jsaul
> jsaul <news...@jsaul.de> wrote:
>
> > Gunnar Ritter <g...@bigfoot.de> wrote:
> >> daß ich der Lauffähigkeit Deines laienhaften Codes (unnötig unportabel,
> >
> > Ist denn z.B. der Code von Jürgen Salk auch "laienhaft"?
>
> Im konkreten Fall <8mnrm9...@salk.fqdn.th-h.de> ja. Der einzige
> Vorteil gegenüber dem Deinigen liegt darin, daß »i=$((i+1))« immer
> noch besser als »$((i++))« ist.
>
> > Ach ja, und zu der Meisterleistung unter
> > <m366b1j...@emma1.emma.line.org> schweigst du dich ja ganz aus.
>
> Klar, ich muß meine Kritik nicht bei jedem neuen Posting wiederholen,
> genausowenig wie ich bei jeder Erwähnung von »$(...)« trotz meiner
> allseits bekannten Abneigung gegen dieses Konstrukt öffentlich auf
> die Palme springen und mit Kokosnüssen werfen muß. Das wäre affig.
Und warum tust du es dann doch? Bei »$((i++))« z.B.? Dass du das nicht so
schön findest wie »i=$((i+1))« ist dein gutes Recht. Aber auf die "Palme
springen und mit Kokosnüssen werfen", das hast *du* getan. Wie so oft. Affig,
in der Tat, aber damit stellst du nur dich selbst bloß, und nicht wie
beabsichtigt andere.
Im übrigen ist obiges »$((i++))«, wie bereits erwähnt, (mindestens) in ksh93,
pdksh, zsh und bash implementiert. Damit wäre das betreffende Konstrukt auf
den meisten "modernen" Shells verfügbar, auch wenn es von SUSv2 nicht
ausdrücklich gefordert wird und damit vielleicht nicht das Prädikat
"portabel" verdient. Habe ich auch nie behauptet. Nimm du aber nur ruhig
weiter AWK, denn es ist ja *deine* überflüssige Zeit, die du damit
vertrödelst.
Matthias Andree
> Aber es fängt doch bei der /bin/sh unter SunOS 5.7 schon an, bzw hört auf.
> Die schluckt obiges Konstrukt jedenfalls nicht, ohne es wieder auszuspucken.
> Ob diese Shell so "richtig alt" ist, vermag ich nicht zu sagen. SunOS 5.7
> jedenfalls ist nicht allzu alt. Ja, ich weiß, eine ksh gibt's dort auch,
> darum ging es hier aber nicht.
Nein, es war die gewünschte Shell bzw. Umgebung überhaupt nicht
vorgegeben.
--
Matthias Andree
Outlook (Express) users: press Ctrl+F3 for the full source code of this post.
begin dont_click_this_virus.exe
end
Matthias Andree
> Matthias Andree <matthia...@gmx.de> wrote:
>
> > Dürfte mit jeder gewaschenen Bourne-Shell funktionieren, ash, bash, ksh,
> ^^^^^^^^^^^
> > zsh fressen das Zeug jedenfalls.
>
> Falsch. ash, bash, ksh, zsh & Co. "fressen" es zwar, damit ist es aber
> nicht Bourne-kompatibel:
>
> i=$(expr $i + 1)
>
> Das willst du uns doch wohl nicht etwa als Bourne verkaufen, oder?
>
> i=$((i+1))
>
> Das etwa auch?
"gewaschen Bourne" ja. Original-Bourne will i=`expr $i + 1`
> Was ist eigentlich eine "gewaschene" Bourne-Shell?
Eine, die XSI Command Language frißt, eine Erweiterung auf Bournes
Grundsteinen.
jsaul
> jsaul <news...@jsaul.de> writes:
>
> > Aber es fängt doch bei der /bin/sh unter SunOS 5.7 schon an, bzw hört auf.
> > Die schluckt obiges Konstrukt jedenfalls nicht, ohne es wieder auszuspucken.
> > Ob diese Shell so "richtig alt" ist, vermag ich nicht zu sagen. SunOS 5.7
> > jedenfalls ist nicht allzu alt. Ja, ich weiß, eine ksh gibt's dort auch,
> > darum ging es hier aber nicht.
>
> Nein, es war die gewünschte Shell bzw. Umgebung überhaupt nicht
> vorgegeben.
Es ging um die Portabilität eines von dir vorgeschlagenen Konstrukts unter der
Bourne-Shell. Genauer gesagt, hast du den Begriff einer "gewaschenen"
Bourne-Shell verwendet, ohne klar zu sagen, was du damit meinst. Ist dies ein
Standard-Ausdruck, den ich verpasst habe? Wohl eher nicht. Also Bourne-Shell, und
unter der läuft dein Konstrukt halt /nicht/. Es gibt (weitestgehend)
Bourne-kompatible Shells wie bash, *ksh*, zsh, d.h. Bourne-Skripte laufen dort.
Das heißt aber nicht, dass Skripte, die die erweiterte Syntax der erwähnten
Shells verwenden, Bourne-kompatibel sind. Du meintest sicher POSIX, aber dann
solltest du nicht Bourne sagen, auch nicht in Verbindung mit dem Adjektiv
"gewaschen". Was eine Bourne-Shell ist, steht (wie du ja weißt) unter
http://steve-parker.org/sh/bourne.html
(aus deinem Posting <m3g0a4w...@emma1.emma.line.org> geklaut, danke dafür).
Meine ergänzende Bemerkung zu Jürgen Ilse's Posting, der von einer "richtig
alten" Bourne-Shell (s.o.) sprach, unter der dein Konstrukt eventuell nicht
funtionieren würde, war dann, dass z.B. die /bin/sh unter SunOS 5.7 zu dieser
Klasse Shells gehört. Ist aber immerhin die System-Shell. Die Shells unter Linux
(z.B.) sind ja größtenteils "POSIX-nah", und schlucken somit dein Konstrukt.
Gunnar Ritter
> Gunnar Ritter wrote:
>> Klar, ich muß meine Kritik nicht bei jedem neuen Posting wiederholen,
>> genausowenig wie ich bei jeder Erwähnung von »$(...)« trotz meiner
>> allseits bekannten Abneigung gegen dieses Konstrukt öffentlich auf
>> die Palme springen und mit Kokosnüssen werfen muß. Das wäre affig.
>
> Und warum tust du es dann doch? Bei »$((i++))« z.B.?
Wenn Du intellektuell in der Lage wärst, dem Kontext zu folgen, so
hättest Du erkannt, daß das a) ein anderes Konstrukt ist und daß ich
b) auch auf den Inhalt der Klammern hingewiesen habe, nicht auf die
Arithmetik selbst.
Aber jetzt zum eigentlichen Grund meines Protestes: Du bist ein
waschechter Troll und störst diese Gruppe massiv. Klar, wie jedes nicht
vollkommen auf den Kopf gefallenes Exemplar dieser Spezies gibst Du
öfter mal Antworten auf triviale Fragen der RTFM-Klasse und hoffst,
Dich damit als hilfreich und kompetent darstellen zu können. Und
natürlich beteuerst Du auch ständig, daß Du überhaupt nicht an Streit
interessiert wärst. Aber das ist nicht wahr. Allein mit Deiner
kindischen Weigerung, der Netiquette durch Angabe eines Realnamens
Genüge zu tun, stiftest Du Unfrieden. Und dadurch, daß Du ständig im
Namen der Portabilität auf irgendwelchen Nichtigkeiten herumhackst,
noch viel mehr. Nun, wenn Du ein wirklich kompetenter Poster wärst,
könnte man darüber hinwegsehen. Aber das bist Du nicht mal im Ansatz,
wie Du mit Deinen dümmlichen Fragen zur ksh so überaus entlarvend
gezeigt hast. Nicht einmal von Portabilität, Deinem angeblichen
Lieblingsthema, verstehst Du wirklich etwas; Dir passieren so üble
Ausrutscher, daß Du Dich auch in diesem Punkt deutlich als simpler
Störenfried herausstellst. Tatsächlich hast Du hier niemals auch nur
eine Zeile Code präsentiert, die mehr als Mittelmaß gewesen wäre.
Nein, Provokation ist ganz offensichtlich das einzige Interesse, das
Du in dieser Gruppe verfolgst. Und da das jetzt alle wissen, kannst
Du gehen.
Wir anderen sollten vereinbaren, diesen Troll nicht mehr zu füttern,
damit ist letztlich keinem gedient.
Grüße,
Gunnar
Gunnar Ritter
> Gunnar Ritter wrote:
>> Klar, ich muß meine Kritik nicht bei jedem neuen Posting wiederholen,
>> genausowenig wie ich bei jeder Erwähnung von »$(...)« trotz meiner
>> allseits bekannten Abneigung gegen dieses Konstrukt öffentlich auf
>> die Palme springen und mit Kokosnüssen werfen muß. Das wäre affig.
>
> Und warum tust du es dann doch? Bei »$((i++))« z.B.?
Wenn Du intellektuell in der Lage wärst, dem Kontext zu folgen, so
hättest Du erkannt, daß das a) ein anderes Konstrukt ist und daß ich
b) auch auf den Inhalt der Klammern hingewiesen habe, nicht auf die
Arithmetik selbst.
Aber jetzt zum eigentlichen Grund meines Protestes: Du bist ein
waschechter Troll und störst diese Gruppe massiv. Klar, wie jedes nicht
vollkommen auf den Kopf gefallene Exemplar dieser Spezies gibst Du
jsaul
Was bist du bloß für ein verfluchter Vollidiot. Ein Spinner, der meint,
nur weil Shell-Skripting das einzige ist, was er in seinem jungen Leben
gelernt hat, diese Newsgroup in einer Weise beherrschen zu wollen, dass
jegliche sinnvolle Konversation im Keim erstickt wird. Ein
selbsternannter Gruppenzensor, dem in seinem Verfolgungswahn der Arsch
auf Grundeis geht, sobald hier von wem auch immer was gepostet wird,
was ihn aus seinem labilen Gleichgewicht bringt.
Gunnar Ritter, nur du weißt, was dich dazu bringt, derartig
widerwärtige Hasstiraden loszutreten, sobald hier jemand zum Thema (na,
erinnerst du dich) "100 dateien auf einmal erzeugen" z.B. folgenden,
völlig korrekten Lösungsvorschlag postet:
i=0
until [ $((i++)) = 100 ]
do
touch datei.$i
done
Was du daraufhin hier in dieser NG von dir gegeben hast, nur weil *dir*
ein von den meisten modernen Shells verbreiteter Ausdruck, nämlich
»$((i++))«, nicht schön genug ist, und »touch« vielleicht zu langsam,
das ist unter aller Würde. Was ist es, was dich an einem solchen
Vorschlag derart verletzt, dass du hier mit solch einem unglaublichen
Gezetere über *Menschen* herfällst, die hier nichts weiter machen, als
über ein Thema zu diskutieren? Ich gehöre normalerweise zu denjenigen,
die sich aus solchen vulgären Flames nicht viel machen, wie du sie hier
bei jeder sich bietenden Gelegenheit abziehst gegen Leute, die dir
nicht nach dem Munde reden. Aber heute hast du die Grenze eindeutig
überschritten.
Gunnar Ritter, wenn du meinst, hier mit deinen Diffamierungen in
irgendeiner Hackordnung aufsteigen zu können, bist du genau 60 Jahre zu
spät gekommen. *Damals* hättest du mit Sicherheit eine steile Karriere
gemacht, *hier* bist du mit deinem Geschrei so überflüssig wie ein
Kropf. Du solltest mal versuchen, durch geeignete Gegenmaßnahmen deine
Umgebung inklusive NG's vor dir zu schützen. Es gibt sicher in deiner
Heimatstadt Beratungsstellen, die dir die Telefonnummer einer
Selbsthilfegruppe nennen können. Du kannst auch mal mit Google
recherchieren, damit kennst du dich ja schon aus.
So, Gunnar Ritter, du solltest dich entschuldigen oder spätestens jetzt
zum *Teufel* scheren. Da dein narzistisches Ego dir aber weder das eine
noch das andere erlauben wird, wird dein Name in weniger als einer
Minute die erste Zeile meines Killfiles zieren. Verlass dich drauf.
Ende der Diskussion.
=====================================================
NB: Ich hoffe, ihr anderen NG-Teilnehmer habt Verständnis dafür, dass
dies _einmal_ so gesagt werden musste. Aber solche persönlichen
Beleidingungen von Gunnar Ritter muss sich *niemand* bieten lassen.
Helmut Schellong
>
> jsaul <ne...@jsaul.de> wrote:
> [...]
> Du in dieser Gruppe verfolgst. Und da das jetzt alle wissen, kannst
> Du gehen.
>
> Wir anderen sollten vereinbaren, diesen Troll nicht mehr zu füttern,
> damit ist letztlich keinem gedient.
Genau richtig.
Ihr selbsternannten Moderatoren in einer unmoderierten NG solltet
uns nach Lust und Laune posten und -in meinem Fall: auch werben :)-
lassen. Das reduzierte den 'Stoff' gewaltig, und wir wären
vielleicht zufriedener als jetzt.
jsaul
Was bist du bloß für ein verfluchter Vollidiot. Ein Spinner, der meint,
nur weil Shell-Skripting das einzige ist, was er in seinem jungen Leben
gelernt hat, diese Newsgroup in einer Weise beherrschen zu wollen, dass
jegliche sinnvolle Konversation im Keim erstickt wird. Ein
selbsternannter Gruppenzensor, dem in seinem Verfolgungswahn der Arsch
auf Grundeis geht, sobald hier von wem auch immer was gepostet wird,
was ihn aus seinem labilen Gleichgewicht bringt.
Gunnar Ritter, nur du weißt, was dich dazu bringt, derartig
widerwärtige Hasstiraden loszutreten, sobald hier jemand zum Thema (na,
erinnerst du dich) "100 dateien auf einmal erzeugen" z.B. folgenden,
völlig korrekten Lösungsvorschlag postet:
i=0
until [ $((i++)) = 100 ]
do
touch datei.$i
done
Was du daraufhin hier in dieser NG von dir gegeben hast, nur weil *dir*
ein von den meisten modernen Shells unterstützter Ausdruck, nämlich
Gruß, jsaul
--
http://www.jsaul.de
Gunnar Ritter
> Gunnar Ritter wrote:
>> jsaul <ne...@jsaul.de> wrote:
>> [...]
>> Du in dieser Gruppe verfolgst. Und da das jetzt alle wissen, kannst
>> Du gehen.
>>
>> Wir anderen sollten vereinbaren, diesen Troll nicht mehr zu füttern,
>> damit ist letztlich keinem gedient.
>
> Genau richtig.
> Ihr selbsternannten Moderatoren in einer unmoderierten NG solltet
> uns nach Lust und Laune posten und -in meinem Fall: auch werben :)-
> lassen. Das reduzierte den 'Stoff' gewaltig,
Nein. Deine Spezialerkrankung behandelt man besser anders.
> und wir wären vielleicht zufriedener als jetzt.
Es gibt da ein Örtchen, an dem Du noch viel glücklicher werden kannst.
Grüße,
Gunnar
jsaul
Was bist du bloß für ein alberner Kasper. Ein Störenfried, der meint,
Gunnar Ritter, in diesem Forum bist du mit deinem Geschrei so
überflüssig wie ein Kropf. Du solltest mal versuchen, durch geeignete
Gegenmaßnahmen deine Umgebung inklusive NG's vor dir zu schützen. Es
gibt sicher in deiner Heimatstadt Beratungsstellen, die dir die
Telefonnummer einer Selbsthilfegruppe nennen können. Du kannst auch mal
mit Google recherchieren, damit kennst du dich ja schon aus.
So, Gunnar Ritter, du solltest dich entschuldigen oder spätestens jetzt
zum Teufel scheren. Da dein narzistisches Ego dir aber weder das eine
noch das andere erlauben wird, wird dein Name in weniger als einer
Minute die erste Zeile meines Killfiles zieren. Verlass dich drauf.
Ende der Diskussion.
=====================================================
NB: Ich hoffe, ihr anderen NG-Teilnehmer habt Verständnis dafür, dass
dies _einmal_ so gesagt werden musste. Aber solche persönlichen
Beleidigungen von Gunnar Ritter muss sich *niemand* bieten lassen.
Matthias Andree
> Genauer gesagt, hast du den Begriff einer "gewaschenen" Bourne-Shell
> verwendet, ohne klar zu sagen, was du damit meinst. Ist dies ein
> Standard-Ausdruck, den ich verpasst habe? Wohl eher nicht.
> Also Bourne-Shell,
Irrige Annahme.
> Bourne-kompatibel sind. Du meintest sicher POSIX, aber dann solltest
POSIX meine ich sicher nicht, weil ich kein bißchen POSIX-Dokumentation
im Original herumliegen habe, auf SUS v2 laß' ich mich gerne ein.
> Meine ergänzende Bemerkung zu Jürgen Ilse's Posting, der von einer
> "richtig alten" Bourne-Shell (s.o.) sprach, unter der dein Konstrukt
> eventuell nicht funtionieren würde, war dann, dass z.B. die /bin/sh
> unter SunOS 5.7 zu dieser Klasse Shells gehört. Ist aber immerhin die
> System-Shell. Die Shells unter Linux (z.B.) sind ja größtenteils
> "POSIX-nah", und schlucken somit dein Konstrukt.
Wohl wahr, aber ich komme bestimmt nicht auf die Idee, unter Solaris in
sh zu hacken, schon gar nicht will ich die als interaktive Shell haben,
auf den Solariskisten, die ich regelmäßig benutze, hab' ich ksh und bash
herumliegen.
Matthias Andree
> Was bist du bloß für ein verfluchter Vollidiot. Ein Spinner, der meint,
> nur weil Shell-Skripting das einzige ist, was er in seinem jungen Leben
> gelernt hat, diese Newsgroup in einer Weise beherrschen zu wollen, dass
> jegliche sinnvolle Konversation im Keim erstickt wird. Ein
Manchmal könnte man annehmen, daß Seismologie zu einer noch nicht
anerkannten Berufskrankheit geführt hat, die unter anderem
Beharrlichkeit im Verstoß gegen allgemein übliche Umgangsformen zur
Folge hat. Ob das explizite Ausdrucksweise oder Nichtkenntnis des
eigenen Namens ist, ist dabei gleichgültig.
Sinnvolle Konversation kann jedenfalls auf sinnloser Werbung für ein
nicht nur nach Gunnars Meinung schlechtes Produkt kaum mehr wachsen.
Immerhin besteht Hoffnung. Hoffnung, daß die Leute, deren Postings Dir
nicht gefallen, im Killfile landen und Du nicht mehr antworten mußt.
Juergen Ilse
Matthias Andree <matthia...@gmx.de> wrote:
> jsaul <ne...@jsaul.de> writes:
>> Meine ergänzende Bemerkung zu Jürgen Ilse's Posting, der von einer
>> "richtig alten" Bourne-Shell (s.o.) sprach, unter der dein Konstrukt
>> eventuell nicht funtionieren würde, war dann, dass z.B. die /bin/sh
>> unter SunOS 5.7 zu dieser Klasse Shells gehört. Ist aber immerhin die
>> System-Shell.
Das ist falsch. Die /bin/sh existiert dort AFAIK nur noch aus Gruenden
der Kompatibilitaet. Die "empfohlene" shell ist bei Solaris 2.x meines
Wissens nach schon immer die ksh gewesen (lediglich bei Solaris 1.x
sprich SunOS 4.1 war das wohl noch anders, aber das war ja im Gegen-
satz zu Solaris 2.x auch kein SYSV sondern ein BSD und die Empfehlungen
fuer die shell gingen z.T. sogar in Richtung csh *schauder* ...).
>> Die Shells unter Linux (z.B.) sind ja größtenteils
>> "POSIX-nah", und schlucken somit dein Konstrukt.
> Wohl wahr, aber ich komme bestimmt nicht auf die Idee, unter Solaris in
> sh zu hacken, schon gar nicht will ich die als interaktive Shell haben,
> auf den Solariskisten, die ich regelmäßig benutze, hab' ich ksh und bash
> herumliegen.
Ich bevorzuga auch da mittlerweile die zsh, aber das ist wohl auch
Geschmacksache ...
jsaul
> Matthias Andree <matthia...@gmx.de> wrote:
>> jsaul <ne...@jsaul.de> writes:
>>> Meine ergänzende Bemerkung zu Jürgen Ilse's Posting, der von einer
>>> "richtig alten" Bourne-Shell (s.o.) sprach, unter der dein Konstrukt
>>> eventuell nicht funtionieren würde, war dann, dass z.B. die /bin/sh
>>> unter SunOS 5.7 zu dieser Klasse Shells gehört. Ist aber immerhin
>>> die System-Shell.
>
> Das ist falsch. Die /bin/sh existiert dort AFAIK nur noch aus Gruenden
> der Kompatibilitaet. Die "empfohlene" shell ist bei Solaris 2.x meines
> Wissens nach schon immer die ksh gewesen [...]
Als standardmäßige Login-Shell für die normalen Benutzer ksh, ja. Aber
die Root-Shell ist /sbin/sh, die meines Wissens eine statisch gelinkte
/bin/sh und somit auch eine Bourne-Shell ist. Ich bin mir deshalb
keineswegs sicher, dass es /bin/sh bzw. /sbin/sh nur noch aus Gründen
der Kompatibilität gibt, sondern würde sie eher als einen zentralen
Bestandteil des Systems betrachten. Immerhin werden z.B. die Skripte
unter /etc/init.d von einer der beiden Varianten abgearbeitet. Der
Begriff "System-Shell" ist daher vielleicht in diesem Zusammenhang
etwas unglücklich. User-Shell ksh, keine Frage.
> Ich bevorzuga auch da mittlerweile die zsh, aber das ist wohl auch
> Geschmacksache ...
Die verwende ich seit kurzem zwar auch als interaktive Shell, aber mir
ist sie etwas *zu* flink mit Spellcheck etc. aber das kann man sicher
irgendwo konfigurieren. Oder die tcsh steckt mir noch zu sehr in den
Fingern...
jsaul
Matthias Andree <matthia...@gmx.de> wrote:
> Manchmal könnte man annehmen, daß Seismologie zu einer noch nicht
> anerkannten Berufskrankheit geführt hat, die unter anderem
> Beharrlichkeit im Verstoß gegen allgemein übliche Umgangsformen zur
> Folge hat. Ob das explizite Ausdrucksweise oder Nichtkenntnis des
> eigenen Namens ist, ist dabei gleichgültig.
Die explizite Ausdrucksweise habe ich in einer persönlichen Email an
Gunnar Ritter bedauert. Es ist in jedem Fall unpassend, jemanden in
einer NG als verfluchten Vollidioten zu bezeichnen. Mir war der Kragen
geplatzt, warum, das ist anhand von früheren Beiträgen in diesem Thread
nachzuvollziehen.
> Sinnvolle Konversation kann jedenfalls auf sinnloser Werbung für ein
> nicht nur nach Gunnars Meinung schlechtes Produkt kaum mehr wachsen.
Die Qualität des Produktes, auf das du dich beziehst, kann und will ich
daher nicht beurteilen. Es gab in diesem Zusammenhang sicher
gerechtfertigte Hinweise auf widersprüchliche Aussagen bzgl. der
Kompatibilität dieses Produktes, die von dieser NG bestimmt registriert
worden sind. Man kann dies in sachlicher Weise, ohne übertriebene
Agressionen auch sicher so (z.B. <m3g0a4w...@emma1.emma.line.org>)
rüberbringen, ohne gleich eine öffentliche Hinrichtung zu veranstalten.
> Immerhin besteht Hoffnung. Hoffnung, daß die Leute, deren Postings Dir
> nicht gefallen, im Killfile landen und Du nicht mehr antworten mußt.
Ich denke, Killfiles sind nicht unbedingt die Lösung. Um sich aus dem
Wege zu gehen vielleicht, aber das ist nicht der Sinn einer Newsgroup.
Aber es kann auch nicht Sinn sein, sich gegenseitig zu beleidigen, und
in diesem Sinne war mein Posting von gestern Abend ein Schuss in den
Ofen. Das gestehe ich auch an dieser Stelle ein, unabhängig vom Wie und
Warum, und _entschuldige_ mich hiermit noch mal _ausdrücklich_ bei
Gunnar Ritter.
An anderer Stelle hatte ich mal vorgeschlagen, dass man sich zu einem
Bier zusammensetzen sollte, um diese unsäglichen und in nichts als
Zwietracht endenen Diskussionen zu entschärfen. Von meiner Seite aus
gilt dies, und wer von den an diesem Thread beteiligten Personen mal
nach Berlin kommen sollte oder gar hier wohnt, kann sich darauf gerne
berufen. Im Ernst. Ich habe damit schon gute Erfahrungen gemacht.
Gruß aus B, jsaul
--
http://www.jsaul.de
Gunnar Ritter
> Aber die Root-Shell ist /sbin/sh, die meines Wissens eine statisch
> gelinkte /bin/sh und somit auch eine Bourne-Shell ist.
Das ist korrekt. Es ist hinzuzufügen, daß /sbin/sh im Gegensatz zu
/usr/bin/sh keine Locales respektiert, deshalb sollte man mit der
Verwendung dieser Shell besonders in Multibyte-Character-Locales
vorsichtig sein (naja, wie mit bash, ash, pdksh, zsh, tcsh auch).
Grüße,
Gunnar
Gunnar Ritter
> Die /bin/sh existiert dort AFAIK nur noch aus Gruenden der
> Kompatibilitaet. Die "empfohlene" shell ist bei Solaris 2.x
> meines Wissens nach schon immer die ksh gewesen [...]
Das halte ich für eine Nullaussage. Fakt ist zunächst, daß systemeigene
Skripte überwiegend /usr/bin/sh oder /sbin/sh und den traditionellen
Toolchest verwenden (zumal der XPG4-Toolchest ja sogar optional ist).
Es gibt in sh(1) die Passage
| Because the shell implements both foreground and background jobs in
| the same process group, they all receive the same signals, which can
| lead to unexpected behavior. It is, therefore, recommended that other
| job contrl shells be used, especially in an interactive environment.
aber das trifft bereits auf »jsh« naheliegenderweise nicht zu.
Grüße,
Gunnar
Christian Weisgerber
> Ich bevorzuga auch da mittlerweile die zsh, aber das ist wohl auch
> Geschmacksache ...
Apropos, verwendet hier jemand zsh 4.0.2 auf sparc? Auf OpenBSD/sparc
ist sie matschig. Ich weiß nicht, was alles kaputt ist, aber schon
die Expansion von * scheitert.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Sven Mascheck
>>> Meine ergänzende Bemerkung zu Jürgen Ilse's Posting, der von einer
>>> "richtig alten" Bourne-Shell (s.o.) sprach, unter der dein Konstrukt
>>> [ $((...)) ] eventuell nicht funtionieren würde, war dann, dass z.B.
>>> die /bin/sh unter SunOS 5.7 zu dieser Klasse Shells gehört.
> Die "empfohlene" shell ist bei Solaris 2.x meines
> Wissens nach schon immer die ksh gewesen
(Erinnerst Du Dich noch, wo es tatsächlich diesbezügliche Hinweise
gegeben hätte?)
Abgesehen davon sollte man die Solaris-/bin/sh nicht mißverständlicherweise
als »"richtig alte" Bourne shell« bezeichnen, denn es ist die sozusagen die
modernere Variante. Also i.Ggs. zu diversen anderen Bourne Shells: siehe
den Thread neulich über die ${1+"$@"}-Konvention, »Bourne vs. Bourne«.
> lediglich bei Solaris 1.x sprich SunOS 4.1 war das wohl noch anders,
> [...]
Das ist recht verharmlost, es gab dort (leider) schlicht gar keine ksh.
Auf einer »Auspex« (aufgebohrtes SunOS 4.1.4 als Fileserver, das noch
bis vor »kurzem« dafür benutzt wurde) habe ich mal eine »ksh88g«
gefunden (und gerettet). Die war aber offenbar nachträglich von einem
Wartungsmensch zu »eigenen Zwecken« installiert worden.
Ansonsten steht Solaris mit einer Bourne Shell als »/bin/sh« mittlerweile
recht alleine da. Nur OSF1/V4,5, AIX3, HP-UX9.x, Irix bis 6.3, Ultrix
und SunOS 4 hatten(/haben) ebenfalls eine. Dann aber bis auf SunOS 4/5,
und Irix durchweg die »ältere« Version. (Ganz abgesehen von noch
exotischeren Dingen wie das Münchner »MUNIX«, PCS/Cadmus).
Gunnar Ritter
> Abgesehen davon sollte man die Solaris-/bin/sh nicht mißverständlicherweise
> als »"richtig alte" Bourne shell« bezeichnen, denn es ist die sozusagen die
> modernere Variante.
Das kommt mir etwas zu einfach vor. Es scheint mir mindestens folgende
Varianten zu geben (bitte ggf. korrigieren, einige kenne ich nur aus
der zugehörigen Dokumentation):
· Uralte BSD-Variante der v7-Shell (Ultrix), ohne Funktionen.
· Reine SVr2-Shell (Ultrix, sh5) mit Funktionen und vielen kleineren
Modernisierungen.
· OSF/1-Variante basierend auf SVr2. Offenbar immer noch ohne modernes $@,
aber z.B. mit Auswertung von LC_COLLATE bei range expressions. Auch auf
AIX und HP-UX.
· SVr3.x-Shell mit modernem $@ und »getopts«. Auf SunOS 4, SCO OpenServer.
· SVr4-Shell mit Job-Control. SunOS 5.
· SVr4.2-Shell mit »read -r«, »mldmode« und »priv« und (Jahre nach
deren erster Festlegung) SVID-Fehlermeldungen »UX:sh: ERROR: ...«.
UnixWare.
Die IRIX-Variante liegt wohl irgendwo zwischen den letzten beiden.
> Ansonsten steht Solaris mit einer Bourne Shell als »/bin/sh« mittlerweile
> recht alleine da. Nur OSF1/V4,5, AIX3, HP-UX9.x, Irix bis 6.3, Ultrix
> und SunOS 4 hatten(/haben) ebenfalls eine.
Naja, auf die SCO-Systeme traf das auch alle zu, und die dürften wohl
durchaus noch präsent sein. Was bei Calderas OpenUnix 8 daraus geworden
ist, weiß ich (noch) nicht.
Grüße,
Gunnar
Felix von Leitner
> Ich denke, Killfiles sind nicht unbedingt die Lösung.
Oh doch.
Ich werde ab jetzt z.B. auf jegliches Herumgeseier von jsaul.de
verzichten.
> An anderer Stelle hatte ich mal vorgeschlagen, dass man sich zu einem
> Bier zusammensetzen sollte, um diese unsäglichen und in nichts als
> Zwietracht endenen Diskussionen zu entschärfen.
Wenn du nicht zu jedem Scheiß noch einmal ein vom Niveau her noch
tieferliegendes Posting absetzen müßtest, wären hier fast gar keine zu
entschärfenden Diskussionen. Denn im Gegensatz zu dir hat Herr
Schellong offenbar rate limiting bei seinen Postings aktiviert.
Juergen P. Meier
[shell varianten]
>· SVr4.2-Shell mit »read -r«, »mldmode« und »priv« und (Jahre nach
> deren erster Festlegung) SVID-Fehlermeldungen »UX:sh: ERROR: ...«.
> UnixWare.
Die /bin/sh von DG/UX (DataGeneral) hatte ebenfalls genau diese SVID ausgaben.
Allerdings hatte sie zusaetzlich zu "read -r" auch noch command-line-history
und -completion, war aber keine ksh (einen strings hatte ich damals gemacht,
weil ich neugierig war, leider existiert das sytem nicht mehr.) und sonderlich
modern war sie auch nicht. Jedoch bin ich dort das erste mal bewusst ueber
»#! /bin/sh« scripte gestolpert (in den runlevels, damals ist mir das zum
ersten mal aufgefallen).
>Die IRIX-Variante liegt wohl irgendwo zwischen den letzten beiden.
Weis jemand, wie das bei Sinix aussieht?
Juergen
--
J...@lrz.fh-muenchen.de - "This World is about to be Destroyed!"
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
> [shell varianten]
>>· SVr4.2-Shell mit »read -r«, »mldmode« und »priv« und (Jahre nach
>> deren erster Festlegung) SVID-Fehlermeldungen »UX:sh: ERROR: ...«.
>> UnixWare.
>
> Die /bin/sh von DG/UX (DataGeneral) hatte ebenfalls genau diese SVID
> ausgaben.
Die anderen Tools auch? Auf welchem AT&T-Release basierte das System
denn?
>>Die IRIX-Variante liegt wohl irgendwo zwischen den letzten beiden.
>
> Weis jemand, wie das bei Sinix aussieht?
Nach <http://manuals.fujitsu-siemens.com/unixservers.html> scheint es
eine SVr4.0-Shell zu haben.
Grüße,
Gunnar
Gunnar Ritter
> Sven Mascheck <sven.m...@student.uni-ulm.de> wrote:
>> Ansonsten steht Solaris mit einer Bourne Shell als »/bin/sh« mittlerweile
>> recht alleine da. Nur OSF1/V4,5, AIX3, HP-UX9.x, Irix bis 6.3, Ultrix
>> und SunOS 4 hatten(/haben) ebenfalls eine.
>
> Naja, auf die SCO-Systeme traf das auch alle zu, und die dürften wohl
> durchaus noch präsent sein. Was bei Calderas OpenUnix 8 daraus geworden
> ist, weiß ich (noch) nicht.
In der nativen Umgebung ist es nach wie vor eine SVr4.2-Bourne-Shell,
in der optionalen Linux-Umgebung eine bash.
Grüße,
Gunnar
Juergen P. Meier
>Juergen P. Meier <J...@lrz.fh-muenchen.de> wrote:
>> Die /bin/sh von DG/UX (DataGeneral) hatte ebenfalls genau diese SVID
>> ausgaben.
>
>Die anderen Tools auch? Auf welchem AT&T-Release basierte das System
>denn?
Das kann ich (mangels vorhandener Maschine) leider nicht mehr herausfinden :(
>>>Die IRIX-Variante liegt wohl irgendwo zwischen den letzten beiden.
>>
>> Weis jemand, wie das bei Sinix aussieht?
>
>Nach <http://manuals.fujitsu-siemens.com/unixservers.html> scheint es
>eine SVr4.0-Shell zu haben.
Ah. (gut das es da manuals gibt ;).
DataGeneral wurde ja wohl ziemlich auseinander gerissen, die Clariion
Storage systeme wurden von EMC gekauft, die DG/UX Systeme und die OS
Software ist wohl gestorben.
Sven Mascheck
>> [ Solaris-/bin/sh [...] sozusagen die modernere Variante ]
> Das kommt mir etwas zu einfach vor.
> [Sehr interessante, ausführliche Differenzierung]
(Oh ja, ich hatte nur grob zw. SVR2 und 3 getrennt. Und (v.a.) »SCO« habe
ich - auch mangels PC - noch nie gesehen und leider komplett unterschlagen,
»war: Bourne Shell als /bin/sh«).
> [...]
> · OSF/1-Variante basierend auf SVr2. Offenbar immer noch ohne modernes $@,
> aber z.B. mit Auswertung von LC_COLLATE bei range expressions. Auch auf
> AIX und HP-UX.
· So auf HP-UX 9/10.
· Auf OSF1 hingegen wird LC_COLLATE nicht beachtet, obwohl es ja in
sh(1b) dokumentiert wird. tr(1) im Vergleich beachtet es, auf V4
und V5. Also doch »nur SVR2.0« - oder buggy (andere Kriterien)?
· Und auf AIX 3 und 4 ist es die nächste Variante:
> · SVr3.x-Shell mit modernem $@ und »getopts«. Auf SunOS 4, SCO OpenServer.
Kennt eigentlich jemand einen Grund, warum SunOS 4 nie eine ksh-86/88 anbot?
(AFAIK: SunOS 4.0: '89, 4.1: '90.) Oder waren abgesehen von den Bourne Shell
Benutzern alle anderen mit csh oder freien Shells zufrieden?
> · SVr4-Shell mit Job-Control. SunOS 5.
>
> · SVr4.2-Shell mit »read -r«, »mldmode« und »priv« und (Jahre nach
> deren erster Festlegung) SVID-Fehlermeldungen »UX:sh: ERROR: ...«.
> UnixWare.
> Die IRIX-Variante liegt wohl irgendwo zwischen den letzten beiden.
Was bietet sie eigentlich mehr als die SVR4.0 Version?
Einziger Punkt, den ich gefunden habe: Offenbar im Zuge der Einführung
der ksh als /bin/sh bei IRIX 6.4, kennt sie (nun bsh) das ksh-artige
${parameter##pattern}, allerdings ausschließlich mit dem "*/" pattern.
(/sbin/builtin_exec besteht aus »${0##*/} "$@"« und es existieren
Softlinks mit Namen der POSIX builtins darauf).
Sonst scheint sie mir aber (auch lt. Manpage) identisch mit
SVR4.0-Varianten wie SunOS 5.
Gerade habe ich noch gesehen, daß Sun für Solaris 8 bei den ganz
traditionellen Utilities ja doch mal etwas verändert hat, das
eigenwillige Verhalten von »sh -c '' '-sh'« ist verschwunden:
SVR(2/)3/4: 1. Argument wird $0, profile wird gelesen und je
nach Version (inkonsistent) gibt es sogar eine interaktive Shell.
Und vermutlich gibt es noch weitere, kosmetische(?) Änderungen.
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
> (Und (v.a.) »SCO« habe ich - auch mangels PC - noch nie gesehen [...]
Glück gehabt.
>> · OSF/1-Variante basierend auf SVr2. Offenbar immer noch ohne modernes $@,
>> aber z.B. mit Auswertung von LC_COLLATE bei range expressions. Auch auf
>> AIX und HP-UX.
>
> · So auf HP-UX 9/10.
>
> · Auf OSF1 hingegen wird LC_COLLATE nicht beachtet, obwohl es ja in
> sh(1b) dokumentiert wird. tr(1) im Vergleich beachtet es, auf V4
> und V5. Also doch »nur SVR2.0« - oder buggy (andere Kriterien)?
Die gemeinsame OSF/1-Version war mehr so eine Vermutung von mir. Wird
denn LC_CTYPE beachtet, bes. funktioniert Globbing mit Multibyte-Chars?
Das überhaupt in das Ding hineinzuhacken ist kompliziert genug um
anzunehmen, daß das nicht jeder Hersteller einzeln für sich gemacht
haben wird.
> Kennt eigentlich jemand einen Grund, warum SunOS 4 nie eine ksh-86/88 anbot?
> (AFAIK: SunOS 4.0: '89, 4.1: '90.)
Meines Wissens hätte die den Hersteller vor SVr4 extra Geld gekostet.
Ich gehe mit Gewißheit davon aus, daß man sie nachkaufen konnte.
>> · SVr4-Shell mit Job-Control. SunOS 5.
>>
>> · SVr4.2-Shell mit »read -r«, »mldmode« und »priv« und (Jahre nach
>> deren erster Festlegung) SVID-Fehlermeldungen »UX:sh: ERROR: ...«.
>> UnixWare.
>
>> Die IRIX-Variante liegt wohl irgendwo zwischen den letzten beiden.
>
> Was bietet sie eigentlich mehr als die SVR4.0 Version?
»echo -n« vielleicht? Okay, ich hatte da was falsches im Hinterkopf,
also wahrscheinlich von SVr4.0 abgeleitet.
> Gerade habe ich noch gesehen, daß Sun für Solaris 8 bei den ganz
> traditionellen Utilities ja doch mal etwas verändert hat, [...]
Kleinere Änderungen müßte es den Sccsids nach ziemlich viele geben;
leider habe ich keine reinen SVr4-Quellen, mit denen man mal einen
systematischen Vergleich aufstellen könnte.
Grüße,
Gunnar
Sven Mascheck
>> Auf OSF1 hingegen wird LC_COLLATE nicht beachtet, obwohl es ja in
>> sh(1b) dokumentiert wird. [...] Also doch »nur SVR2.0« - oder buggy
>> (andere Kriterien)?
> Wird denn LC_CTYPE beachtet, bes. funktioniert Globbing mit
> Multibyte-Chars?
Ebenfalls unklar wegen nicht (installierten/)existierenden Multibyte-Locales.
(Und gibt es überhaupt SV-Varianten, die bei 8-bit globbing Schwierigkeiten
haben?). Es gibt auch einen privaten strace(1) port für OSF/1. Mit dem
habe ich aber auch noch nicht mehr herausgefunden, als das eben zumindest
ein setlocale(3) ausgeführt wird.
Die Bourne Shell auf HP-UX10 hingegen bietet doch tatsächlich Multibyte-
globbing. Wie weit muß das eigentlich in der Shell implementiert werden
bzw. wie weit kann eine aufwendige libc helfen?
>> [IRIX-Variante] Was bietet sie eigentlich mehr als die SVR4.0 Version?
> »echo -n« vielleicht?
Ja. Hm, geht (aber?) übrigens auch auf SunOS 4 und OSF1 (beide nur »-n«),
auf MUNIX(SVR-)3.2 und Irix5/6 sowohl mit »-n« als auch »\c«. (Ich kenne
aber die Historie bzgl. »echo« gar nicht.)
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
>> Sven Mascheck <sven.m...@student.uni-ulm.de> wrote:
> (Und gibt es überhaupt SV-Varianten, die bei 8-bit globbing Schwierigkeiten
> haben?).
Das wurde AFAIK mit SVr3 eingeführt. Die SVr2-Shell war noch nicht
8bit-clean.
> Die Bourne Shell auf HP-UX10 hingegen bietet doch tatsächlich Multibyte-
> globbing. Wie weit muß das eigentlich in der Shell implementiert werden
> bzw. wie weit kann eine aufwendige libc helfen?
Das erste Problem liegt darin, daß die Bourne-Shell sbrk() benutzt,
während der Locale-Code der libc meist malloc() aufruft. Dann muß
man eben alle Stellen in der Shell heraussuchen, an denen es auf
ein einzelnes Zeichen ankommt: Quoting mit Backslashes, Globbing,
getopts und alle Stellen, an denen isprint() o.ä. sinnvoll sind.
Das Problem liegt eher darin, diese Stellen zu isolieren als es
dann hineinzuhacken. Bei komplexeren Shells wird das natürlich
erheblich aufwendiger.
>>> [IRIX-Variante] Was bietet sie eigentlich mehr als die SVR4.0 Version?
>> »echo -n« vielleicht?
>
> Ja. Hm, geht (aber?) übrigens auch auf SunOS 4 und OSF1 (beide nur »-n«),
> auf MUNIX(SVR-)3.2 und Irix5/6 sowohl mit »-n« als auch »\c«.
Und sogar auf Solaris/i86, wenn »SYSV3« im Environment vorkommt. Ob
das SVr4-Code oder eine Sun-Erweiterung ist, weiß ich nicht.
> (Ich kenne aber die Historie bzgl. »echo« gar nicht.)
Research Unix -> 32v -> BSD hatte »-n«, PWB/Unix -> System III -> System
V die Escape-Sequenzen und dann wurde es eben ein Durcheinander.
Grüße,
Gunnar
Gunnar Ritter
> Eckhard Sebastian Maass <Eckhar...@gmx.net> wrote:
>> * Gunnar Ritter <g...@bigfoot.de>:
>>> Richtig, »seq« ist ein Tool, das man ausrotten sollte. Der halbwegs
>>> kompetente Programmierer erledigt dessen Aufgaben portabel und ggf.
>>> auch viel flexibler mit ein paar Zeilen awk.
>>
>> Ich benutze zur Zeit noch sehr häufig seq - wenn'a aber auch mit awk
>> geht. Gibt's da ein paar Beispiele?
>
> Folgendes ist eine quick-and-dirty-Implementation von seq, Korrekturen
> erwünscht:
Der Vollständigkeit halber noch eine endgültigere Fassung:
progname=`basename $0`
usage() {
echo "usage: $progname [-f format | -w] [-s separator] [first [step]] last" >&2
exit 2
}
fmt= sep='\n' wflag=0 shift=1
while getopts f:s:w0123456789 arg
do
case "$arg" in
f) fmt="$OPTARG" ;;
s) sep="$OPTARG" ;;
w) wflag=1 ;;
[0123456789]) shift=2 break ;;
*) usage
esac
done
shift `expr $OPTIND - $shift`
test $wflag -eq 1 && test -n "$fmt" && usage
test -z "$fmt" && fmt=%g
first=1 step=
case $# in
1) ;;
2) first="$1" shift ;;
3) first="$1" step="$2" shift 2 ;;
*) usage
esac
last="$1"
invinc() {
echo "$progname: invalid step" >&2
exit 2
}
if awk </dev/null 'BEGIN {
if ('"$first"' <= '"$last"')
exit 0
else
exit 1
}'
then
cmp=\<
case "$step" in
[+.0123456789]*) ;;
'') step=1 ;;
*) invinc
esac
else
cmp=\>
case "$step" in
-*) ;;
'') step=-1 ;;
*) invinc
esac
fi
awk </dev/null 'BEGIN {
if ('$wflag' == 1)
format = sprintf("%%0%dg%s", length("'"$last"'"), "'"$sep"'")
else
format = "'"$fmt$sep"'"
i = '"$first"'
while (i '$cmp'= '"$last"') {
printf(format, i)
i += '"$step"'
}
}'
Folgende Inkompatibilitäten zu GNU seq verbleiben:
· awk verwendet Gleitkommazahlen mit doppelter Präzision, seq welche mit
einfacher.
· GNU seq akzeptiert (undokumentiert) Hexadezimalzahlen in C-Notation.
· Das Skript unterstützt, wie man unschwer erkennen kann, keine long
options.
Grüße,
Gunnar
Juergen Salk
>>>> Richtig, »seq« ist ein Tool, das man ausrotten sollte. Der halbwegs
>>>> kompetente Programmierer erledigt dessen Aufgaben portabel und ggf.
>>>> auch viel flexibler mit ein paar Zeilen awk.
> Der Vollständigkeit halber noch eine endgültigere Fassung:
[ ... ]
> Folgende Inkompatibilitäten zu GNU seq verbleiben:
> · awk verwendet Gleitkommazahlen mit doppelter Präzision, seq welche mit
> einfacher.
> · GNU seq akzeptiert (undokumentiert) Hexadezimalzahlen in C-Notation.
> · Das Skript unterstützt, wie man unschwer erkennen kann, keine long
> options.
Oh oh. Mir sind in Deinem Werk mindestens noch vier weitere
"Inkompatibilitäten" aufgefallen:
· GNU seq akzeptiert keine unsinnigen Formatanweisungen.
· GNU seq funktioniert auch, wenn rückwärts gezählt wird (in Bash).
· GNU seq beendet den Output auch bei »-s« mit einem Newline.
· GNU seq's »-w« Option funktioniert auch, wenn length(last)
kleiner ist als length(first).
Kleiner Patch gefällig?
--- awkseq.orig Sun Sep 9 20:11:54 2001
+++ awkseq Sun Sep 9 20:12:04 2001
@@ -7,6 +7,11 @@
exit 2
}
+invfmt() {
+ echo "$progname: invalid format string: \`$fmt'." >&2
+ exit 2
+}
+
fmt= sep='\n' wflag=0 shift=1
while getopts f:s:w0123456789 arg
do
@@ -21,16 +26,16 @@
shift `expr $OPTIND - $shift`
test $wflag -eq 1 && test -n "$fmt" && usage
test -z "$fmt" && fmt=%g
-
+test "$fmt" != "%g" -a "$fmt" != "%f" -a "$fmt" != "%e" && invfmt
+
first=1 step=
case $# in
1) ;;
-2) first="$1" shift ;;
-3) first="$1" step="$2" shift 2 ;;
+2) first="$1"; shift ;;
+3) first="$1"; step="$2"; shift 2 ;;
*) usage
esac
last="$1"
-
invinc() {
echo "$progname: invalid step" >&2
exit 2
@@ -59,14 +64,26 @@
fi
awk </dev/null 'BEGIN {
- if ('$wflag' == 1)
- format = sprintf("%%0%dg%s", length("'"$last"'"), "'"$sep"'")
- else
+ if ('$wflag' == 1){
+ firstlen=length("'"$first"'")
+ lastlen=length("'"$last"'")
+ if ( firstlen > lastlen )
+ maxlen = firstlen
+ else
+ maxlen = lastlen
+ format = sprintf("%%0%dg%s", maxlen, "'"$sep"'")
+ formatlast = sprintf("%%0%dg", maxlen)
+ }
+ else{
format = "'"$fmt$sep"'"
+ formatlast = "'"$fmt"'"
+ }
i = '"$first"'
- while (i '$cmp'= '"$last"') {
+ while (i '$cmp' '"$last"') {
printf(format, i)
i += '"$step"'
}
+ printf(formatlast, i)
+ printf("\n")
}'
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
Gunnar Ritter
>> Folgende Inkompatibilitäten zu GNU seq verbleiben: [...]
>
> Oh oh. Mir sind in Deinem Werk mindestens noch vier weitere
> "Inkompatibilitäten" aufgefallen:
Danke.
> · GNU seq akzeptiert keine unsinnigen Formatanweisungen.
Im Gegenzug akzeptiert Dein Check
> +test "$fmt" != "%g" -a "$fmt" != "%f" -a "$fmt" != "%e" && invfmt
keine sinnigen Formatanweisungen wie "%06g". Genau deshalb hatte ich
entsprechenden Code in <3B9365A0....@bigfoot.de> gestrichen.
Der Aufwand für eine korrekte Überprüfung von printf-Strings lohnt
sich IMHO nicht, awk macht das am besten selbst.
> · GNU seq funktioniert auch, wenn rückwärts gezählt wird (in Bash).
> [...]
> -2) first="$1" shift ;;
> -3) first="$1" step="$2" shift 2 ;;
> +2) first="$1"; shift ;;
> +3) first="$1"; step="$2"; shift 2 ;;
Eigentlich überflüssig, da shift ein special builtin ist. Bug in bash
(auch bei »break«):
foo=bug; foo=correct shift 0; echo $foo
Vgl. ISO/IEC 9945-2:1993(E), 3.14, p. 152-153 und 3.14.12, p. 159-160.
> · GNU seq beendet den Output auch bei »-s« mit einem Newline.
>
> · GNU seq's »-w« Option funktioniert auch, wenn length(last)
> kleiner ist als length(first).
ACK. Damit wäre ich dann bei
progname=`basename $0`
usage() {
echo "usage: $progname [-f format | -w] [-s separator] [first [step]] last" >&2
exit 2
}
fmt= sep='\n' wflag=0 shift=1
while getopts f:s:w0123456789 arg
do
case "$arg" in
f) fmt="$OPTARG" ;;
s) sep="$OPTARG" ;;
w) wflag=1 ;;
[0123456789]) shift=2; break ;;
*) usage
esac
done
test $OPTIND -gt $shift && shift `expr $OPTIND - $shift`
test "x$1" = x-w && shift
test $wflag -eq 1 && test -n "$fmt" && usage
test -z "$fmt" && fmt=%g
first=1 step=
case $# in
1) ;;
2) first="$1"; shift ;;
3) first="$1" step="$2"; shift 2 ;;
*) usage
esac
last="$1"
invinc() {
echo "$progname: invalid step" >&2
exit 2
}
if awk </dev/null 'BEGIN {
if ('"$first"' <= '"$last"')
exit 0
else
exit 1
}'
then
cmp=\<
case "$step" in
[+.0123456789]*) ;;
'') step=1 ;;
*) invinc
esac
else
cmp=\>
case "$step" in
-*) ;;
'') step=-1 ;;
*) invinc
esac
fi
awk </dev/null 'BEGIN {
if ('$wflag' == 1) {
flen = length("'"$first"'")
llen = length("'"$last"'")
if (flen > llen)
len = flen
else
len = llen
format = sprintf("%%0%dg%s", len, "'"$sep"'")
fmtlst = sprintf("%%0%dg\n", len)
} else {
format = "'"$fmt$sep"'"
fmtlst = "'"$fmt"'\n"
}
i = '"$first"'
while (i '$cmp' '"$last"') {
printf(format, i)
i += '"$step"'
}
printf(fmtlst, i)
}'
Grüße,
Gunnar
Gunnar Ritter
>> Folgende Inkompatibilitäten zu GNU seq verbleiben: [...]
>
> Oh oh. Mir sind in Deinem Werk mindestens noch vier weitere
> "Inkompatibilitäten" aufgefallen:
Danke.
> · GNU seq akzeptiert keine unsinnigen Formatanweisungen.
Im Gegenzug akzeptiert Dein Check
> +test "$fmt" != "%g" -a "$fmt" != "%f" -a "$fmt" != "%e" && invfmt
keine sinnigen Formatanweisungen wie "%06g". Genau deshalb hatte ich
entsprechenden Code in <3B9365A0....@bigfoot.de> gestrichen.
Der Aufwand für eine korrekte Überprüfung von printf-Strings lohnt
sich IMHO nicht, awk macht das am besten selbst.
> · GNU seq funktioniert auch, wenn rückwärts gezählt wird (in Bash).
> [...]
> -2) first="$1" shift ;;
> -3) first="$1" step="$2" shift 2 ;;
> +2) first="$1"; shift ;;
> +3) first="$1"; step="$2"; shift 2 ;;
Eigentlich überflüssig, da shift ein special builtin ist. Bug in bash
(auch bei »break«):
foo=bug; foo=correct shift 0; echo $foo
Vgl. ISO/IEC 9945-2:1993(E), 3.14, p. 152-153 und 3.14.12, p. 159-160.
> · GNU seq beendet den Output auch bei »-s« mit einem Newline.
>
> · GNU seq's »-w« Option funktioniert auch, wenn length(last)
> kleiner ist als length(first).
ACK. Damit wäre ich dann bei
progname=`basename $0`
usage() {
echo "usage: $progname [-f format | -w] [-s separator] [first [step]] last" >&2
exit 2
}
fmt= sep='\n' wflag=0
while getopts f:s:w0123456789 arg
do
case "$arg" in
f) fmt="$OPTARG" ;;
s) sep="$OPTARG" ;;
w) wflag=1 ;;
[0123456789]) break ;;
*) usage
esac
done
test $wflag -eq 1 && test -n "$fmt" && usage
test -z "$fmt" && fmt=%g
while :
do
case "$1" in
-w|-ws?*|-[fs]?*) shift ;;
-[fs]|-ws) shift 2 ;;
-w*[0123456789]*) usage ;;
*) break
esac
done
first=1 step=
case $# in
1) ;;
2) first="$1"; shift ;;
3) first="$1" step="$2"; shift 2 ;;
*) usage
esac
last="$1"
invinc() {
echo "$progname: invalid step" >&2
exit 2
}
if awk </dev/null 'BEGIN {
if ('"$first"' <= '"$last"')
exit 0
else
exit 1
}'
then
cmp=\>
case "$step" in
[+.0123456789]*) ;;
'') step=1 ;;
*) invinc
esac
else
cmp=\<
case "$step" in
-*) ;;
'') step=-1 ;;
*) invinc
esac
fi
awk </dev/null 'BEGIN {
if ('$wflag' == 1) {
flen = length("'"$first"'")
llen = length("'"$last"'")
if (flen > llen)
len = flen
else
len = llen
format = sprintf("%%0%dg", len)
} else
format = "'"$fmt"'"
for (i = '"$first"';;) {
printf(format, i)
i += '"$step"'
if (i '$cmp' '"$last"')
break
printf("%s", "'"$sep"'")
}
printf("\n")
}'
Grüße,
Gunnar
Juergen Salk
>> · GNU seq akzeptiert keine unsinnigen Formatanweisungen.
> Der Aufwand für eine korrekte Überprüfung von printf-Strings lohnt
> sich IMHO nicht, awk macht das am besten selbst.
awk überprüft zunächst mal gar nichts:
$ ./awkseq.orig -f %unsinn 1 2
%uunsinn
%uunsinn
Ist Dir zum Beispiel ...
awk </dev/null 'BEGIN {
if ("'"$fmt"'" !~ /^%[-+#0]*[0-9]*\.?[0-9]*[efg]$/)
exit 0
else
exit 1
}' && invfmt
... wirklich zu viel Aufwand für eine korrekte Fehlerbehandlung?
$ ./awkseq.new -f %unsinn 1 2
awkseq: invalid format string: `%unsinn'.
Beste Grüsse - Jürgen
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
>>> · GNU seq akzeptiert keine unsinnigen Formatanweisungen.
>
>> Der Aufwand für eine korrekte Überprüfung von printf-Strings lohnt
>> sich IMHO nicht, awk macht das am besten selbst.
>
> awk überprüft zunächst mal gar nichts:
Alle mir bekannten awk-Varianten brechen ab, wenn der Formatstring mehr
conversion specifications enthält als Argumente gegeben sind (anstatt
z.B. core zu dumpen, laut POSIX.2 ist das Verhalten unspecified). Das
ist der einzige Fall, dessen Überprüfung mich wirklich interessiert.
> $ ./awkseq.orig -f %unsinn 1 2
> %uunsinn
> %uunsinn
Nicht hübsch, aber unproblematisch.
> Ist Dir zum Beispiel ...
>
> awk </dev/null 'BEGIN {
> if ("'"$fmt"'" !~ /^%[-+#0]*[0-9]*\.?[0-9]*[efg]$/)
> exit 0
> else
> exit 1
> }' && invfmt
>
> ... wirklich zu viel Aufwand für eine korrekte Fehlerbehandlung?
Ja. Es startet einen zusätzlich Prozeß, weist immer noch Formate zurück,
die GNU seq akzeptiert (z.B. »foo%g«), weist zudem Formate zurück, die
nützlich sein könnten, obwohl GNU seq sie nicht akzeptiert (z.B. »%o«).
Selbst ein »y« als Formatstring würde ich nicht unterbinden wollen.
Wenn Du damit Coredumps oder Endlosschleifen verhindern könntest, sähe
das natürlich anders aus, aber derzeit hat Dein Check genau gar keine
nützlichen Vorteile, sondern schränkt das Interface nur unnötig ein.
Grüße,
Gunnar
Juergen Salk
>> $ ./awkseq.orig -f %unsinn 1 2
>> %uunsinn
>> %uunsinn
> Nicht hübsch, aber unproblematisch.
>> Ist Dir zum Beispiel ...
>>
>> [ 6 Zeilen awk ]
>>
>> ... wirklich zu viel Aufwand für eine korrekte Fehlerbehandlung?
> Ja. Es startet einen zusätzlich Prozeß, ...
Kommentar überflüssig.
> weist immer noch Formate zurück, die GNU seq akzeptiert (z.B. »foo%g«),
Trivial. Just for the records: /^.*%[-+#0]*[0-9]*\.?[0-9]*[efg].*$/
> weist zudem Formate zurück, die nützlich sein könnten, obwohl GNU seq
> sie nicht akzeptiert (z.B. »%o«). Selbst ein »y« als Formatstring würde
> ich nicht unterbinden wollen.
Du kannst Deinen seq Clone gerne auch so schreiben, dass er Dir
Balladen singt oder dass Du damit PacMan spielen kann. Nur hat er
dann eben nicht mehr die definierte Funktionalität von seq(1), die
da lautet: "`seq' prints a sequence of numbers to standard output."
^^^^^^^
Gunnar Ritter
>> weist immer noch Formate zurück, die GNU seq akzeptiert (z.B. »foo%g«),
>
> Trivial. Just for the records: /^.*%[-+#0]*[0-9]*\.?[0-9]*[efg].*$/
»foo%g%g« - und das wäre sogar ein prinzipiell gefährliches Format.
Vielleicht hast Du nach der nächsten trivialen Änderung ja endlich
mehr Glück. Oder Du gehst die Sache mal methodisch an und überlegst
gründlicher, was für Formate Du eigentlich akzeptieren willst und
warum gerade diese, bevor Du REs ins Blaue hinein zusammenhackst.
>> weist zudem Formate zurück, die nützlich sein könnten, obwohl GNU seq
>> sie nicht akzeptiert (z.B. »%o«). Selbst ein »y« als Formatstring würde
>> ich nicht unterbinden wollen.
>
> Du kannst Deinen seq Clone gerne auch so schreiben, dass er Dir
> Balladen singt oder dass Du damit PacMan spielen kann. Nur hat er
> dann eben nicht mehr die definierte Funktionalität von seq(1), die
> da lautet: "`seq' prints a sequence of numbers to standard output."
> ^^^^^^^
Da das Skript eine zudem nützliche Obermenge von GNU seq-Formatstrings
akzeptiert, ist das absolut unproblematisch. Es generiert eben nicht nur
Nummern, sondern optional auch die vorgegebene Anzahl unnummerierter
Zeichenketten, und ich sehe keinen Grund, hier weiter zu beschränken.
Der Grund für die rigiden Überprüfungen bei GNU seq liegt wohl einfach
darin, daß dort C-Code der Form »printf(format, (float))« ausgeführt
wird und ungültige Formatstrings daher SEGVs auslösen können. Da ich
dieses Problem in awk nicht habe, muß ich die Sicherheitsvorkehrungen
auch nicht künstlich emulieren.
Grüße,
Gunnar
Juergen Salk
>>> weist immer noch Formate zurück, die GNU seq akzeptiert (z.B. »foo%g«),
>>
>> Trivial. Just for the records: /^.*%[-+#0]*[0-9]*\.?[0-9]*[efg].*$/
> »foo%g%g« - und das wäre sogar ein prinzipiell gefährliches Format.
»foo%g%g« oder ähnliches wird von awk abgefangen, wie Du selbst schon
in <3B9CB1C2...@bigfoot.de> festgestellt hast. Es wird also auf
keinen Fall irgendein Unsinn auf stdout ausgegeben. Wo ist also das Problem?
Ansonsten ersetze eben ».*« durch »[^]*«.
> Vielleicht hast Du nach der nächsten trivialen Änderung ja endlich
> mehr Glück.
Wer hat um Korrekturvorschläge gebeten und sein Skript schon
dreimal korrigieren müssen? Deine Polemik ist hier fehl am Platze.
Beste Grüsse - Jürgen
Juergen Salk
[ Format-Strings matchen mit /^.*%[-+#0]*[0-9]*\.?[0-9]*[efg].*$/ ]
> Ansonsten ersetze eben ».*« durch »[^]*«.
^^^
Kleiner Unfall. Sollte heissen: »([^%]|(%%)+)*«.
Aber wie schon gesagt: Eigentlich unnötig, wegen awk.
Beste Grüsse - Jürgen
Gunnar Ritter
> »foo%g%g« oder ähnliches wird von awk abgefangen, wie Du selbst schon
> in <3B9CB1C2...@bigfoot.de> festgestellt hast. Es wird also auf
> keinen Fall irgendein Unsinn auf stdout ausgegeben.
Es wird auch so kein Unsinn auf stdout ausgegeben. Es wird nur etwas
ausgegeben, das Dir nicht in den Kram paßt, obwohl ihm gültige awk-
Konstrukte zugrundeliegen.
> Wo ist also das Problem?
Wenn Du schon Checks durchführst, dann vielleicht solche, die wenigstens
theoretisch gefährliche Konstrukte abfangen. Es wäre immerhin denkbar,
daß eine mir nicht bekannte awk-Implementation sich dabei nicht so
angenehm verhält.
> Ansonsten ersetze eben ».*« durch »[^]*«.
Durch was bitte?
>> Vielleicht hast Du nach der nächsten trivialen Änderung ja endlich
>> mehr Glück.
>
> Wer hat um Korrekturvorschläge gebeten und sein Skript schon
> dreimal korrigieren müssen? Deine Polemik ist hier fehl am Platze.
Oh, zwischen mehreren Dutzend Zeilen Skript zur Emulation eines nur
unscharf dokumentierten Utilities und einer Zeile RE sehe ich schon
einen sehr entscheidenden Unterschied.
Grüße,
Gunnar
Juergen Salk
>> Wer hat um Korrekturvorschläge gebeten und sein Skript schon
>> dreimal korrigieren müssen? Deine Polemik ist hier fehl am Platze.
> Oh, zwischen mehreren Dutzend Zeilen Skript [...] und einer Zeile RE
> sehe ich schon einen sehr entscheidenden Unterschied.
Ich nicht. Die Anzahl der Zeilen eines Skripts sagt nämlich genau gar
nichts über dessen Komplexität oder die Fähigkeiten des Autors aus.
> ... Emulation eines nur unscharf dokumentierten Utilities ...
Was genau an ...
`seq' prints a sequence of numbers to standard output.
[...]
`-f FORMAT'
Print all numbers using FORMAT; default `%g'. FORMAT must contain
exactly one of the standarding float output formats `%e', `%f', or
`%g'.
... ist so unscharf, dass Du es nicht verstanden hast?
EOD, wegen Zeitverschwendung.
Beste Grüsse - Jürgen
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
>>> Wer hat um Korrekturvorschläge gebeten und sein Skript schon
>>> dreimal korrigieren müssen? Deine Polemik ist hier fehl am Platze.
>
>> Oh, zwischen mehreren Dutzend Zeilen Skript [...] und einer Zeile RE
>> sehe ich schon einen sehr entscheidenden Unterschied.
>
> Ich nicht. Die Anzahl der Zeilen eines Skripts sagt nämlich genau gar
> nichts über dessen Komplexität [...] aus.
a) Quatsch - und b) würde das Dein Rumgehampel mit den REs immer noch
nicht rechtfertigen.
>> ... Emulation eines nur unscharf dokumentierten Utilities ...
>
> Was genau an ...
>
> `seq' prints a sequence of numbers to standard output.
>
> [...]
>
> `-f FORMAT'
> Print all numbers using FORMAT; default `%g'. FORMAT must contain
> exactly one of the standarding float output formats `%e', `%f', or
> `%g'.
>
> ... ist so unscharf, dass Du es nicht verstanden hast?
Was genau an »das Skript hat weitere nützliche Features« hast Du nicht
verstanden? Wenn Dein Bürokratendenken Dir keine abwärtskompatiblen
Erweiterungen gestattet, sondern unnötige Einschänkungen gebietet, tust
Du mir leid.
Grüße,
Gunnar
Juergen Salk
>> Die Anzahl der Zeilen eines Skripts sagt nämlich genau gar
>> nichts über dessen Komplexität [...] aus.
> a) Quatsch
Du hast schon überzeugender argumentiert.
> Was genau an »das Skript hat weitere nützliche Features« hast Du nicht
> verstanden?
Oh, ich habe jedes Wort verstanden. Vielleicht könntest Du dann bei
Gelegenheit auch mal das nützliche Feature einbauen, von »1« bis »2«
zählen zu können:
$ awkseq.orig 1.0 0.1 2.0
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
$
Beste Grüsse - Jürgen
Gunnar Ritter
> Vielleicht könntest Du dann bei Gelegenheit auch mal das nützliche
> Feature einbauen, von »1« bis »2« zählen zu können:
>
> $ awkseq.orig 1.0 0.1 2.0
> 1
> 1.1
> 1.2
> 1.3
> 1.4
> 1.5
> 1.6
> 1.7
> 1.8
> 1.9
> $
Längst erwähntes Problem (float vs. double). Vergleiche »1 .2 2«.
Grüße,
Gunnar
Rolf Buenning
> Oh, ich habe jedes Wort verstanden. Vielleicht könntest Du dann bei
> Gelegenheit auch mal das nützliche Feature einbauen, von »1« bis »2«
> zählen zu können:
>
> $ awkseq.orig 1.0 0.1 2.0
> 1
> 1.1
> 1.2
> 1.3
> 1.4
> 1.5
> 1.6
> 1.7
> 1.8
> 1.9
> $
Hmm,
rolf@Sirius:~ > seq --version
seq (GNU sh-utils) 2.0
Written by Ulrich Drepper.
rolf@Sirius:~ > seq -s " " 1,0 0,1 2,0
1 1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9
rolf@Sirius:~ > seq -s " " 1,0 0,1 2,1
1 1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9 2 2,1
Gruss Rolf
jsaul
> rolf@Sirius:~ > seq --version
> seq (GNU sh-utils) 2.0
> Written by Ulrich Drepper.
>
> rolf@Sirius:~ > seq -s " " 1,0 0,1 2,0
> 1 1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9
> rolf@Sirius:~ > seq -s " " 1,0 0,1 2,1
> 1 1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9 2 2,1
Für ein Gedankenprotokoll schon nicht schlecht, die »,« würdest du im
realen Leben sicher durch ».« ersetzen wollen. Trotzdem zeigt dein
Beispiel eindrucksvoll, was für eine Sch...-Software dieses seq ist.
Aber der erfahrene Programmierer kennt obiges Verhalten natürlich und
wird selbstverständlich¹
seq -s " " 1.0 0.1 2.0001
verwenden. ;-)
¹) bzw. gar nicht
Gruß, jsaul
--
http://www.jsaul.de
Juergen Salk
> Längst erwähntes Problem (float vs. double). Vergleiche »1 .2 2«.
$ awkseq.orig -f%Lg 1 .2 2
Segmentation Fault - core dumped
So gesehen unter Solaris 8 und HP-UX 10.20. Vermutlich auch eines
der nützlichen Features Deines Skripts. Da nehmen wir doch gerne
undefinierte Ausgaben und Coredumps in Kauf, nicht wahr?
Wieso werde ich eigentlich das Gefühl nicht los, dass Du uns hier
Deine Bugs als Features verkaufen willst? Du solltest jetzt
besser aufhören damit.
Beste Grüsse - Jürgen
Gunnar Ritter
> $ awkseq.orig -f%Lg 1 .2 2
> Segmentation Fault - core dumped
>
> So gesehen unter Solaris 8 und HP-UX 10.20. Vermutlich auch eines
> der nützlichen Features Deines Skripts. Da nehmen wir doch gerne
> undefinierte Ausgaben und Coredumps in Kauf, nicht wahr?
Nein, wie ich bereits schrieb. Das rechtfertigt in der Tat den Check,
den Du vorgeschlagen hattest (wobei ich [efg] trotzdem noch etwas
erweitern würde, etwa [cdeEfgGouxX]; nicht alle historischen awk-
Implementationen interpretieren all diese Formate, aber sie verhalten
sich dabei offenbar harmlos). Man sollte weiterhin auch Strings
zulassen, die gar keine Formatanweisungen enthalten. Damit wäre ich
dann bei
^([^%]|(%%)+)*(%[-+#0]*[0-9]*\.?[0-9]*[cdeEfgGouxX])?([^%]|(%%)+)*$
> Wieso werde ich eigentlich das Gefühl nicht los, dass Du uns hier
> Deine Bugs als Features verkaufen willst?
Weil Du Dich an irgendwelchem Hickhack aufgegeilt hast, denke ich. Ich
hatte schon in <3B9CB1C2...@bigfoot.de> ausdrücklich darauf
hingewiesen, daß Coredumps einen Check rechtfertigen. Nun, da Du diesen
Fall belegt hast, befürworte ich den Check dementsprechend. Lies den
Thread bitte noch mal und überdenke Deine persönlichen Unterstellungen.
Grüße,
Gunnar
Gunnar Ritter
> Rolf Buenning <rbue...@t-online.de> wrote:
>> rolf@Sirius:~ > seq --version
>> seq (GNU sh-utils) 2.0
>> Written by Ulrich Drepper.
>>
>> rolf@Sirius:~ > seq -s " " 1,0 0,1 2,0
>> 1 1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9
>> rolf@Sirius:~ > seq -s " " 1,0 0,1 2,1
>> 1 1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9 2 2,1
>
> Für ein Gedankenprotokoll schon nicht schlecht, die »,« würdest du im
> realen Leben sicher durch ».« ersetzen wollen.
man printf(3C) locale(5) LC_NUMERIC=de_DE
Grüße,
Gunnar