Wie wird Compiliert? Die Fortsetzung
Thomas Mundt
Leider funktioniert es noch immer nicht.
Was mache ich falsch ?
Hier der genaue Ablauf des 100. Versuchs den Einstieg in die C-Sprache
zu bekommen:
Als Erstes habe ich mit Hilfe eines Texteditors einen C-Quelltext
erstellt
und unter dem Namen test.c gespeichert.
Inhalt von test.c:
#include <stdio.h>
main( )
{
printf{"\nDies ist ein erstes C-Programm.\n\n"};
printf{"Wie Sie sehen, kann der Befehl 'printf' "};
printf{"nicht nur Texte drucken,\n"};
printf{"sondern auch rechnen.\n\n"};
printf{"13 * 7 = %i \n",13 * 7};
}
Mein nächstes Ziel war es nun ein ablauffertiges Programm zu bekommen.
Ich wollte also mit Hilfe des GNU-C (gcc) compilieren und Linken.
Test.c befand sich im Verzeichnis /home/thomas/test.c
Ich tippte den folgenden Befehl unter Linux ein:
gcc /home/thomas/test.c -p /home/thomas/test.exe
Im Verzeichnis /home/thomas existierte nun eine neue Datei mit dem Namen
test,
die ich nun ausführen wollte.
Ich tippte also test ein, leider ohne Ergebnis.
Was mache ich falsch ?
(Übrigens ein wunderbares Thema für eine Homepage)
Gruß
Thomas
.
Steffen Dingel
Thomas Mundt <thomas...@luebeck.netsurf.de> writes:
>Erstmal Danke für die prompte Beantwortung meiner Frage.
>
>Leider funktioniert es noch immer nicht.
>Was mache ich falsch ?
>
Bis hierher ist alles richtig.
>gcc /home/thomas/test.c -p /home/thomas/test.exe
Erstmal wuerde ich hier -o statt -p nehmen, ich weiss aber nicht
genau was -p macht, vielleicht geht das auch.
Dann kannst Du die Pfade auch weglassen, wenn Du sowieso in /home/thomas
bist (schaden aber nicht).
>Im Verzeichnis /home/thomas existierte nun eine neue Datei mit dem Namen
>test,
>die ich nun ausführen wollte.
>Ich tippte also test ein, leider ohne Ergebnis.
Hier vermute ich, das nicht Deine Programm /home/thomas/test sondern
das Systemprogramm /usr/bin/test (oder sonstwo) ausgefuehrt wurde. Ist
also wahrscheinlich nur ein bloeder Zufall mit dem Namen. Wenn Du
/test oder /home/thomas/test statt nur test eingibst sollte es klappen.
Also insgesamt so (im Verzeichnis /home/thomas):
gcc test.c -o test
/test
Gruss,
Steffen
--
----------------------------------
Steffen Dingel
ste...@omega.ping.de
http://www.ping.de/sites/omega/
Roland Rosenfeld
> Inhalt von test.c:
> #include <stdio.h>
> main( )
> {
> printf{"\nDies ist ein erstes C-Programm.\n\n"};
> printf{"Wie Sie sehen, kann der Befehl 'printf' "};
> printf{"nicht nur Texte drucken,\n"};
> printf{"sondern auch rechnen.\n\n"};
> printf{"13 * 7 = %i \n",13 * 7};
> }
Das ist kein C, da bei C die Parameter der Funktionen in runden und
nicht in geschweiften Klammern stehen. Es ist also erstmal sehr
merkwürdig, wenn Du obiges ohne Fehlermeldung durch den Compiler
bekommen hast.
> Mein nächstes Ziel war es nun ein ablauffertiges Programm zu
> bekommen. Ich wollte also mit Hilfe des GNU-C (gcc) compilieren und
> Linken. Test.c befand sich im Verzeichnis /home/thomas/test.c Ich
> tippte den folgenden Befehl unter Linux ein:
> gcc /home/thomas/test.c -p /home/thomas/test.exe
Was soll das -p da? Laut Manpage von gcc schreibt -p Profiler
Informationen in das Binary. Du meinst also vermutlich eher:
gcc test.c -o test.exe
> Im Verzeichnis /home/thomas existierte nun eine neue Datei mit dem
> Namen test,
Die wurde aber vermutlich nicht von obigem Aufruf erstellt, sondern
war schon vorher da.
> die ich nun ausführen wollte. Ich tippte also test ein, leider ohne
> Ergebnis.
Das liegt daran, daß test ein Shell-internes Kommando ist, welches
ausgeführt wird, wenn Du einfach nur test eintippst. Wenn Du ein
Programm im aktuellen Verzeichnis ausführen willst, solltest Du den
Pfad mit angeben, wobei auch relative Pfade möglich/sinnvoll sind. In
Deinem Fall also
./test
oder
./test.exe
Oder wie auch immer das Binary heißen soll.
> Was mache ich falsch ?
So ziemlich alles. Ist hier eigentlich irgendwo eine Kamera versteckt?
Mir kommt es vor, als könnte man kaum versehentlich in so viele Fallen
reintappen, wie Du uns das hier vormachst...
> (Übrigens ein wunderbares Thema für eine Homepage)
gähn...
Tschoeeee
Roland
--
* Internet: rol...@spinnaker.rhein.de * Fido: 2:2450/42 *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Knut Stolze
> >gcc /home/thomas/test.c -p /home/thomas/test.exe
>
> Erstmal wuerde ich hier -o statt -p nehmen, ich weiss aber nicht
> genau was -p macht, vielleicht geht das auch.
-p gibt irgendwelche Debug-Informationen für groff mit (keine Ahnung, was
das macht.
> Dann kannst Du die Pfade auch weglassen, wenn Du sowieso in /home/thomas
> bist (schaden aber nicht).
>
> >Im Verzeichnis /home/thomas existierte nun eine neue Datei mit dem Namen
> >test,
Die hieß "test.exe". Das ist was völlig anderes.
> >die ich nun ausführen wollte.
> >Ich tippte also test ein, leider ohne Ergebnis.
>
> Hier vermute ich, das nicht Deine Programm /home/thomas/test sondern
> das Systemprogramm /usr/bin/test (oder sonstwo) ausgefuehrt wurde. Ist
> also wahrscheinlich nur ein bloeder Zufall mit dem Namen. Wenn Du
> /test oder /home/thomas/test statt nur test eingibst sollte es klappen.
^^^^^
Die Vermutung dürfte zutreffen, da das im allgemeinen das Problem ist.
Aber zu meiner Markierung: Das funktioniert nicht. Wenn schon, dann im
Verzeichnis /home/thomas folgendes eingeben:
./test.exe
oder irgendwo im System:
/home/thomas/test.exe
> Also insgesamt so (im Verzeichnis /home/thomas):
>
> gcc test.c -o test
> /test
./test
/ ist das root-Verzeichnis (ich meine nicht das Home-Verzeichnis von root).
./ ist das aktuelle Verzeichnis.
Und wie gesagt: Endungen wie ".exe", ".com" ".bat" interessieren ein Unix
nicht. Das sind alles Relikte aus DOS-Zeiten, wi man noch keine anständige
Rechtevergabe hatte. Genau so, wie die Datei heißt, also mit der Endung, muß
sie aufgerufen werden, wenn sie gestartet werden soll.
ciao, Knut
Knut Stolze
> > die ich nun ausführen wollte. Ich tippte also test ein, leider ohne
> > Ergebnis.
>
> ausgeführt wird, wenn Du einfach nur test eintippst. Wenn Du ein
Nein. test ist kein internes Shell-Kommando. Bei mir unter AIX und auch
unter Linux finde ich es in /usr/bin. (Ob das immer so sein muß, weiß ich
nicht genau.)
ciao, Knut
Anselm Lingnau
Knut Stolze <sto...@pax01f.mipool.uni-jena.de>:
> Nein. test ist kein internes Shell-Kommando. Bei mir unter AIX und auch
> unter Linux finde ich es in /usr/bin.
Das eine schließt das andere nicht aus. Einige Shells implementieren
`test' aus Effizienzgründen selbst, andere wollen traditionell, klein
und/oder dumm sein und verlassen sich auf das externe Programm, das aus
diesem Grund auch immer vorhanden ist, selbst wenn es nie jemand
aufruft.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
So, if anybody wants to have hardware sent to them: don't call me, but instead
write your own Unix operating system. It has worked every time for me.
-- Linus Torvalds
Klaus Schilling
> Erstmal Danke für die prompte Beantwortung meiner Frage.
>
> Leider funktioniert es noch immer nicht.
> Was mache ich falsch ?
>
> Hier der genaue Ablauf des 100. Versuchs den Einstieg in die C-Sprache
> zu bekommen:
>
> Als Erstes habe ich mit Hilfe eines Texteditors einen C-Quelltext
> erstellt
> und unter dem Namen test.c gespeichert.
> Inhalt von test.c:
>
> #include <stdio.h>
> main( )
> {
> printf{"\nDies ist ein erstes C-Programm.\n\n"};
> printf{"Wie Sie sehen, kann der Befehl 'printf' "};
> printf{"nicht nur Texte drucken,\n"};
> printf{"sondern auch rechnen.\n\n"};
> printf{"13 * 7 = %i \n",13 * 7};
> }
>
>
> Mein nächstes Ziel war es nun ein ablauffertiges Programm zu bekommen.
> Ich wollte also mit Hilfe des GNU-C (gcc) compilieren und Linken.
> Test.c befand sich im Verzeichnis /home/thomas/test.c
> Ich tippte den folgenden Befehl unter Linux ein:
>
> gcc /home/thomas/test.c -p /home/thomas/test.exe
>
> Im Verzeichnis /home/thomas existierte nun eine neue Datei mit dem Namen
> test,
> die ich nun ausführen wollte.
> Ich tippte also test ein, leider ohne Ergebnis.
>
> Was mache ich falsch ?
Es gibt ein tool 'test' das wahrscheinlich auf den meisten Unix systemen
installiert ist. Ohne Argumente tut der 'test' Befehl gar nichts.
Wenn man einfach 'test' eingibt, wird dieses ausgefuehrt, falls es sich im Pfad
vor befindet und hoehere Prioritaet hat als jedes andere Programm namens
'test'. Dafuer is die Umgebungsvariable PATH zustaendig.
Klaus Schilling
Bernd Gehrmann
> On 26 Oct 1998 23:13:09 GMT, Steffen Dingel wrote:
> > >gcc /home/thomas/test.c -p /home/thomas/test.exe
> >
> > Erstmal wuerde ich hier -o statt -p nehmen, ich weiss aber nicht
> > genau was -p macht, vielleicht geht das auch.
>
> -p gibt irgendwelche Debug-Informationen für groff mit (keine Ahnung, was
> das macht.
Das moechte ich sehen, wie man groff als Debugger verwendet ;-)
Die Option -p erzeugt Profiling-Informationen fuer prof, der aber
seit gprof ziemlich ueberfluessig ist (und den es folgerichtig
wohl auf keinem Linux-System gibt).
Bernd.
Klaus Schilling
> On 26 Oct 1998 23:27:41 GMT, Roland Rosenfeld wrote:
> > > die ich nun ausführen wollte. Ich tippte also test ein, leider ohne
> > > Ergebnis.
> >
> > Das liegt daran, daß test ein Shell-internes Kommando ist, welches
> > ausgeführt wird, wenn Du einfach nur test eintippst. Wenn Du ein
>
> Nein. test ist kein internes Shell-Kommando. Bei mir unter AIX und auch
> unter Linux finde ich es in /usr/bin. (Ob das immer so sein muß, weiß ich
> nicht genau.)
>
> ciao, Knut
test ist Bestandteil der GNU shellutils.
Klaus Schilling
Urs Thuermann
> Leider funktioniert es noch immer nicht.
> Was mache ich falsch ?
Einiges.
> #include <stdio.h>
> main( )
> {
> printf{"\nDies ist ein erstes C-Programm.\n\n"};
> printf{"Wie Sie sehen, kann der Befehl 'printf' "};
> printf{"nicht nur Texte drucken,\n"};
> printf{"sondern auch rechnen.\n\n"};
> printf{"13 * 7 = %i \n",13 * 7};
> }
1. Die Argumente von Funktionen, also in diesem Beispiel printf,
muessen wie in fast allen Programmiersprachen in runden Klammern
stehen. So wie Dein code aussieht, ist es syntaktisch falsch, und
gcc wird parse errors ausgeben.
Ganz abgesehen davon, ist die Behauptung, dass printf rechnen
koenne, nicht richtig, was aber dem compiler natuerlich egal ist.
Die Berechnung von 13 * 7 macht schon der compiler und nicht die
Funktion printf.
> Test.c befand sich im Verzeichnis /home/thomas/test.c
> Ich tippte den folgenden Befehl unter Linux ein:
>
> gcc /home/thomas/test.c -p /home/thomas/test.exe
2. -p steht fuer profiling und erzeugt code, der mit gprof untersucht
werden kann. Du meinst hier sicherlich eher -o
3. gcc versucht bei Deinem Kommando eine Datei test.exe uebersetzen,
die es nicht gibt, und wird daher eine weitere Fehlermledung
erzeugen.
4. Die absoluten Pfade /home/thomas sind ueberfluessig.
5. Ausfuehrbare Programme werden unter UNIX normalerweise nicht .exe
oder .com oder so genannt. Im Gegensatz zu MSDOS & Co koennen sie
unter UNIX beliebige Namen haben und man benutzt normalerweise
keine Endung. Wenn eine Endung wie .exe angibt, muss man das
Programm auch genau so ausfuehren. Man kann also nicht ein
test.exe erzeugen und es dann als test aufrufen.
6. Der Name test ist sehr schlecht gewaehlt. Einige shells,
z.b. auch die bash, die unter Linux gaengig ist, haben ein
Kommando test eingebaut. Ausserdem gibt es /usr/bin/test, das
normalerweise vor Deinem Programm namens test gefunden wird.
Kannst Du feststellen mit echo $PATH und type test bzw. which test
(in bash bzw. tcsh).
Also besser waere hier beispielsweise
cd /home/thomas
gcc test.c -o foo (oder welcher Name Dir gefaellt)
und zum Aufrufen
./foo
Hast Du die Fehlermeldungen in 1. und 3. ignoriert? Die stehen da
eigentlich, damit Du sie liest.
> Im Verzeichnis /home/thomas existierte nun eine neue Datei mit dem
> Namen test, die ich nun ausführen wollte.
Das glaube ich nicht. So wie Du den gcc aufgerufen hast, hat er keine
Datei erzeugt. Dass Du test trotzdem ausfuehren konntest, liegt an 6.
> Ich tippte also test ein, leider ohne Ergebnis.
Siehe man test oder help test in der bash.
> (Übrigens ein wunderbares Thema für eine Homepage)
Nein.
urs
Roland Rosenfeld
>> Das liegt daran, daß test ein Shell-internes Kommando ist, welches
>> ausgeführt wird, wenn Du einfach nur test eintippst.
> Nein.
Du hast recht, diese Aussage ist etwas zu allgemein. Sie gilt aber
zumindest für die bash, die ja inzwischen sehr weit verbreitet ist,
weil sie die Standard-Shell auf Linux-Systemen ist.
> test ist kein internes Shell-Kommando.
Diese Aussage ist unrichtig. Gegenbeispiel bash:
$ type test
test is a shell builtin
Gegenbeispiel pdksh:
$ type test
test is a shell builtin
Für die tcsh stimmt Deine Aussage jedoch:
$ where test
/usr/bin/test
> Bei mir unter AIX und auch unter Linux finde ich es in /usr/bin.
Das widerspricht meiner Aussage, daß test ein shell-internes Kommando
ist, nicht. Du solltest allerdings bedenken, daß shell-interne
Kommandos bei der Ausführung Priorität vor Kommandos im PATH haben.
Wenn Du also bei einer bash oder pdksh "test" ohne Pfad angibst, dann
wird dort nicht /usr/bin/test und auch nicht ./test ausgeführt,
sondern das shell-interne Kommando test.
> (Ob das immer so sein muß, weiß ich nicht genau.)
Es ist wohl üblich, daß /usr/bin/test existiert, aber schon die
Tatsache, daß das nur in /usr/bin und nicht in /bin liegt, zeigt, daß
sh-Skripts das nicht brauchen, denn sonst würde kaum ein System
hochfahren, bei dem /usr eine eigene Partition ist, schließlich ist
"test" (auch unter dem Namen "[" bekannt) eines der existenziellen
Kommandos der sh, das in fast jedem Skript verwendet wird.
Michael Staats
>On 26 Oct 1998 23:27:41 GMT, Roland Rosenfeld wrote:
>> > die ich nun ausführen wollte. Ich tippte also test ein, leider ohne
>> > Ergebnis.
>>
>> Das liegt daran, daß test ein Shell-internes Kommando ist, welches
>> ausgeführt wird, wenn Du einfach nur test eintippst. Wenn Du ein
>Nein. test ist kein internes Shell-Kommando. Bei mir unter AIX und auch
>unter Linux finde ich es in /usr/bin. (Ob das immer so sein muß, weiß ich
>nicht genau.)
Test ist erstmal ein externes Kommando, das muß so sein. Allerdings
haben viele shells, auch die unter AIX, test _zusätzlich_ als internes
Kommando drin, damit's schneller geht und nicht für jeden popeligen
Test ein Prozess erzeugt wird. Allerdings _muß_ sich auch das
interne test wie ein externes Kommando verhalten, d. h. was die
Parameterauswertung angeht, passiert das gleiche wie bei externen
Kommandos. Abgekürzt wird test oft auch mit [. D. h.
test "$A" = blubb
ist das selbe wie
[ "$A" = blubb ]
(Folklore über /bin/[ bitte an geeigneter Stelle weiterverarbeiten).
Will man ein echtes internes Test-Kommando, so kann man in ksh
[[ $A = blubb ]] verwenden. Da kann man z. B. die Anführungszeichen um
$A weglassen. Zu Details: siehe man page ksh.
Was das Kompilieren von Testprogrammen angeht: Nennt sie niemals
"test". Das dürfte eine der Fallen sein, in die Unix Anfänger am
häufigsten reinfallen. Es ist einfach ziemlich lästig und erfordert
ziemlich viel Lernwillen auf Seiten der Zuhörer, wenn man bei diesem
Problem erstmal Suchpfad, das "echte" test, warum man _keinen_ . am
Anfang von seinem $PATH haben will, um das Problem zu umgehen
usw. erklären muß, wo's doch eigentlich um erste Schritte bei der
Programmierung geht.
Nebenbei: Wenn ich anfange, Leuten das Übersetzen von C Programmen
unter Unix zu erklären, lautet die Antwort natürlich, vorausgesetzt
man hat tst.c: "make tst". Das ist einfach, erspart gleich den ganzen
.exe Quatsch, die 4711 Optionen des C-Compilers (für den Anfang
werdens die defaults ja wohl tun) usw. Klar, man muß beim zweiten oder
dritten Übungsprogramm erklären, wie ich die libm mitlinke, aber das
ist auch nicht komplizierter als Compileroptionen. Leider hilft das
nur eine Übungsstunde lang, eine Woche später kommen alle mit ekeligen
Compileraufrufen an :-( Argl.
Tschüß,
Michael
--
Michael Staats, Theoretical Physics, Uni-GH Duisburg
email: mic...@thp.Uni-Duisburg.DE
Bitte keine Artikel ins Usenet und gleichzeitig als email verschicken. Danke.
Please dont post articles to Usenet and as email simultaneously. Thanks.
Oliver Bandel
Steffen Dingel <ste...@omega.ping.de> wrote:
[...]
> Hier vermute ich, das nicht Deine Programm /home/thomas/test sondern
> das Systemprogramm /usr/bin/test (oder sonstwo) ausgefuehrt wurde. Ist
> also wahrscheinlich nur ein bloeder Zufall mit dem Namen. Wenn Du
> /test oder /home/thomas/test statt nur test eingibst sollte es klappen.
Ach ja, genau. Das war es. Der typische Anfänger-Fehler bei Unix-Neulingen.
Programm umbenennen hilft.
Tschüß,
Oliver
Beate Rother
>gcc /home/thomas/test.c -p /home/thomas/test.exe
-o
>Im Verzeichnis /home/thomas existierte nun eine neue Datei mit dem Namen
>test,
... eine neue Datei mit dem Namen "test.exe", ...
>die ich nun ausführen wollte.
>Ich tippte also test ein, leider ohne Ergebnis.
"test" (siehe "man test") ist ein bereits vorhandenes Programm.
Um Erfolg zu haben, haettest Du
cd /home/thomas
./test.exe
eingeben muessen.
uebr: Unter Linux ist jede Datei ausfuehrbar, die Du mit "chmod +x datei"
ausfuehrbar gemacht hast - unabhaengig von der Endung .exe/.com/.bat :-)
-bero.
Helmut Schellong
>
> Test ist erstmal ein externes Kommando, das muß so sein. Allerdings
> haben viele shells, auch die unter AIX, test _zusätzlich_ als internes
> Kommando drin, damit's schneller geht und nicht für jeden popeligen
> Test ein Prozess erzeugt wird. Allerdings _muß_ sich auch das
> interne test wie ein externes Kommando verhalten, d. h. was die
> Parameterauswertung angeht, passiert das gleiche wie bei externen
> Kommandos. Abgekürzt wird test oft auch mit [. D. h.
>
> test "$A" = blubb
>
> ist das selbe wie
>
> [ "$A" = blubb ]
>
> (Folklore über /bin/[ bitte an geeigneter Stelle weiterverarbeiten).
>
> Will man ein echtes internes Test-Kommando, so kann man in ksh
> [[ $A = blubb ]] verwenden. Da kann man z. B. die Anführungszeichen um
> $A weglassen. Zu Details: siehe man page ksh.
>
Einige kleine Detail-Hinweise:
Als Gleichheitsoperator ist '=' obsolet, '==' aktuell.
Man kann durchaus [ $A == blubb ] && ... angeben, wenn
sichergestellt ist, daß 'A' existiert, nicht leer ist und
nicht nur Zwischenraumzeichen enthält.
In diesen Fällen entsteht nämlich [ == blubb ] ,
was für 'test' ein Syntaxfehler ist.
Bei "$A", ""$A, $A'', ..., entsteht nämlich mindestens
[ "" == blubb ] ,
und bei "$A" werden zusätzlich Wildcard-Zeichen [*?
und Zwischenraumzeichen des Inhalts maskiert.
Es gibt eine Shell, bei der man [ A -eq 5 ] angeben kann,
und auch beispielsweise expr "$zeile" :A 're\(g_ex\)pr'.
Das geht nur, weil beide Kommandos intern sind.
Ein externes Kommando kann nicht auf den Variablenmodul
einer aufrufenden Shell zugreifen!
Bei ksh geht auch read var?prompt, ohne Maskierung
des '?', weil durch 'read' als Arg0 eben eine Abschaltung
der Wildcard-Interpretation vorgenommen wird...
> --
> Michael Staats, Theoretical Physics, Uni-GH Duisburg
> email: mic...@thp.Uni-Duisburg.DE
--
Mit freundlichen Grüßen
Helmut Schellong
sche...@t-online.de
http://home.t-online.de/home/schellong
Michael Staats
[ ... ]
>Man kann durchaus [ $A == blubb ] && ... angeben, wenn
>sichergestellt ist, daß 'A' existiert, nicht leer ist und
>nicht nur Zwischenraumzeichen enthält.
>In diesen Fällen entsteht nämlich [ == blubb ] ,
>was für 'test' ein Syntaxfehler ist.
>Bei "$A", ""$A, $A'', ..., entsteht nämlich mindestens
> [ "" == blubb ] ,
>und bei "$A" werden zusätzlich Wildcard-Zeichen [*?
>und Zwischenraumzeichen des Inhalts maskiert.
[ ... ]
Und so weiter ad infinitum. So geht z. B. a=$b _immer_ ohne
Anführungszeichen etc.
Genau deshalb wird folgendes scheinbar zu einem geflügelten Wort:
"Verwende Perl. Shell will man koennen, dann aber nicht verwenden."
Kristian Koehntopp, de.comp.os.unix.misc
Dem ist nichts hizuzufügen.
Tschüß,
Michael (trotzdem noch gelegentlich shell programmierend,
weil's ja wie ne kurze Sache aussieht. Was sich
meistens als Irrtum herausstellt.)
--
Michael Staats, Theoretical Physics, Uni-GH Duisburg
email: mic...@thp.Uni-Duisburg.DE
Helmut Schellong
> ...
> Und so weiter ad infinitum. So geht z. B. a=$b _immer_ ohne
> Anführungszeichen etc.
Ich würde nicht sagen, daß die Regeln, die man sich merken muß,
in allen Shells grenzenlos oder unbestimmt sind.
Wenn man sich die Interpretationsschritte und die Maskierungen
einer Shell (ksh) vor Augen führt, entdeckt man, daß eigentlich
eher das Gegenteil der Fall ist.
So muß man nicht viel mehr wissen als daß die maskierende
Einfassung "......" *nur* die Zeichen $ ` \ als Zeichen mit
Spezialbedeutung übrig läßt,
wobei \ nur dazu da ist, deren Bedeutung auch noch aufzuheben,
und ` ist obsolet und kann durch $(...) ersetzt werden.
Daß ohne Maskierung noch Wildcards *?[
Umlenkungen <> , Subshell () , && , || und Kommandoabschluß ;NL
dazukommen, ist schon nahezu eine erschöpfende Aufzählung.
Die Regel, wo Zwischenraumzeichen entfernt oder auf eines
reduziert werden, ist sehr einfach, durchgängig und fast
überall woanders auch anzutreffen.
Das Verhalten einer Shell ergibt sich eigentlich ganz
automatisch und recht einfach nachvollziehbar, allein
aus dem obigen ersten Absatz heraus.
>
> Genau deshalb wird folgendes scheinbar zu einem geflügelten Wort:
>
> "Verwende Perl. Shell will man koennen, dann aber nicht verwenden."
> Kristian Koehntopp, de.comp.os.unix.misc
>
> Dem ist nichts hizuzufügen.
Dieser Meinung ist nichts hinzuzufügen.
Jedoch kann man durchaus anderer Meinung sein!:
"Verwende eine gute, moderne Shell aus der ksh-Linie.
Perl ist nicht so universell und aufwendiger zu schreiben, etc."
Ein typisches Unix-System hat heutzutage beispielsweise:
1400 ausführbare Binaries
1100 Shell-Scripts (alle Bourne-Shell!)
60 tcl-Scripts
0 Perl-Scripts
Perl ist also ein spezieller nichtinteraktiver Interpreter,
der C, awk und sed in sich vereinigt,
und nur wesentliche Bedeutung
bei den CGI-Scripts im Internet hat.
>
> Tschüß,
> Michael (trotzdem noch gelegentlich shell programmierend,
> weil's ja wie ne kurze Sache aussieht. Was sich
> meistens als Irrtum herausstellt.)
Zugegeben, /bin/sh und /bin/csh sind bei umfangreichen Aufgaben
sehr ermüdend und auch knifflig zu programmieren,
jedoch ab /bin/ksh sieht das doch *ganz* anders aus!:
Es gibt neue Shells, die viele echte Arbeitskommandos intern
haben, die daraus resultierenden Vorteile voll nutzen
und ksh, bash, zsh funktionell *weit* in den Schatten stellen
und dennoch beispielsweise 15-fach schneller und 5-fach kleiner
als 'bash' sind!
Es ist eine wahre Freude, solche Funktions-Giganten, die trotzdem
nicht überladen und 'leicht' sind, kurz, knapp und schnell
zu programmieren!
Erik Braun
>"Verwende eine gute, moderne Shell aus der ksh-Linie.
> Perl ist nicht so universell und aufwendiger zu schreiben, etc."
Welche Shell empfiehlst Du denn, die universeller als Perl ist, und
mit der mit weniger Aufwand programmiert werden kann?
danke, erik
--
er...@minet.uni-jena.de http://www.minet.uni-jena.de/~erik/
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> wrote:
>
> >"Verwende eine gute, moderne Shell aus der ksh-Linie.
> > Perl ist nicht so universell und aufwendiger zu schreiben, etc."
>
> Welche Shell empfiehlst Du denn, die universeller als Perl ist, und
> mit der mit weniger Aufwand programmiert werden kann?
>
Ich hatte das absichtlich nicht erwähnt, weil das Eigenwerbung
gewesen wäre ...
Ich empfehle 'bsh' bzw. 'bsh.exe', die als kostenlose
Shareware mit Beispiel-Scripts und vielen man-Pages
auf meiner Homepage liegt.
Die dortige Version ist für DOS16, läuft daher überall,
wird auch vom T-Online-Team benutzt,
ist etwa 90 KB groß, braucht 140 KB Speicher
und hat etwa 80 interne Kommandos, darunter:
grep, expr, tr, cat, cut, line, echo, print, prints, fprint,
catv, seek, sum, base, cmpv, read, readl, ifset, ifdef, ...
Der Unterschied zu Perl ist u.a., daß es eine
Bourne/Korn-Shell-typische KOMMANDO-Programmiersprache ist,
die noch mehr Freiheiten und Variationen erlaubt
und sehr kurz formuliert werden kann.
Perl ist eher "C mit eingebauten RegExpressions und sh-Details".
Ein paar Streiflichter:
-----------------------
n-fach indirekter Variablen(längen)zugriff:
${{name} ${{{name} ${{#name} ...
-------------------------------------------------------------------
for 3 flag name wert in n karl wwwww g svxV3.2 www ...
do
...
done
Variante für Tabelleninhalte u.ähnl.
Es werden jeweils n Variablen auf einmal gefüllt.
-------------------------------------------------------------------
[for] [name] [from a] [by n] [to b] repeat
do ...; done
-------------------------------------------------------------------
local a b=bbb c
static # lokal_statisch
global
-------------------------------------------------------------------
funktion() { ...; }
funktion()) { ...; )} # verschachtelt!
-------------------------------------------------------------------
while ; until ; case ; if-elif-else ; {{ local-block; }}
continue [n] ; break [n] ; goend [n] ; goto mmm
-------------------------------------------------------------------
Arithmetik wie in C:
$((...)) ((...)) let arg...
let "a+x>=b&&!c ? i : j = wert" "..."...
i oder j wird in Abhängigkeit gesetzt!
Zahlenbasis 2 bis 36 durchgehend und 256 !
Enthalten sind: Dual(2), Oktal(8), Dez.(10), Hex(16)
-------------------------------------------------------------------
Globales Dateiöffnen:
> datei1 # open()
3<> datei2 # open()
...
catv ... =3
...
><< # close(), close()
-------------------------------------------------------------------
cat $2 | {
> $2
while readl Zeile # liest aus Pipe-Datei
do
...; catv xxx # xxx >> "$2"
done
><
Lösung ohne(!) temporäre Datei.
-------------------------------------------------------------------
Kommando catv:
catv /abc name 100,32,4 ker /%j =$offs,,1:
"abc", der Inhalt der Variablen 'name',
der Inhalt der Datei, die mit Handle 4 verknüpft ist,
ab Offset 100, maximal 32 Byte, Inhalt von 'ker'
und ein Zeilenvorschub
werden in die Datei geschrieben, die mit Handle 1
verknüpft ist, ab $offs, danach wird die Datei ggf.
gekürzt bis zum Offset nach dem Schreibvorgang(:).
Mit beispielsweise
catv ... =:,,description
wird der verkettete Input ans ENDE der Variablen 'descri..'
geschrieben (:) - Offset 0 auf's Ende bezogen.
-------------------------------------------------------------------
Formatierte Ausgabe: prints ssss ..... .... ....
-------------------------------------------------------------------
print -r "aaa$var.$( kommando )"$kh`cmd`.$( cmd $(cmd) )'<<>>'
-------------------------------------------------------------------
Kommandozeilen-Editor (-E / set -E),
besser als 'doskey'.
-------------------------------------------------------------------
Reguläre Ausdrücke (grep,expr) und Unix-Wildcards.
-------------------------------------------------------------------
u.v.a.m.
-------------------------------------------------------------------
Anselm Lingnau
Helmut Schellong <sche...@t-online.de>:
> Jedoch kann man durchaus anderer Meinung sein!:
>
> "Verwende eine gute, moderne Shell aus der ksh-Linie.
> Perl ist nicht so universell und aufwendiger zu schreiben, etc."
`Es ist einfacher, eine Shell zu portieren als ein Shellskript.'
-- Larry Wall
> Ein typisches Unix-System hat heutzutage beispielsweise:
> 1400 ausführbare Binaries
> 1100 Shell-Scripts (alle Bourne-Shell!)
> 60 tcl-Scripts
> 0 Perl-Scripts
> Perl ist also ein spezieller nichtinteraktiver Interpreter,
> der C, awk und sed in sich vereinigt,
> und nur wesentliche Bedeutung
> bei den CGI-Scripts im Internet hat.
Sprich für Dich selber. Ich habe gerade mal hier das Programm
#!/local/bin/perl
while (<>) {
s/^.*?:\s*//;
next if /^(directory|symbolic link)/;
$_ = "ELF executable\n" if /ELF .* executable/;
$count{$_}++;
}
foreach (sort keys %count) {
print "$count{$_}\t$_";
}
über das Ergebnis von `file /bin/* /usr/bin/* /sbin/* /usr/sbin *'
laufengelassen und das folgende Ergebnis bekommen:
13 ASCII text
160 Bourne shell script text
16 Bourne-Again shell script text
3 C shell script text
877 ELF executable
4 English text
1 a /usr/bin/expect -f script text
1 a /usr/bin/uuwish script text
3 a /usr/bin/wish -f script text
83 perl script text
(Die ASCII-Textdateien entpuppen sich bei näherer Betrachtung als schlecht
installierte Perl-Skripten. Grr. Bugreport fällig.)
Zumindest für dieses System kann man also nicht sagen, daß Perl keine
wesentliche Bedeutung hat. Es ist zwar so, daß die Perl-Skripten nicht
alle wichtige unabhängige Funktionalität zur Verfügung stellen (obwohl
es da auch ein paar gibt), sondern hauptsächlich Unterstützung für das
Systemmanagement bieten (indem sie zum Beispiel Abstraktionen für das
Management von Konfigurationsdateien zur Verfügung stellen), aber genau
für sowas ist Perl ja gemacht worden.
> Es gibt neue Shells, die viele echte Arbeitskommandos intern
> haben, die daraus resultierenden Vorteile voll nutzen
> und ksh, bash, zsh funktionell *weit* in den Schatten stellen
> und dennoch beispielsweise 15-fach schneller und 5-fach kleiner
> als 'bash' sind!
Zum Beispiel? Tu Dir keinen Zwang an, das Perl-Programm oben in Deiner
Lieblings-Shell zu formulieren und hier zu posten.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Good software is made or broken by the people who write it, not by the language
used. -- Brian Powell
Erik Braun
>Ich empfehle 'bsh' bzw. 'bsh.exe', die als kostenlose
>Shareware mit Beispiel-Scripts und vielen man-Pages
>auf meiner Homepage liegt.
>Die dortige Version ist für DOS16, läuft daher überall,
äh, das bezweifle ich.
Ich befürchte, daß diese Version für die meisten Leser dieser Newsgruppe
nutzlos ist. Schade.
gruß, erik
--
er...@minet.uni-jena.de http://www.minet.uni-jena.de/~erik/
Bjoern_Hesse
> On 12 Nov 1998 20:17:07 GMT, Helmut Schellong <sche...@t-online.de> wrote:
>
> >Ich empfehle 'bsh' bzw. 'bsh.exe', die als kostenlose
> >Shareware mit Beispiel-Scripts und vielen man-Pages
> >auf meiner Homepage liegt.
> >Die dortige Version ist für DOS16, läuft daher überall,
>
> äh, das bezweifle ich.
>
> Ich befürchte, daß diese Version für die meisten Leser dieser Newsgruppe
> nutzlos ist. Schade.
Wenn die ohne Dos-Extender laeuft, sollte sie im Dosemu eigentlich ganz gut
nutzbar sein.
Bjoern
Michael Staats
Tilman Schmidt
>
> Ich empfehle 'bsh' bzw. 'bsh.exe', die als kostenlose
> Shareware mit Beispiel-Scripts und vielen man-Pages
> auf meiner Homepage liegt.
> Die dortige Version ist für DOS16, läuft daher überall,
Das muß eine Bedeutung des Wortes "überall" sein, die mir bis jetzt
noch nicht geläufig war. (Kleine Anleihe bei Douglas Adams.)
--
Tilman Schmidt E-Mail: Tilman....@sema.de (office)
Sema Group Koeln, Germany til...@schmidt.bn.uunet.de (private)
"newfs leaves the filesystem in a well known state (empty)."
- Henrik Nordstrom
Wolfgang Denk
>Ich empfehle 'bsh' bzw. 'bsh.exe', die als kostenlose
>Shareware mit Beispiel-Scripts und vielen man-Pages
>auf meiner Homepage liegt.
>Die dortige Version ist für DOS16, läuft daher überall,
Vonwegen. Auf keinem meiner Rechner (allesamt Linux oder Solaris)
läuft so ein DOS16 Ding...
>wird auch vom T-Online-Team benutzt,
ROTFL!
>Perl ist eher "C mit eingebauten RegExpressions und sh-Details".
Du machst wohl nicht viel mit Perl, oder?
Wolfgang
--
Phone: (+49)-89-95720-110 Fax: (+49)-89-95720-112 w...@denx.muc.de
Office: (+49)-89-722-27328 Wolfga...@ICN.Siemens.DE
"At least they're __________EXPERIENCED incompetents"
Helmut Schellong
>
> Im Artikel <72ap22$9i0$1...@news02.btx.dtag.de> schrieb
> Helmut Schellong <sche...@t-online.de>:
>
> > Jedoch kann man durchaus anderer Meinung sein!:
> >
> > "Verwende eine gute, moderne Shell aus der ksh-Linie.
> > Perl ist nicht so universell und aufwendiger zu schreiben, etc."
>
> `Es ist einfacher, eine Shell zu portieren als ein Shellskript.'
> -- Larry Wall
Meine bsh-Scripts konzipiere ich in der Regel für UNIX und DOS
gleichzeitig.
Dabei brauche ich zumeist nur auf '\ <--> /' und einige
wenige Kommandos (rm <--> DEL, ...) achtzugeben.
Das heißt, die Scripts laufen vollautomatisch auf beiden (allen)
Systemen, weil es das interne Kommando 'ver' gibt, mit dem ich
mir die Kennzeichner 'unix, dos, ..., shw, frw, full'
geben lassen kann.
Anwender der bsh wollten bisher ausschließlich die DOS-Version,
auch Unix-User.
Sie sagten: "Die läuft ja überall..."
> ............
> 83 perl script text
>
> (Die ASCII-Textdateien entpuppen sich bei näherer Betrachtung als schlecht
> installierte Perl-Skripten. Grr. Bugreport fällig.)
>
> Zumindest für dieses System kann man also nicht sagen, daß Perl keine
> wesentliche Bedeutung hat. Es ist zwar so, daß die Perl-Skripten nicht
> alle wichtige unabhängige Funktionalität zur Verfügung stellen (obwohl
> es da auch ein paar gibt), sondern hauptsächlich Unterstützung für das
> Systemmanagement bieten (indem sie zum Beispiel Abstraktionen für das
> Management von Konfigurationsdateien zur Verfügung stellen), aber genau
> für sowas ist Perl ja gemacht worden.
Mir fällt auf, daß da keine tcl-Scripts sind.
Die perl-Scripts sind offensichtlich ein Ersatz dafür!
Ich bin übrigens absolut kein Gegner von 'perl'!
Nur, bei einer Interpretersprache für universellen, täglichen
Einsatz erwarte ich persönlich -über alles gesehen-
knappe Formulierungsmöglichkeiten und viele Freiheiten.
Nur EIN Beispiel:
Bei perl muß man alle Objekte stets kennzeichnen:
Variablen, Zeichenketten, und bei 'print' muß man alle Args
in eine Kommaliste schreiben - es ist einfach sehr viel mehr
Syntax nötig.
Gegenbeispiel:
echo "aaaaaaaaaa aaa $var mmm: $((16#, a[i]+h+8#774)) mmm%
bbbbbbb '$( kdo )' bbbbbb%
ccccccccccc $( prints s-20- "$fnam" )cccc%
ddddddddddd"
Das finde ich eindeutig besser!
>
> > Es gibt neue Shells, die viele echte Arbeitskommandos intern
> > haben, die daraus resultierenden Vorteile voll nutzen
> > und ksh, bash, zsh funktionell *weit* in den Schatten stellen
> > und dennoch beispielsweise 15-fach schneller und 5-fach kleiner
> > als 'bash' sind!
>
> Zum Beispiel? Tu Dir keinen Zwang an, das Perl-Programm oben in Deiner
> Lieblings-Shell zu formulieren und hier zu posten.
>
> Anselm
Ich hatte vor ein paar Monaten das gleiche wie Du gemacht:
Mit 'find' und 'file' eine Liste vom ganzen System (50000 files)
erstellt und dann just:
for sm in suchmuster_liste
do
conv -"t_ " sm
prints s6bs $( grep -ciF "$sm" $quelle ) "$sm" >> $ziel
done
Ich hatte die Liste aber manuell geschrieben,
weil's ein Einzelzweck war.
Dies ist nur eine von mehreren Lösungsvarianten!
Man kann auch $IFS setzen, dann fiele 'conv' weg.
Eine Dauerlösung müßte die Liste (sml) automatisch erzeugen:
< $quelle
while readl zeile
do expr "$zeile" :sm '^xx%(yyy%)zz$'
catv sml | grep -Fiq "$sm" && continue
catv sm /%j =:,,sml
done
><
Auch hier gibt es viele Varianten:
z.B. oben `makesmlist quelle` einsetzen, wobei dann die sm
in dieser Funktion mit echo auf Handle 1 geschrieben werden.
Mit Datei geht's auch: `cat smlist`
etc.
Helmut Schellong
> Helmut Schellong <sche...@t-online.de>:
> > ........
> > und ksh, bash, zsh funktionell *weit* in den Schatten stellen
> > und dennoch beispielsweise 15-fach schneller und 5-fach kleiner
> > als 'bash' sind!
>
> Zum Beispiel? Tu Dir keinen Zwang an, das Perl-Programm oben in Deiner
> Lieblings-Shell zu formulieren und hier zu posten.
>
> Anselm
Anselm,
ich hatte noch /tmp/FTYP.Z und habe das Beispiel
ganz konkret praktisch realisiert:
cut -f2 -d'TABTAB' $quelle | tr ' ' '@' |
while readl sm
do grep -Fsq "$sm" sml || echo "$sm" >> sml; done
for sm in $( cat sml )
do conv -"t@ " sm
prints s6s3s $( grep -cF "$sm" $quelle ) '' "$sm"
done
Mit der Variablenvariante geht's auch:
#do catv sml | grep -Fq "$sm" || catv sm /%j =:,,sml; done
nur langsamer.
Die Quelldatei hat über 2 MByte!
Die erste Schleife braucht etwa 30 Sekunden,
die zweite 0,5 Sekunden pro Quellen-Scan (pro Typ).
Ich finde, daß meine bsh-Lösung sich sehr gut sehen
lassen kann.
Das Kommando 'file' unter SCO scheint aber besser zu sein...:
Filetyp-Liste SCO OS 5.0.4:
---------------------------
2237 English text
54 ELF 32-bit LSB dynamic lib 80386
12758 ascii text
12701 data
124 empty
1055 commands text
1297 ELF 32-bit LSB executable 80386
433 sh commands text
437 Bourne/Korn shell commands text
288 iAPX 386 COFF demand-paged executable
189 c program text
41 osavtcl commands text
31 uuencoded file
1 Microsoft a.out segmented word-swapped 86 executable
32 DOS executable (COM)
337 iAPX 386 COFF object file not stripped
174 ar archive
60 iAPX 386 COFF object file not stripped - version 30821
1 iAPX 386 COFF object file - version 30821
16 iAPX 386 COFF demand-paged executable not stripped
636 gencat-compiled message catalogue data
4 softmgmtTcl commands text
6 ELF 32-bit LSB relocatable 80386
14 iAPX 386 COFF static shared library not stripped
5 Microsoft a.out separate pure segmented standalone word-swapped 86 executable
1 gzip compressed data - deflate method , original file name , max compression
2074 Compiled Terminfo Entry
10 Bennet Yee's "face" format
13 fortran program text
998 X11 Portable Compiled Format (PCF) font
2 tar archive
16 X11 Speedo font data
16 PostScript Type 1 font text
34 [nt]roff, tbl, or eqn input text
2 csh commands text
3 ksh commands text
723 GIF87 image
60 cannot open, No such file or directory
3 assembler program text
4 mc68k executable not stripped
1 GIF89 image 639 x 881
4106 LZH-compressed data
1 GIF89 image 275 x 105
1 GIF89 image 422 x 79
2 GIF89 image 441 x 39
1 GIF89 image 438 x 87
1 GIF89 image 441 x 166
1 GIF89 image 441 x 69
1 GIF89 image 438 x 271
1 GIF89 image 441 x 129
1 GIF89 image 438 x 110
1 GIF89 image 438 x 264
2 GIF89 image 438 x 50
1 GIF89 image 438 x 39
2 GIF89 image 438 x 107
3 GIF89 image 440 x 86
1 GIF89 image 437 x 687
1 GIF89 image 438 x 374
3 GIF89 image 439 x 107
1 GIF89 image 439 x 214
1 GIF89 image 440 x 165
2 GIF89 image 440 x 150
1 GIF89 image 438 x 129
1 GIF89 image 439 x 86
1 GIF89 image 440 x 59
1 GIF89 image 439 x 150
1 GIF89 image 440 x 244
1 GIF89 image 439 x 44
1 GIF89 image 441 x 195
1 GIF89 image 439 x 129
1 GIF89 image 440 x 171
1 GIF89 image 439 x 320
4 GIF89 image 440 x 107
1 GIF89 image 441 x 50
1 GIF89 image 438 x 309
1 GIF89 image 441 x 117
1 GIF89 image 438 x 72
1 GIF89 image 441 x 35
1 GIF89 image 438 x 35
1 GIF89 image 441 x 57
1 GIF89 image 438 x 57
1 GIF89 image 441 x 107
1 GIF89 image 441 x 256
2 GIF89 image 441 x 44
1 GIF89 image 438 x 192
1 GIF89 image 438 x 150
1 GIF89 image 440 x 497
1 GIF89 image 438 x 101
1 GIF89 image 440 x 65
1 GIF89 image 438 x 44
1 GIF89 image 440 x 22
1 GIF89 image 439 x 171
2 GIF89 image 439 x 22
1 GIF89 image 440 x 129
1 GIF89 image 441 x 22
1 GIF89 image 399 x 206
1 GIF89 image 441 x 338
1 GIF89 image 438 x 255
1 GIF89 image 438 x 314
1 GIF89 image 441 x 133
1 GIF89 image 438 x 182
1 GIF89 image 441 x 272
1 GIF89 image 441 x 302
1 GIF89 image 438 x 58
1 GIF89 image 438 x 115
2 Frame Maker MIF file
2 GIF89 image 227 x 62
4 GIF89 image 227 x 44
2 GIF89 image 227 x 100
4 GIF89 image 227 x 81
2 GIF89 image 231 x 62
3 PostScript document
6 GIF89 image 21 x 20
2 GIF89 image 265 x 282
27 GIF89 image 20 x 20
2 GIF89 image 75 x 165
2 GIF89 image 23 x 20
2 GIF89 image 307 x 126
2 GIF89 image 258 x 134
4 GIF89 image 83 x 57
4 GIF89 image 5 x 20
2 GIF89 image 305 x 113
2 GIF89 image 548 x 129
8 GIF89 image 30 x 30
2 GIF89 image 459 x 126
2 GIF89 image 17 x 20
2 GIF89 image 284 x 73
2 GIF89 image 303 x 111
2 GIF89 image 303 x 108
2 GIF89 image 30 x 20
10 GIF89 image 19 x 20
2 GIF89 image 273 x 149
4 GIF89 image 137 x 137
2 GIF89 image 253 x 147
2 GIF89 image 35 x 74
8 GIF89 image 9 x 26
10 JPEG image
4 GIF89 image 174 x 85
2 GIF89 image 277 x 174
2 GIF89 image 156 x 85
2 GIF89 image 276 x 145
3 MMDF mailer text
147 DOS executable (EXE)
6 X11 Bitmap Distribution Format (BDF) font
12 GIF89 image 52 x 52
5 GIF89 image 55 x 26
1 GIF89 image 38 x 21
2 GIF89 image 24 x 16
1 GIF89 image 200 x 65
1 GIF89 image 77 x 20
1 GIF89 image 119 x 20
2 GIF89 image 110 x 20
1 GIF89 image 144 x 20
2 GIF89 image 66 x 36
1 GIF89 image 81 x 43
1 GIF89 image 91 x 20
1 GIF89 image 94 x 20
5 perl commands text
1 GIF89 image 93 x 93
3 PKZIP archive
8 Java Class File bytecode
2 valid core file (SCO UNIX)
1 tclsh commands text
4 GIF89 image 19 x 19
10 GIF89 image 20 x 23
2 GIF89 image 15 x 15
Helmut Schellong
Anselm,
eine weitere Variante:
cut -f2 -d'TABTAB' $1 | sort |
while readl s
do cmpv s S || prints s6s "$n" " $S" && n=0 S="$s"; let ++n
done
prints s6s "$n" " $S"
Die braucht nur noch 15 Sekunden komplett,
trotz Quelldatei >2 MB, und ist noch kürzer.
Bei vorheriger Variante muß noch ein 'TAB' ergänzt werden:
prints s6s3s $( grep -cF "TAB$sm" $quelle ) '' "$sm"
wegen -F und osavtcl ...
vtcl ...
tcl ...
Filetyp-Liste SCO OS 5.0.4:
---------------------------
34 [nt]roff, tbl, or eqn input text
10 Bennet Yee's "face" format
437 Bourne/Korn shell commands text
2074 Compiled Terminfo Entry
32 DOS executable (COM)
147 DOS executable (EXE)
54 ELF 32-bit LSB dynamic lib 80386
1297 ELF 32-bit LSB executable 80386
6 ELF 32-bit LSB relocatable 80386
2237 English text
2 Frame Maker MIF file
723 GIF87 image
8 GIF89 image
n GIF89 image ...
10 JPEG image
8 Java Class File bytecode
4106 LZH-compressed data
3 MMDF mailer text
1 Microsoft a.out segmented word-swapped 86 executable
5 Microsoft a.out separate pure segmented standalone word-swapped 86 executable
3 PKZIP archive
16 PostScript Type 1 font text
3 PostScript document
6 X11 Bitmap Distribution Format (BDF) font
998 X11 Portable Compiled Format (PCF) font
16 X11 Speedo font data
172 ar archive
12758 ascii text
3 assembler program text
189 c program text
60 cannot open, No such file or directory
111 commands text
7014 compressed data
2 csh commands text
888 data
8 directory
109 empty
13 fortran program text
636 gencat-compiled message catalogue data
1 gzip compressed data - deflate method , original file name , max compression
272 iAPX 386 COFF demand-paged executable
16 iAPX 386 COFF demand-paged executable not stripped
1 iAPX 386 COFF object file - version 30821
277 iAPX 386 COFF object file not stripped
60 iAPX 386 COFF object file not stripped - version 30821
3 iAPX 386 COFF static shared library
14 iAPX 386 COFF static shared library not stripped
3 ksh commands text
4 mc68k executable not stripped
41 osavtcl commands text
5 perl commands text
427 sh commands text
4 softmgmtTcl commands text
2 tar archive
14 tcl commands text
1 tclsh commands text
31 uuencoded file
2 valid core file (SCO UNIX)
10 vtcl commands text
Helmut Schellong
>
> >> Perl ist also ein spezieller nichtinteraktiver Interpreter,
> >> der C, awk und sed in sich vereinigt,
> >> und nur wesentliche Bedeutung
> >> bei den CGI-Scripts im Internet hat.
>
> > Sprich für Dich selber. Ich habe gerade mal hier das Programm
>
> > #!/local/bin/perl
>
> > while (<>) {
> > s/^.*?:\s*//;
> > next if /^(directory|symbolic link)/;
> > $_ = "ELF executable\n" if /ELF .* executable/;
> > $count{$_}++;
> > }
>
> > foreach (sort keys %count) {
> > print "$count{$_}\t$_";
> > }
>
> dem TRS-80, bei denen ein Stück Maschinensprache in der ersten Zeile
> versteckt gewesen ist. Da nehm ich dann doch lieber Python.
>
> Cao
> jay
>
> --
> Klaus-J. Wolf - It's the end of the world as we know it.
> http://pweb.uunet.de/shunyata.nom/yanestra/software.html
Einerseits hast Du mit Deinen heftigen Worten Recht,
andererseits gebe ich jeder Programmiersprache
eine Chance - jede Sprache hat Stärken und Schwächen.
Perl gibt es schon lange, länger als Korn-Shell.
Ich bin ziemlich sicher, wenn ksh gleichzeitig mit perl
aufgekommen wäre, hätte ksh gewonnen.
Diejenigen Teile von perl, die von awk/C abstammen,
sind ja gut, jedoch wenn die perl-Spezifika hinzukommen,
sieht's tatsächlich 'komisch verdreht', kryptisch
und sehr 'implizit' aus.
Der Vorteil ist, wenn eine Aufgabe gut zu den impliziten
perl-Mechanismen paßt, wird's kurz und effizient.
Ich hab auch mal folgendes probiert:
open(QUELLE, "<$ARGV[0]");
while (<QUELLE>) {
s/^[^\t]+\t+//;
$count{$_}++;
}
close(QUELLE);
foreach (sort keys %count) {
print "$count{$_}\t$_";
}
Das läuft schneller als meine bsh-Lösung:
cut -f2 -d'TABTAB' $1 | sort |
while readl s
do cmpv s S || prints s6s $n " $S" && n=0 S="$s"; let ++n
done
prints s6s $n " $S"
wobei aber '/bin/sort' die meiste Zeit verbraucht.
(Sicher nicht die effizienteste Implementation)
Alle anderen Kommandos sind bsh-intern.
Sämtliche Aspekte und Details betrachtend gefallen mir
besonders 'bsh' aber auch 'ksh' besser als 'perl'.
Die Syntax ist 'ordentlicher' - eine klassische
Kommando-Programmiersprache halt.
Mit noch mehr Freiheiten und Variantenreichtum,
letztlich noch knapper formulierbar.
Und es sind Shells mit Prompt und Kommandozeilen-Editor...
Die Syntax von 'Python' kenne ich (noch) nicht.
Die ist -vergleichsweise!- ziemlich unbekannt.
Martin Neumann
sche...@t-online.de (Helmut Schellong) writes:
> Filetyp-Liste SCO OS 5.0.4:
> ---------------------------
Toll :-(
Was hat das mit GNU-Software zu tun?
--
mn++ <m...@denise.westfalen.de>
echo 'znvy?%f?whfgsbesha?za^qravfr&jrfgsnyra&qr?!$/&fvtangher'|tr \
'?n-z$N-Z&a-m!A-M^%' ' a-m~A-M.n-z<N-Z@-'|$(echo 'Plattfisch'|tr -d \
'Packetlift')&&echo D$(echo Leitplanke|sed -e 's/.\{6\}//')||echo 'oops.'
Erik Braun
>Anwender der bsh wollten bisher ausschließlich die DOS-Version,
>auch Unix-User.
>Sie sagten: "Die läuft ja überall..."
mir ist das ein wenig unklar.
Wie bekomme ich eine DOS-Version unter Digital Unix zum laufen?
danke, erik
--
er...@minet.uni-jena.de http://www.minet.uni-jena.de/~erik/
Helmut Schellong
>
> In article <72ioe2$mgc$1...@news02.btx.dtag.de>,
> sche...@t-online.de (Helmut Schellong) writes:
>
> > ---------------------------
>
> Was hat das mit GNU-Software zu tun?
Einerseits nichts, andererseits alles!
Es geht hier doch nicht um die Bedeutung des Inhalts
der Liste oder deren Herkunft,
sondern um irgendeine TAB-delimited-Liste an sich,
die mit einem Script erzeugt wurde!!!
Es werden hier verschiedene Interpreter-Sprachen
diskutiert!
Dieses penible offtopic-Herumreiten verläßt manchmal
schon den Rahmen des Vernünftigen!
GNU ist ein allgemeines Unix-Thema.
GNU ist mit der gesamten Unix-Welt verknüpft!
Auch SCO bietet **hundertfach** GNU-Software an!!!
GNU gab es schon als es Linux noch nicht gab!
Seit wann darf man nur Linux in einem gnu-Forum bringen?!
Helmut Schellong
>
> On 13 Nov 1998 19:39:00 GMT, Helmut Schellong <sche...@t-online.de> wrote:
>
> >Anwender der bsh wollten bisher ausschließlich die DOS-Version,
> >auch Unix-User.
> >Sie sagten: "Die läuft ja überall..."
Die wollten auch den 'Brückenschlag':
eine solche Funktionalität *auch* unter DOS!
>
> mir ist das ein wenig unklar.
> Wie bekomme ich eine DOS-Version unter Digital Unix zum laufen?
>
> danke, erik
Ist dieses angestrengte Unverständnis Absicht?
Die Sache dürfte doch klar sein!:
Wenn hier ausdrücklich von einem DOS16-Programm die Rede ist,
ist es doch logisch, daß *das* nur in allen DOS-Umgebungen
laufen kann!
Und wo gibt es DOS-Umgebungen?
Fast überall!
Nämlich: MS-DOS, DR-DOS, PC-DOS, ...,
alle DOS-Boxen, alle DOS-Emulatoren(Linux,SCO-Merge,...).
Kürzlich hat mich ein zufriedener Vollversion-Kunde
angemailt: "Hi, die bsh läuft bei mir auch mit'm DOS-emu
unter Linux...fein!
Die läuft ja überall."
Jetzt verstanden?
Für Digital Unix müßte man den bsh-Quellkode erst mit
dem dortigen 'cc' kompilieren.
Möglicherweise geht's mit '#define UNIX' allein
schon auf Anhieb...
(Quellkode ist aber nicht öffentlich)
Anselm Lingnau
Helmut Schellong <sche...@t-online.de>:
> Perl gibt es schon lange, länger als Korn-Shell.
Das ist nicht richtig. Die Kornshell gibt es schon seit der Mitte der
80er Jahre. Allerdings war sie zu Anfang nicht arg weit verbreitet, da
schwer zu kriegen (AT&T wollte Geld dafür). -- Perl ist eigentlich erst
seit Anfang der 90er so richtig im Umlauf, obwohl frühe Perls auch in
die späten 80er fallen.
> Ich bin ziemlich sicher, wenn ksh gleichzeitig mit perl
> aufgekommen wäre, hätte ksh gewonnen.
Unwahrscheinlich. Die Kornshell ist eine Shell mit allen ihren Vor- und
Nachteilen -- im Vergleich zu ihrer Syntax ist Perl noch fast logisch,
da es in Perl immerhin keine multiplen aufeinanderfolgenden
Ersetzungsdurchgänge gibt wie bei der (Korn-)Shell (Perl kann Puristen
zwar durch die Interpunktion verschrecken, aber das ist zum größten Teil
Geschmackssache; wem das nicht paßt, der kann Python benutzen, falls es
ihm nichts ausmacht, daß Schleifen `nur' durch Einrückung begrenzt
werden (Dementi: Python ist auch eine nette Programmiersprache,
jedenfalls um Längen besser als die Shell)), und außerdem forkt die
Kornshell wie jede Shell rechts und links Massen von Prozessen, was sie
natürlich langsamer dastehen läßt als Perl. Für viele Aufgaben ist
Effizienz aber durchaus ein Faktor.
Unabhängig davon hat Perl den großen Vorteil, halbwegs vernünftige
Datenstrukturen zu unterstützen. Heutiges Perl erlaubt ja sogar
Referenzen und objektorientierte Programmierung, und da kann die
Kornshell beim besten Willen nicht mehr mithalten. Bei der Kornshell ist
man für interessante Funktionalität im wesentlichen gezwungen, externe
Programme über Pipes aneinanderzuhängen. Das ist natürlich ein mächtiges
Konzept, aber auch nicht ohne seine Nachteile. Zum Beispiel müssen alle
komplexen Datenstrukturen zum Verschicken über eine Pipe irgendwie
ASCIIfiziert werden (und auf der Empfängerseite wieder
zurückkonvertiert). Das ist im einfachsten Fall lästig und im
allgemeinen Fall ein verdammtes Ärgernis, das zu verquerem Code und
Ineffizienzen führt. Außerdem hat Perl im Gegensatz zur Kornshell ein
vernünftiges Modulkonzept. Bei entsprechender Umsicht lassen sich ohne
weiteres Perl-Programme schreiben, die über Zehntausende von Zeilen
gehen; ein Kornshell-Skript in dieser Größe würde Werke von Stephen King
verblassen lassen.
Die Vermutung, daß die Kornshell Perl hätte ersetzen können, kann nur
jemand aufstellen, der die beiden Programme nicht wirklich kennt.
Tatsache ist, daß sie in verschiedenen Ligen spielen und beide ihre
Nische haben. Niemand würde dauerhaft auf die Idee kommen, Perl als
Kommando-`Shell' für den interaktiven Gebrauch einzusetzen (obwohl es
geht), und niemand, der einen Rest von Vernunft besitzt, würde
CGI-Skripten mit einer Shell implementieren, um nur mal zwei Beispiele
zu nennen. Als weitere Illustration läßt sich anführen, daß man zum
Beispiel X-Oberflächen bequem mit Perl implementieren kann (unter
Zuhilfenahme von Tk). Es gab im Rahmen von CDE mal eine
Ksh-Implementierung mit einer Anbindung an Motif, aber schon bei dem
Gedanken daran läuft es mir kalt den Rücken hinunter.
> cut -f2 -d'TABTAB' $1 | sort |
> while readl s
> do cmpv s S || prints s6s $n " $S" && n=0 S="$s"; let ++n
> done
> prints s6s $n " $S"
Das mußte ich einfach mal so zitieren :^) Wer über die Syntax von Perl
lästert und gleich im Anschluß danach sowas postet, der verliert in
meinen Augen den letzten Rest von Glaubwürdigkeit. Ich habe in meiner
Zeit wirklich genug Shellskripten geschrieben, aber das, was da steht,
finde *ich* komisch verdreht, kryptisch und sehr implizit. Kleines
Beispiel: `cut' benutzt `-f', um ein Feld zum Ausschneiden anzugeben,
und `-d', um das Trennzeichen anzugeben. Die entsprechenden Optionen für
`sort' (das externe Programm) werden in Deinem Beispiel nicht gebraucht,
aber sie heißen respektive `-k' und `-t'. Solltest Du auf die Idee
kommen, awk aufrufen zu wollen, müßtest Du `-T' für das Trennzeichen
angeben und so weiter. Das ist nicht gerade ein Beispiel für Konsistenz.
Im Vergleich zu `printf', das es in analoger Form in der Shell, in C und
auch Perl gibt, finde ich Deine `prints'-Syntax ziemlich kryptisch. (Im
übrigen scheint mir das Programm nichts zu tun, was man nicht auch mit
`sort ... | uniq -c' hinkriegen würde, aber das gehört wohl nicht
hierher.)
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Software engineering: how to program if you cannot. -- Edsger W. Dijkstra
Helmut Schellong
>
> Im Artikel <72nfbu$mj2$1...@news02.btx.dtag.de> schrieb
> Helmut Schellong <sche...@t-online.de>:
>
> > Perl gibt es schon lange, länger als Korn-Shell.
>
> Das ist nicht richtig. Die Kornshell gibt es schon seit der Mitte der
> 80er Jahre. Allerdings war sie zu Anfang nicht arg weit verbreitet, da
> schwer zu kriegen (AT&T wollte Geld dafür). -- Perl ist eigentlich erst
> seit Anfang der 90er so richtig im Umlauf, obwohl frühe Perls auch in
> die späten 80er fallen.
Genau das ist der Knackpunkt!
Nicht die bloße Existenz der ksh meinte ich, sondern grundsätzlich
die standardmäßige Verfügbarkeit.
Ich hatte schon vielfach in Fachzeitschriften von perl gelesen
als von ksh meilenweit noch nix zu sehen war, in den Fachz.
als auch in /bin .
>
> > Ich bin ziemlich sicher, wenn ksh gleichzeitig mit perl
> > aufgekommen wäre, hätte ksh gewonnen.
>
> Unwahrscheinlich. Die Kornshell ist eine Shell mit allen ihren Vor- und
> Nachteilen -- im Vergleich zu ihrer Syntax ist Perl noch fast logisch,
> da es in Perl immerhin keine multiplen aufeinanderfolgenden
> Ersetzungsdurchgänge gibt wie bei der (Korn-)Shell (Perl kann Puristen
Das schenkt einem aber einen unglaublichen Variantenreichtum
und sehr knappe Formulierungen!
> zwar durch die Interpunktion verschrecken, aber das ist zum größten Teil
Siehe Beitrag zuvor: "würg..."
> Geschmackssache; wem das nicht paßt, der kann Python benutzen, falls es
> ihm nichts ausmacht, daß Schleifen `nur' durch Einrückung begrenzt
Python ist allerdings sehr neu...
> werden (Dementi: Python ist auch eine nette Programmiersprache,
> jedenfalls um Längen besser als die Shell)), und außerdem forkt die
> Kornshell wie jede Shell rechts und links Massen von Prozessen, was sie
> natürlich langsamer dastehen läßt als Perl. Für viele Aufgaben ist
> Effizienz aber durchaus ein Faktor.
Richtig!
Deshalb hab ich auch die bsh entwickelt, die
50/15/10/...-fach schneller ist als 4dos/bash/zsh/...!
Und mehr bietet als alle anderen Shells
und die Vorzüge von internen Kommandos stark ausnutzt.
Die bsh ist sogar als DOS-Version der bash weit überlegen!
A r b e i t s g e s c h w i n d i g k e i t
------------------------------------------------------------------
bsh ************************************************************
ksh *******************************************
zsh *****
bash ***
csh **
4dos *
sh -
------------------------------------------------------------------
Die Größen der Shell-Executables:
---------------------------------------------------------------
bsh 95K (DOS), 103K (COFF), 87K (ELF)
4dos 180K (DOS)
ksh 152K (ELF)
zsh 503K (COFF)
bash 528K (COFF)
csh 75K (ELF)
sh 57K (ELF)
---------------------------------------------------------------
Als einzige Shell hat die bsh zusätzlich die Kommandos
grep, expr, tr, cut, cat, prints, sum, crc,
wc, line, tee, catv, base, ...
eingebaut(!), die man nicht als typische Buildins bezeichnen kann.
Man kommt so fast gänzlich ohne Externals aus!
>
> Unabhängig davon hat Perl den großen Vorteil, halbwegs vernünftige
> Datenstrukturen zu unterstützen. Heutiges Perl erlaubt ja sogar
> Referenzen und objektorientierte Programmierung, und da kann die
"Heutiges Perl" ist das Stichwort!
Als ich sagte, daß die ksh wahrscheinlich gewonnen hätte, meinte
ich selbstverständlich einen Vergleich *damals*.
Referenzen: Deshalb unterstützt bsh auch mehrfache Indirektion.
> Kornshell beim besten Willen nicht mehr mithalten. Bei der Kornshell ist
> man für interessante Funktionalität im wesentlichen gezwungen, externe
> Programme über Pipes aneinanderzuhängen. Das ist natürlich ein mächtiges
> Konzept, aber auch nicht ohne seine Nachteile. Zum Beispiel müssen alle
> komplexen Datenstrukturen zum Verschicken über eine Pipe irgendwie
> ASCIIfiziert werden (und auf der Empfängerseite wieder
> zurückkonvertiert). Das ist im einfachsten Fall lästig und im
> allgemeinen Fall ein verdammtes Ärgernis, das zu verquerem Code und
Siehe bsh-intern: 'catv, base, base#number'
> Ineffizienzen führt. Außerdem hat Perl im Gegensatz zur Kornshell ein
> vernünftiges Modulkonzept. Bei entsprechender Umsicht lassen sich ohne
> weiteres Perl-Programme schreiben, die über Zehntausende von Zeilen
> gehen; ein Kornshell-Skript in dieser Größe würde Werke von Stephen King
> verblassen lassen.
Deshalb hat bsh auch u.a.: local, static, global !
und erlaubt verschachtelte Funktionsdefinitionen und -löschungen.
>
> Die Vermutung, daß die Kornshell Perl hätte ersetzen können, kann nur
> jemand aufstellen, der die beiden Programme nicht wirklich kennt.
Ich sagte nicht "ersetzen", sondern meinte, daß die Gunst der User
-zumindest zunächst- in Richtung der ksh hätte ausschlagen können.
Das hätte -damals!- durchaus passieren können,
weil ksh die *bekannte* sh erweitert, perl jedoch völlig anders war/ist.
Viele Dinge hängen 'vom richtigen Zeitpunkt' (u.ähnl.) ab!
In diesem letzten Absatz (die vorherigen waren sachlich) versuchst Du
aber sehr konstruiert, mir 'was am Zeuge zu flicken'!
Du hattest aufgefordert, eine Lösungsvariante für meine Lieblings-Shell
zu zeigen - und das hab ich getan - und es sind einwandfrei
funktionierende Varianten und kurze Varianten.
Jemand anderer hatte sich über DEINE Variante ausgekotzt,
und ICH habe daraufhin perl verteidigt!
Das Kommando 'uniq' ist bei der DOS-Version der bsh nicht verfügbar.
Außerdem hätte ich dann dessen Ausgabeformat hinnehmen müssen!
Ich wollte aber alle Worte selbst justieren können.
Und sort ... | uniq -c wäre ja wohl keine Lösungsvariante
*mit* meiner Lieblings-Shell gewesen!
Wenn printf: "%6s %s\n" verlangt,
und prints: s6s ,
wo bitte ist das kryptisch?
prints ist nichts weiter als ein vereinfachter(!) Auszug
aus printf !
Die Kommando-Optionen allgemein unter Unix sind tatsächlich
inkonsistent.
Die Gründe liegen auf der Hand und müssen wohl kaum erklärt werden.
Michael Staats
>Ist dieses angestrengte Unverständnis Absicht?
>Die Sache dürfte doch klar sein!:
>Wenn hier ausdrücklich von einem DOS16-Programm die Rede ist,
>ist es doch logisch, daß *das* nur in allen DOS-Umgebungen
>laufen kann!
>Und wo gibt es DOS-Umgebungen?
>Fast überall!
DOS Umgebungen gibt es nicht fast überall, sondern fast
nirgendwo.
>Kürzlich hat mich ein zufriedener Vollversion-Kunde
>angemailt: "Hi, die bsh läuft bei mir auch mit'm DOS-emu
> unter Linux...fein!
> Die läuft ja überall."
Das ist pervers. Unter Linux gibt es ja nun einen Haufen Skript-
sprachen, und warum soll man dann noch eine unter einem kastrierten
BIOS Emulator laufen lassen? Die zudem mindestens genauso kryptisch
wie perl ist, wie Du ja eindrucksvoll demonstriert hat, und ich will
nicht _noch_ eine Scriptsprache lernen, die nur auf einer sehr
eingeschränkten Klasse Maschinen läuft, während andere Skriptsprachen
wirklich fast überall laufen.
>Jetzt verstanden?
Ja, schon länger.
>(Quellkode ist aber nicht öffentlich)
Damit sind wir jetzt wirklich in d.c.gnu off-topic, zumindest was
Deine shell an sich angeht. Die Diskussion über freie Software
vs. Deine shell halte ich noch für on-topic.
Tschüß,
Michael
Martin Neumann
sche...@t-online.de (Helmut Schellong) writes:
>> Was hat das mit GNU-Software zu tun?
>
> Einerseits nichts, andererseits alles!
Aha.
> Es geht hier doch nicht um die Bedeutung des Inhalts
> der Liste oder deren Herkunft,
> sondern um irgendeine TAB-delimited-Liste an sich,
> die mit einem Script erzeugt wurde!!!
Und Scripte haben automatisch was mit GNU-Software zu tun, ja?
> Es werden hier verschiedene Interpreter-Sprachen
> diskutiert!
Und deswegen musst du eine KB lange Liste posten?
> Dieses penible offtopic-Herumreiten verläßt manchmal
> schon den Rahmen des Vernünftigen!
Ja, wirklich. Diese Gruppeneinteilung ist recht laestig, wie waere
es mit misc.misc?
> GNU ist ein allgemeines Unix-Thema.
Soso. Deswegen ist GNU wohl auch das Ankronym fuer "GNU's not UNIX".
> GNU ist mit der gesamten Unix-Welt verknüpft!
> Auch SCO bietet **hundertfach** GNU-Software an!!!
> GNU gab es schon als es Linux noch nicht gab!
Und deswegen musst du eine KB lange Liste posten?
> Seit wann darf man nur Linux in einem gnu-Forum bringen?!
Seit Linux unter der GPL steht.
Im Ernst:
Mir gehen schlicht und einfach diese mehrfach geposteten Listen auf
den Keks, ich glaube nicht, dass nicht auch ein dreizeiliger Auszug
aus der Liste genuegt haette. Und jetzt Flup2 poster.
Helmut Schellong
>
> sche...@t-online.de (Helmut Schellong) writes:
>
> >Ist dieses angestrengte Unverständnis Absicht?
> >Die Sache dürfte doch klar sein!:
>
> >Wenn hier ausdrücklich von einem DOS16-Programm die Rede ist,
> >ist es doch logisch, daß *das* nur in allen DOS-Umgebungen
> >laufen kann!
> >Und wo gibt es DOS-Umgebungen?
> >Fast überall!
>
> DOS Umgebungen gibt es nicht fast überall, sondern fast
> nirgendwo.
DOS-Umgebungen gibt's unter Win3.x, Win95/98, WinNT, OS/2,
Linux, SCO-Unix, ...
also fast überall.
Wieviel Prozent Marktanteil haben denn wohl die oben
aufgeführten Systeme in der Summe?(!)
Allein SCO hat unter den PC-Unixen einen Anteil
von fast 90 Prozent,
und in der gesamten Unix-Welt einen Anteil von 40%.
>
> >Kürzlich hat mich ein zufriedener Vollversion-Kunde
> >angemailt: "Hi, die bsh läuft bei mir auch mit'm DOS-emu
> > unter Linux...fein!
> > Die läuft ja überall."
>
> Das ist pervers. Unter Linux gibt es ja nun einen Haufen Skript-
> sprachen, und warum soll man dann noch eine unter einem kastrierten
> BIOS Emulator laufen lassen? Die zudem mindestens genauso kryptisch
> wie perl ist, wie Du ja eindrucksvoll demonstriert hat, und ich will
> nicht _noch_ eine Scriptsprache lernen, die nur auf einer sehr
> eingeschränkten Klasse Maschinen läuft, während andere Skriptsprachen
> wirklich fast überall laufen.
Die bsh läuft unter DOS ohne jede Funktionalitätseinbuße
wie unter Unix, nur langsamer.
Außerdem ist die DOS-Variante nur EINE von vielen möglichen,
weil bisher praktisch nur diese verlangt wurde.
Daher liegt bisher auch nur diese als kostenlose Shareware
auf meiner Homepage,
übrigens ohne Funktionalitätsbeschränkung und ohne Abschaltung
nach z.B. 30 Tagen.
Zudem ist die bsh unter DOS absolut konkurrenzlos.
Die bsh ist fast vollkommen kompatibel mit ksh,
wenn man deren Erweiterungen nicht verwendet,
und ksh wiederum ist kompatibel mit sh.
Ich finde keineswegs, daß die Syntax der Shells aus
der Bourne-Shell-Linie mindestens so kryptisch ist
wie perl - perl ist doch merklich kryptischer und vor
allem impliziter.
Schon mal auf den Gedanken gekommen, daß ich meinen Satz:
"komisch verdreht, kryptisch, implizit"
überhaupt gar nicht negativ meine?!
Ich zähle damit nur Fakten auf, die von *mir*, wenn daraus
Vorteile resultieren, durchaus ohne Groll akzeptiert werden!
Ich selbst verwende natürlich eine Unix-Variante der bsh,
und wenn ich ein Beispiel-Script für meine Homepage testen
will, geb ich kurz 'dos' ein und rufe bshs.exe script auf...
Die bsh ist ganz sicher und zweifelsfrei eine nützliche
Alternative und Ergänzung zu den anderen Interpretern,
und je nach Entwicklungsschwerpunkt, Problemstellungen
und Neigung werden manche häufiger zu perl greifen
und andere häufiger bsh oder eine andere Shell einsetzen.
Ich bin mir sicher, daß die bsh unter den Shells (ohne perl)
derzeit den Gipfel bezüglich Problemlösungskraft markiert.
Das kann man aber erst erkennen, wenn man 'bsh.mnk' oder
'bshmnk.htm' liest...
>
> >Jetzt verstanden?
>
> Ja, schon länger.
Das ist fein. :-)
>
> >(Quellkode ist aber nicht öffentlich)
>
> Damit sind wir jetzt wirklich in d.c.gnu off-topic, zumindest was
> Deine shell an sich angeht. Die Diskussion über freie Software
> vs. Deine shell halte ich noch für on-topic.
>
> Tshüß,
> Michael
Meines Wissens gibt es NUR den bash-Quellkode öffentlich.
Betreffend die Merkmale
Arbeitsgeschwindigkeit, Programmgröße, Ressourcenbedarf,
Funktionalität und Portabilität
stellt die bsh derzeit den 'Weltrekord' dar.
Deshalb gebe ich den Quellkode nicht her;
außerdem wäre dann zu befürchten, daä man endlos, endlos,
endlos über meinen Programmierstil lästerte!
Ich bin nämlich eigentlich Elektronik-Entwicklungsingenieur,
der auch 'Embedded Systems' entwickelt hat
und daher extrem effizient entwickelt,
das heiät, ich werfe mit Adressen, Rekursivität, etc.,
nur so um mich... - ein C-Guru eben.
Helmut Schellong
>
> In article <72pt5n$l7o$1...@news02.btx.dtag.de>,
> sche...@t-online.de (Helmut Schellong) writes:
>
> >> Was hat das mit GNU-Software zu tun?
> >
> > Einerseits nichts, andererseits alles!
>
> Aha.
>
> > Es geht hier doch nicht um die Bedeutung des Inhalts
> > der Liste oder deren Herkunft,
> > sondern um irgendeine TAB-delimited-Liste an sich,
> > die mit einem Script erzeugt wurde!!!
>
> Und Scripte haben automatisch was mit GNU-Software zu tun, ja?
Wenn man mal von .BAT absieht, durchaus ja!
(Ueberwiegende Gegebenheiten in der Praxis)
>
> > Es werden hier verschiedene Interpreter-Sprachen
> > diskutiert!
>
> Und deswegen musst du eine KB lange Liste posten?
Ja, und ob!
Es hatte jemand den Anfang gemacht und SEINE Liste gepostet,
und mich aufgefordert, MEINE Lösung zu posten!
Und eine Liste mit etwa 60 Zeilen und 2KB Länge ist ja wohl
noch keine 'Belastung', sondern liegt im Bereich ganz normaler
Beitragslängen!
>
> > Dieses penible offtopic-Herumreiten verläßt manchmal
> > schon den Rahmen des Vernünftigen!
>
> Ja, wirklich. Diese Gruppeneinteilung ist recht laestig, wie waere
> es mit misc.misc?
>
> > GNU ist ein allgemeines Unix-Thema.
>
> Soso. Deswegen ist GNU wohl auch das Ankronym fuer "GNU's not UNIX".
Ja, ganz genau deshalb!
Das Augenzwinkern des Schöpfers dieses rekursiven Begriffes
hast Du wohl noch nicht bemerkt.
GNU ist PD-Software grundsätzlich für alle Betriebssyteme.
De Fakto ist sie weit überwiegend in der Unix-Welt verbreitet.
>
> > GNU ist mit der gesamten Unix-Welt verknüpft!
> > Auch SCO bietet **hundertfach** GNU-Software an!!!
> > GNU gab es schon als es Linux noch nicht gab!
>
> Und deswegen musst du eine KB lange Liste posten?
Nicht *deswegen*. (siehe oben)
>
> > Seit wann darf man nur Linux in einem gnu-Forum bringen?!
>
> Seit Linux unter der GPL steht.
Das ist schlichtweg Quatsch.
Hier reden andere durchaus auch von 'Digital Unix', usw.
Als Linux noch nicht GPL hatte, durfte man hier auch schon
von Linux reden, und zwar weil es GNU-Software für Linux gab.
>
> Im Ernst:
> Mir gehen schlicht und einfach diese mehrfach geposteten Listen auf
> den Keks, ich glaube nicht, dass nicht auch ein dreizeiliger Auszug
> aus der Liste genuegt haette. Und jetzt Flup2 poster.
>
Da hast Du Recht, ein Dreizeiler hätte nicht gereicht.
Dis zweite -gekürzte!- Liste hatte ich gepostet, weil die erste
leicht fehlerhaft war, genau bei den Zeilen, um die es ging.
Es ging hier nämlich darum, welche ausführbaren Dateiarten
es wie häufig gibt unter diversen Sustemen,
und wie man sieht, sind die über mein gesamtes Listing
verstreut vorhanden.
Die zweite Liste kam ja NACH Deinem ersten Artikel,
in dem Du gezielt die '...SCO...'-Zeile auf's Korn nahmst.
Für monothematische Linux-Freaks gibt's ja auch ganz
spezielle NewsGroups außerhalb dieser NG...
Karl Eichwalder
| außerdem wäre dann zu befürchten, daä man endlos, endlos,
| endlos über meinen Programmierstil lästerte!
Sei unbesorgt, das GNU Project hat durchaus Platz für Exoten. In
standards.texi (vgl. ftp://ftp.gnu.org) wird wohl ausführlich dargelegt,
warum es gut ist, GNU Software nach bestimmten Vorgaben zu entwickeln.
Gleichzeitig wird aber auch gesagt, dass man die Programmier-Eigenheiten
eines jeden existierenden Programms zu respektieren habe, wenn man
Beiträge liefern möchte.
PS. Ich denke, wir (= die GNU Leute und du) reden noch sehr aneinander
vorbei; leider musst du dir auch ein Informationsdefizit vorwerfen
lassen -- um fortgesetzte Missverständnisse zu vermeiden wäre es
hilfreich, wenn du die Dokumente aus dem etc-Verzeichnis des Emacs
bzw. vom GNU Webserver (http://www.gnu.org) lesen würdest.
--
Karl Eichwalder
Michael Staats
>Michael Staats wrote:
>> DOS Umgebungen gibt es nicht fast überall, sondern fast
>> nirgendwo.
>DOS-Umgebungen gibt's unter Win3.x, Win95/98, WinNT, OS/2,
>Linux, SCO-Unix, ...
>also fast überall.
Das sind alles Programme (Betriebssytem will ich den Win-Kram gar
nicht nennen), die auf PC Hardware laufen. Es gibt noch mehr auf
dieser Welt. Ich weiß, daß es auch für andere Maschinen Win Emulatoren
gibt, aber naturgemäß funktionieren die nur bedingt, und sind vor
allem grottenlangsam.
>Wieviel Prozent Marktanteil haben denn wohl die oben
>aufgeführten Systeme in der Summe?(!)
>Allein SCO hat unter den PC-Unixen einen Anteil
>von fast 90 Prozent,
>und in der gesamten Unix-Welt einen Anteil von 40%.
Wir brauchen das jetzt nicht weiter diskutieren, aber bei diesen
Rechnern handelt es sich um PCs, also persönliche Rechner. Hier an der
Uni leben z. B. Tausende von Studi-Accounts auf ein paar
HP-UX-Kisten. Wie willst Du das zählen?
>Die bsh läuft unter DOS ohne jede Funktionalitätseinbuße
>wie unter Unix, nur langsamer.
Dann kann sie ja nicht viel können. DOS enthält doch die ein oder
andere Einschränkung gegenüber Unix, und wenn die auch in der Unix
Version drin sind, na toll.
>Zudem ist die bsh unter DOS absolut konkurrenzlos.
Nun, ich kenne bsh nicht, aber daß sie unter DOS konkurrenzlos ist,
naja, das ist ja auch nichts so besonderes.
(Nebenbei: Unter AIX wird mit bsh die gute alte bourne shell
bezeichnet, /bin/sh ist die POSIX shell. Das könnte woanders auch so
sein, weiß ich aber nicht.)
>Meines Wissens gibt es NUR den bash-Quellkode öffentlich.
Ja, das glaube ich, daß das Deinem Wissen entspricht (SCNR) :-)
Es gibt mindestens noch sh, pdksh, zsh, ash, abgesehen von den
Nicht-Shell Skript Sprachen perl, sed, awk, tcl, ...
>Betreffend die Merkmale
>Arbeitsgeschwindigkeit, Programmgröße, Ressourcenbedarf,
>Funktionalität und Portabilität
>stellt die bsh derzeit den 'Weltrekord' dar.
Ich kenne Deine bsh nun nicht, aber ich melde mal Zweifel an. Auf
jeden Fall, was die Portabilität angeht. Schau mal nach, worauf perl
läuft. Und zwar real existierend, nicht nur "Ja da müßtest Du mal den
bsh Souce Code nehmen und mal schauen, ob's klappt".
Helmut Schellong
>
> sche...@t-online.de (Helmut Schellong) writes:
>
> >Michael Staats wrote:
>
> >> DOS Umgebungen gibt es nicht fast überall, sondern fast
> >> nirgendwo.
>
> >DOS-Umgebungen gibt's unter Win3.x, Win95/98, WinNT, OS/2,
> >Linux, SCO-Unix, ...
> >also fast überall.
>
> Das sind alles Programme (Betriebssytem will ich den Win-Kram gar
> nicht nennen), die auf PC Hardware laufen. Es gibt noch mehr auf
> dieser Welt. Ich weiß, daß es auch für andere Maschinen Win Emulatoren
> gibt, aber naturgemäß funktionieren die nur bedingt, und sind vor
> allem grottenlangsam.
Sehr deutlich langsamer sind die Emus (Austr.Straußenvogel)
auf jeden Fall.
Z.B. SCO-Merge (DOS6.22/Win3.x/Win32s/Win95)
nimmt dem Prozessor subjektiv die halbe Kraft weg.
>
> >Wieviel Prozent Marktanteil haben denn wohl die oben
> >aufgeführten Systeme in der Summe?(!)
> >Allein SCO hat unter den PC-Unixen einen Anteil
> >von fast 90 Prozent,
> >und in der gesamten Unix-Welt einen Anteil von 40%.
>
> Wir brauchen das jetzt nicht weiter diskutieren, aber bei diesen
> Rechnern handelt es sich um PCs, also persönliche Rechner. Hier an der
> Uni leben z. B. Tausende von Studi-Accounts auf ein paar
> HP-UX-Kisten. Wie willst Du das zählen?
>
> >Die bsh läuft unter DOS ohne jede Funktionalitätseinbuße
> >wie unter Unix, nur langsamer.
>
> Dann kann sie ja nicht viel können. DOS enthält doch die ein oder
> andere Einschränkung gegenüber Unix, und wenn die auch in der Unix
> Version drin sind, na toll.
Die einzige Einschränkung ist tatsächlich nur das Langsamerlaufen.
Ein Prozeßmanagement hat die DOS-Version allerdings nicht,
das kann man in gewisser Weise mit Taskmanagern des BS machen...
Und bei meiner Unix-Version (bisher nur in meiner Hand)
hab ich (zur Zeit noch) ein wait() nach dem fork().
In den sehr seltenen notwendigen Fällen mache ich halt:
'# bsh script.bsh &'.
Die ganz große Stärke der bsh ist deren enorme
Funktionalitätssumme, die alles andere übertrifft, trotz des
fehlenden Prozeßmanagements.
>
> >Zudem ist die bsh unter DOS absolut konkurrenzlos.
>
> Nun, ich kenne bsh nicht, aber daß sie unter DOS konkurrenzlos ist,
> naja, das ist ja auch nichts so besonderes.
>
> (Nebenbei: Unter AIX wird mit bsh die gute alte bourne shell
> bezeichnet, /bin/sh ist die POSIX shell. Das könnte woanders auch so
> sein, weiß ich aber nicht.)
Ach.
Na ja, 'bsh'==BatchSHell. (==BourneSHell==Tilt)
Und mein 2. Vorname beginnt mit 'B'...
Geschützt sind Dateinamen aber ohnehin nicht...
>
> >Meines Wissens gibt es NUR den bash-Quellkode öffentlich.
>
> Ja, das glaube ich, daß das Deinem Wissen entspricht (SCNR) :-)
>
> Es gibt mindestens noch sh, pdksh, zsh, ash, abgesehen von den
> Nicht-Shell Skript Sprachen perl, sed, awk, tcl, ...
Ich habe selbst auch zsh, tcsh, perl,... aus der SCO-Skunkware
mit Quellkode...
Warum ich nur von bash schrieb, weiß ich selber nich mehr -
- Freud'sche Fehlleistung.
(Mit Verlaub: Freud'sche Fehlleistung NUR hier - bitte!)
>
> >Betreffend die Merkmale
> >Arbeitsgeschwindigkeit, Programmgröße, Ressourcenbedarf,
> >Funktionalität und Portabilität
> >stellt die bsh derzeit den 'Weltrekord' dar.
(Unter allen SHELLS!)
>
> Ich kenne Deine bsh nun nicht, aber ich melde mal Zweifel an. Auf
> jeden Fall, was die Portabilität angeht. Schau mal nach, worauf perl
> läuft. Und zwar real existierend, nicht nur "Ja da müßtest Du mal den
> bsh Souce Code nehmen und mal schauen, ob's klappt".
Das stimmt nun tatsächlich und ist keine platte Angeberei!:
Arbeitsgeschw.: siehe hier in der NG. -->
Programmgröße: dito (um die 100 KB)
Ressourcenbed.: 145 KB bzw. 175 KB Ram (CODE+DATA)
Funktionalität: siehe bsh.mnk, bshmnk.htm, xyz.mnx, xyz.bsh
Portabilität: Kaum mehr als folgende LIB-Funktionen:
open(),close(),read(),write(),fork()/spawn(),
wait(),stat(),dup(),dup2(),putenv(),opendir()[...].
Der Rest ist reines ANSI-C.
Martin Neumann
sche...@t-online.de (Helmut Schellong) writes:
> Die ganz große Stärke der bsh ist deren enorme
> Funktionalitätssumme, die alles andere übertrifft, trotz des
> fehlenden Prozeßmanagements.
Wenn deine Shell kein Prozessmanagement kann, dann kann sie
schon gar nicht alles andere uebertreffen.
In einer Multitasking-Umgebung ist dies einer der essentiellsten
Features.
Anselm Lingnau
Martin Neumann <m...@denise.westfalen.de>:
> Wenn deine Shell kein Prozessmanagement kann, dann kann sie
> schon gar nicht alles andere uebertreffen.
> In einer Multitasking-Umgebung ist dies einer der essentiellsten
> Features.
Es ist schon eine gewisse Macke, sowas nicht zu haben, aber zwingend
erforderlich ist es nicht. Schließlich gibt es xterms, und die Benutzer
von Plan 9 leben auch irgendwie, obwohl rc kein `Prozessmanagement'
anbietet. (Das Konzept eines `Textbildschirms', auf dem man kein neues
Terminalfenster aufmachen kann, existiert unter Plan 9 nicht, so daß das
keinen Nachteil darstellt. Unter Unix gibt es `screen'.)
Daß trotzdem für viele Leute Jobkontrolle ein wichtiges Feature für eine
Shell ist und sie eine Shell, die das nicht anbietet, keines zweiten
Blickes würdigen, steht auf einem anderen Blatt. Unbestritten ist auch,
daß die Implementierung von Jobkontrolle eine Shell nicht gerade
einfacher und übersichtlicher macht.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Oh, yeah. I definitely want a book on solid coding techniques from the folks
who brought us GENERAL PROTECTION ERROR and UNRECOVERABLE APPLICATION ERROR.
-- Billy Chambless
Martin Neumann
Anselm Lingnau <lin...@tm.informatik.uni-frankfurt.de> writes:
>> Wenn deine Shell kein Prozessmanagement kann, dann kann sie
>> schon gar nicht alles andere uebertreffen.
>
> Es ist schon eine gewisse Macke, sowas nicht zu haben, aber zwingend
> erforderlich ist es nicht. Schließlich gibt es xterms
xterms erfordern X11, X11 erfordert relativ viel Speicher, viel Speicher hat
nicht jedes System (embedded Systeme usw.).
Es kann nicht sein, dass ich fuer einen zweiten Job den ich von meiner
Shell starten will, eine zweite Instanz meiner Shell starten muss. Das hat
ganz einfach mit vernuenftiger Resourcen-Nutzung nichts mehr zu tun; auch
wenn grosszuegig Resourcen da sind, muss man die ja nicht verschleudern.
xterms binden den Nutzer an ein GUI-System, jeder Rechner braucht einen
X-Server, nur um mehrere Shell-Jobs parallel ablaufen zu lassen. Das ist
purer Overkill. telnet (oder besser ssh) reicht bei einer jobfaehigen Shell.
> Unbestritten ist auch, daß die Implementierung von Jobkontrolle eine
> Shell nicht gerade einfacher und übersichtlicher macht.
Was verstehst du in diesem fall unter "nicht einfach und unuebersichtlich"?
Helmut Schellong
>
> In article <73cmqb$v4p$3...@news01.btx.dtag.de>,
> sche...@t-online.de (Helmut Schellong) writes:
>
> > Die ganz große Stärke der bsh ist deren enorme
> > Funktionalitätssumme, die alles andere übertrifft, trotz des
> > fehlenden Prozeßmanagements.
>
> schon gar nicht alles andere uebertreffen.
> Features.
Selbstverständlich kann sie das.
Was ist denn das für eine Logik!?
Wenn ein Programm 100 Punkte hat, darunter von 87 bis 96
ein Prozeßmanagement, und ein anderes Programm hat
450 Punkte, darunter jedoch kein Prozeßmanagement,
dann gewinnt nach meiner Logik das letztere Programm.
Bisher kann die bsh das nicht, weil es (hier) ohnehin um
die DOS-Version geht.
Wenn die bsh von Beginn an nur für Unix konzipiert worden
wäre - ja dann hätte sie jetzt gewiß ein PM.
Ich sagte ja, daß die Unix-Version nur in meinen Händen
befindlich ist - und ich hab in 200000 Script-Zeilen
keinen Bedarf für bg-Prozesse gehabt.
Als Ausgleich kann man z.B. 'csh: bsh_script &' geben.
Und weiterhin arbeite ich meistens mit mehrfachem
gleichzeitigem Login (multiscreen), was hinsichtlich
parallelem Arbeiten ohnehin das Beste ist.
Ich hab gerade drei neue Kommandos:
remove, mkdirs, list, und eine automatische
Slash-Korrektur (/ <--> \) hinzugefügt.
Das war mir erneut wichtiger als unter anderem
mal das wait() hinter dem fork() wegzunehmen...!
Michael Staats
>Slash-Korrektur (/ <--> \) hinzugefügt.
a.) Ich hasse Programme, die meinen, schlauer zu sein als ich. Das
Problem ist im Prinzip ohnehin unlösbar. Was soll mit
"copy /b x.txt" passieren? Ein "copy \b x.txt" draus machen? Toll. Oder
"copy \bla.txt"? Unter Unix: "cp /bla blubb" vs. "cp \$jaja huhu"?
Welche slashes erstzt Du denn wo?
b.) Wenn überhaupt, dann \ -> /, denn das geht sogar unter MS-DOS.
Anselm Lingnau
Helmut Schellong <sche...@t-online.de>:
> Wenn ein Programm 100 Punkte hat, darunter von 87 bis 96
> ein Prozeßmanagement, und ein anderes Programm hat
> 450 Punkte, darunter jedoch kein Prozeßmanagement,
> dann gewinnt nach meiner Logik das letztere Programm.
Nach dieser Logik `gewinnt' aber auch ein Auto mit zwölf Zylindern,
Chromzierleisten, einem Schiebedach und Ledersitzen gegen einen
Vierzylinder mit Holzbänkchen und einer Plastikfolie als Verdeck, selbst
wenn das erste Auto keine Räder hat.
Manche Leute haben eben andere Prioritäten. Und unter Unix ist
Jobkontrolle nun mal etwas, was, wenn man es denn haben will, bloß die
Shell vernünftig machen kann. Die allermeisten der Kommandos, die Du
liebe- und mühevoll in Deine Shell einbaust, gibt es unter Unix sowieso
schon als externe Programme, und vielen Unix-Leuten ist es im Grunde
piepegal, ob der Aufruf nun fünf Sekunden länger dauert oder nicht.
(Wenn es wirklich schnell gehen muß, nehmen wir Perl oder gar C.)
Jobkontrolle ist aber vielen Leuten wichtig und läßt sich nur unter
Verrenkungen shell-extern implementieren, so daß viele Leute lieber eine
Shell mit `100 Punkten und Jobkontrolle' haben als eine andere mit `450
Punkten'.
Anselm Lingnau
Martin Neumann <m...@denise.westfalen.de>:
> xterms erfordern X11, X11 erfordert relativ viel Speicher, viel Speicher hat
> nicht jedes System (embedded Systeme usw.).
Auf Embedded-Systemen wirst Du selten in die Verlegenheit kommen, mehr
als eine Shell-Sitzung starten zu müssen.
Es gibt jede Menge Möglichkeiten, auch ohne X mehrere Sitzungen parallel
laufen zu lassen (siehe `screen'). Im übrigen unterstützt auch eine
sehr simple Shell wie rc, die keine Jobkontrolle à la csh oder bash hat,
das Abschicken von Programmen im Hintergrund per `bla &'.
Es geht ja auch nicht darum, daß Jobkontrolle überflüssig ist. Man
sollte sich aber vor Augen führen, daß Unix ca. zehn Jahre lang
existiert hat und populär geworden ist, bevor mit der C-Shell die
Jobkontrolle erfunden wurde. Background-Jobs gab es vorher auch schon,
und ich persönlich würde eine Shell, die keine Background-Jobs anbietet,
unter Unix eigentlich nicht für diskutabel halten (sorry, Helmut).
Andere Leute haben vielleicht andere Prioritäten.
> > Unbestritten ist auch, daß die Implementierung von Jobkontrolle eine
> > Shell nicht gerade einfacher und übersichtlicher macht.
>
> Was verstehst du in diesem fall unter "nicht einfach und unuebersichtlich"?
Vergleich mal die relevanten Teile des Quellcodes von `rc' mit denen der
`bash', und Du wirst schon sehen, was ich meine :^)
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Literature is news that stays news. -- Ezra Pound
Helmut Schellong
>
> Im Artikel <73m3qf$in2$1...@news00.btx.dtag.de> schrieb
> Helmut Schellong <sche...@t-online.de>:
>
> > Wenn ein Programm 100 Punkte hat, darunter von 87 bis 96
> > ein Prozeßmanagement, und ein anderes Programm hat
> > 450 Punkte, darunter jedoch kein Prozeßmanagement,
> > dann gewinnt nach meiner Logik das letztere Programm.
>
> Nach dieser Logik `gewinnt' aber auch ein Auto mit zwölf Zylindern,
> Chromzierleisten, einem Schiebedach und Ledersitzen gegen einen
> Vierzylinder mit Holzbänkchen und einer Plastikfolie als Verdeck, selbst
> wenn das erste Auto keine Räder hat.
Wenn ich das rein quantitativ gemeint hätte (sinnlos überladen),
gäbe ich Dir voll Recht.
Es kommt aber ganz drauf an, wie pauschal bzw. oberflächlich ich das mit
den Punkten gemeint habe!
Die Punkte sind durchaus echte Qualitätspunkte, also Punkte, die durch
Problemlösungskraft erworben wurden!
>
> Manche Leute haben eben andere Prioritäten. Und unter Unix ist
> Jobkontrolle nun mal etwas, was, wenn man es denn haben will, bloß die
> Shell vernünftig machen kann. Die allermeisten der Kommandos, die Du
> liebe- und mühevoll in Deine Shell einbaust, gibt es unter Unix sowieso
> schon als externe Programme, und vielen Unix-Leuten ist es im Grunde
> piepegal, ob der Aufruf nun fünf Sekunden länger dauert oder nicht.
> (Wenn es wirklich schnell gehen muß, nehmen wir Perl oder gar C.)
> Jobkontrolle ist aber vielen Leuten wichtig und läßt sich nur unter
> Verrenkungen shell-extern implementieren, so daß viele Leute lieber eine
> Shell mit `100 Punkten und Jobkontrolle' haben als eine andere mit `450
> Punkten'.
>
Mit diesem Absatz widersprichst Du einigen anderen Stellungnahmen,
die Shells gerade wegen der externen Prozesse schlechtgemacht hatten...
- im Vergleich zu Perl.
Die bsh ist sehr schnell - möglicherweise im Mittel etwa so schnell
wie Perl...
Ich selbst finde es auch nicht gerade toll oder explizit erstrebenswert,
daß die bsh derzeit keinerlei Prozesse im Hintergrund laufen lassen kann.
Zumindest '... &' sollte sie besser können.
*** Aber, eines muß ich erneut erwähnen! ***:
Die bsh entstand ab 1995 unter dem Titel:
"Implementation einer Korn-Shell unter DOS"
........
Deren Verwendung unter mehreren BS mit ein und denselben Scripts (!!!)
ist mir wichtig!
Helmut Schellong
>
> sche...@t-online.de (Helmut Schellong) writes:
>
> >Slash-Korrektur (/ <--> \) hinzugefügt.
>
> a.) Ich hasse Programme, die meinen, schlauer zu sein als ich. Das
Ich auch!
> Problem ist im Prinzip ohnehin unlösbar. Was soll mit
> "copy /b x.txt" passieren? Ein "copy \b x.txt" draus machen? Toll. Oder
> "copy \bla.txt"? Unter Unix: "cp /bla blubb" vs. "cp \$jaja huhu"?
> Welche slashes erstzt Du denn wo?
Ich ersetze unter DOS / durch \, unter Unix umgekehrt.
ABER: Nur an denjenigen Stellen, wo eindeutig ein Pfadname an eine
Systemfunktion übergeben wird ! ! !
Z.B.: fd= open(path, ...);
Bei
externen Kommandos,
'extern kdo arg...' und
'system kdo arg...' (explizit & implizit)
bleiben alle Argumente unbehandelt!
Da man externe Kommandos in der bsh kaum braucht, sind die Scripts
damit noch portabler bzw. leichter portabel zu machen.
> b.) Wenn überhaupt, dann \ -> /, denn das geht sogar unter MS-DOS.
Wie bitte!?
C:\> help label
Innerhalb von label-Namen nicht erlaubt:
* ? / \ | . , ; : + = [ ] ( ) & ^ < > "
erlaubt:
! # $ % ' - @ _ ` { } ~
. Space (Dateinamen dazu)
\ (Pfadnamen dazu)
(Wenn doch, dann wäre das aber problematisch: KDO/option, etc.)
Helmut Schellong
>
> Manche Leute haben eben andere Prioritäten. Und unter Unix ist
> Jobkontrolle nun mal etwas, was, wenn man es denn haben will, bloß die
> Shell vernünftig machen kann.
> Jobkontrolle ist aber vielen Leuten wichtig und läßt sich nur unter
Nachsatz
--------
Das Parallel-Processing unter Unix ist im wesentlichen vorteilhaft
durch dessen intensive Verwendung vom Betriebssystem selbst
und vom BS bereitgestellte Multiscreen-Einrichtungen etc.!
Kommandos (Kommandozeile oder Script) im Hintergrund laufen zu lassen
(kdo ... ... &) ist demgegenüber von geringerer Bedeutung.
Begründungen:
1.) Fast immer kann man das NICHT machen, weil jedes Kommando
auf die vollständige Beendigung der Arbeit des vorausgehenden
Kommandos unbedingt angewiesen ist!
2.) Kandidaten sind ohnehin nur nichtinteraktive Kommandos.
Viele potentiell geeignete Kandidaten würden sich jedoch
eine 50:50-CPU-Konkurrenz liefern - was nix bringt.
3.) Paralleles Arbeiten kostet zusätzlich verwaltende CPU-Zeit!
4.) Geeignet als bg-Kommando sind vornehmlich Kommandos,
die häufig 'schlafen', also z.B. an einer read(), write()
oder sleep()-Funktion oft und lange festhängen.
Zum Beispiel:
Kopiere Datei1 --> FloppyDriveA &
set CLD=$child
Kopiere Datei2 --> FloppyDriveB
wait #CLD
Das bringt (nur) etwa 1,5-fache Geschwindigkeit.
Als bg sinnvoll, weil die Drives so langsam sind.
Man achte auf das 'wait': das Script kann erst
weitermachen, wenn die Aktionen fertig(!) sind.
5.) Die obigen Script-Zeilen könnte ich auch per echo
aus der bsh heraus zur Eingabe einer csh pipen, die bg kann.
Das ist (wegen der Seltenheit) kein sonderliches Problem.
6.) Folgende Keywords aus PEARL machen deutlich, daß Multitasking
professionell betrieben viel Aufmerksamkeit erfordert:
TASK PRIORITY SPECIFY INTERRUPT ACTIVATE
AT AFTER WHEN EVERY ALL UNTIL DURING USING sema
TERMINATE SUSPEND CONTINUE AT AFTER WHEN
RESUME PREVENT SEMA REQUEST sema RELEASE sema
PRESET RESERVE BOLT FREE ENTER LEAVE bolt
Das waren *nur* Multitasking-Keywords!
7.) Ich bin durchaus sehr erfahren in Multitasking,
auf verschiedenen Gebieten, z.B. MikroKontroller.
Wenn die bsh das noch nicht bietet, dann vielleicht
auch gerade deshalb...
Michael Staats
>Ich ersetze unter DOS / durch \, unter Unix umgekehrt.
Folge: Unter Unix kann ich Dateien wie z. B. "jaja\huhu" nicht mehr
ansprechen. Na super.
>ABER: Nur an denjenigen Stellen, wo eindeutig ein Pfadname an eine
>Systemfunktion übergeben wird ! ! !
> Z.B.: fd= open(path, ...);
>Bei
> externen Kommandos,
> 'extern kdo arg...' und
> 'system kdo arg...' (explizit & implizit)
>bleiben alle Argumente unbehandelt!
Das heißt, es ist auch noch inkonsistent, je nach dem ob ich ein
internes oder externes Kommando aufrufe. Na super.
>> b.) Wenn überhaupt, dann \ -> /, denn das geht sogar unter MS-DOS.
>Wie bitte!?
>C:\> help label
>Innerhalb von label-Namen nicht erlaubt:
> * ? / \ | . , ; : + = [ ] ( ) & ^ < > "
Eben. Deshalb funktioniert unter DOS ja auch / als Pfadseparator,
weils in Dateinamen nicht erlaubt ist. Wohlgemerkt: Unter DOS, nicht
in dem mitgelieferten Kommandointerpreter namens command.com.
Martin Neumann
sche...@t-online.de (Helmut Schellong) writes:
> 1.) Fast immer kann man das NICHT machen, weil jedes Kommando
> auf die vollständige Beendigung der Arbeit des vorausgehenden
> Kommandos unbedingt angewiesen ist!
Ja und? Dann schickt man die aufeinander angewiesesenen Kommandos
allesamt in den Hintergund, etwa so
{ foo ; batz ; butz ;} &
> 2.) Kandidaten sind ohnehin nur nichtinteraktive Kommandos.
> Viele potentiell geeignete Kandidaten würden sich jedoch
> eine 50:50-CPU-Konkurrenz liefern - was nix bringt.
Doch, ich muss nicht warten, bis der eine Prozess fertig ist und
dann auf irgendeine Taste druecken um den neuen Prozess zu starten.
Und wenn mich die gleichzeitige CPU-Nutzung aus irgendeinem Grunde
trotzdem stoeren sollte, so schicke ich sie als "{ p1 ; p2 ;} &" los
und muss trotzdem nicht aehnlich einem pavlowschen Aeffchen auf das
Ende des einen Prozesses warten und dann den naechsten starten.
> 3.) Paralleles Arbeiten kostet zusätzlich verwaltende CPU-Zeit!
... und nutzt die CPU idealer aus. Sagen wir, du startest Prozess
A und wartest bis er endet und startest dann Prozess B. Wenn zwischen
dem Ende von Prozess A und dem Starten von B ein, zwei Sekunden
vergehen, dann hat die CPU wahrscheinlich laenger Daeumchen gedreht,
als der Verwaltungsaufwand gewesen waere.
> 4.) Geeignet als bg-Kommando sind vornehmlich Kommandos,
> die häufig 'schlafen', also z.B. an einer read(), write()
> oder sleep()-Funktion oft und lange festhängen.
Nein, ich sehe keinen Grund, warum man I/O-intensive Prozesse nicht
in den Background schicken sollte.
> 5.) Die obigen Script-Zeilen könnte ich auch per echo
> aus der bsh heraus zur Eingabe einer csh pipen, die bg kann.
> Das ist (wegen der Seltenheit) kein sonderliches Problem.
Dann hat man erstens zwei Prozesse statt einem und zweitens ist das
nicht selten.
> 6.) Folgende Keywords aus PEARL machen deutlich, daß Multitasking
> professionell betrieben viel Aufmerksamkeit erfordert:
> TASK PRIORITY SPECIFY INTERRUPT ACTIVATE
> AT AFTER WHEN EVERY ALL UNTIL DURING USING sema
> TERMINATE SUSPEND CONTINUE AT AFTER WHEN
> RESUME PREVENT SEMA REQUEST sema RELEASE sema
> PRESET RESERVE BOLT FREE ENTER LEAVE bolt
> Das waren *nur* Multitasking-Keywords!
Die Sprache heisst Perl. Willst du mir jetzt auch noch sagen, dass
Multitasking per se eine doofe, umstaendliche Sache ist?
> 7.) Ich bin durchaus sehr erfahren in Multitasking,
> auf verschiedenen Gebieten, z.B. MikroKontroller.
> Wenn die bsh das noch nicht bietet, dann vielleicht
> auch gerade deshalb...
Ach, du willst deine Shell auf einen Mikrokontroller portieren?
Anselm Lingnau
Helmut Schellong <sche...@t-online.de>:
> Mit diesem Absatz widersprichst Du einigen anderen Stellungnahmen,
> die Shells gerade wegen der externen Prozesse schlechtgemacht hatten...
Man darf das nicht so schwarzweiß sehen. Das Teure ist ja in vielen
Fällen nicht die Rechenzeit auf dem Computer, sondern die Denkzeit der
Leute, die ihn programmieren. Wenn man die paar hundert Dienstprogramme,
die ein typisches Unix mitbringt und von denen viele als Bausteine für
Shellskripten gedacht sind (weil das, was sie tun, so trivial ist, daß
man mit ihnen sonst nicht viel anfangen kann, zum Beispiel `uniq'), alle
in die Shell einbauen wollte, dann hätte man eine Menge zu tun und das
Resultat wäre recht groß und unhandlich. Statt dessen macht man den
Kompromiß, sie als externe Prozesse laufen zu lassen, was zwar
prinzipiell langsamer ist, aber heute auch keinen so großen Unterschied
mehr macht. (Außerdem kann man dann mehr als eine Shell haben ... und es
soll zum Beispiel tatsächlich Leute geben, die die C-Shell mögen :^)).
Daß man für viele Sachen in einer Sprache wie Perl sowieso gegenüber
den gängigen Shells uneinholbar viel schneller ist, wenn man sich
nicht gerade ziemlich dumm anstellt, steht auf einem anderen Blatt.
Aber auch in Perl-Programmen kann es sich lohnen, Aufgaben gezielt
an externe Programme zu delegieren. Ein gezieltes `who' oder `ps'
ist im Zweifelsfalle einfacher, als sich die Daten `zu Fuß' in Perl
zu verschaffen.
Das Grundprinzip ist immer, ein Programm erst mal zum Laufen zu bringen
und dann zu schauen, wo man es schneller machen kann (falls nötig). Wenn
ich eine Stunde über ein Programm nachdenke, ist es egal, ob es zum
Ablauf zehn Sekunden oder zwei Minuten braucht -- das fällt dann im
Vergleich zu der Zeit, die ich schon aufgewendet habe, nicht mehr ins
Gewicht. Wenn es allerdings zwei Minuten braucht und ich drei Tage
Arbeit reinstecken müßte, um es auf zehn Sekunden runterzubringen, muß
man schon überlegen, ob die zusätzliche Mühe sich lohnt, und dabei
Faktoren betrachten wie den, wie oft das Programm laufen muß usw. Das
gilt natürlich für Programme in jeder Sprache.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Dance is the hidden language of the soul, of the body. -- Martha Graham
Anselm Lingnau
Helmut Schellong <sche...@t-online.de>:
> Kommandos (Kommandozeile oder Script) im Hintergrund laufen zu lassen
> (kdo ... ... &) ist demgegenüber von geringerer Bedeutung.
> Begründungen:
> 1.) Fast immer kann man das NICHT machen, weil jedes Kommando
> auf die vollständige Beendigung der Arbeit des vorausgehenden
> Kommandos unbedingt angewiesen ist!
Wir müssen wohl mal ein paar grundlegende Begriffe klären.
`Jobkontrolle' bei einer Shell ist ein bißchen mehr als nur Prozesse mit
`&' in den Hintergrund zu schicken. Dazu zählen nämlich Kommandos wie
`bg', `fg' und `Control-Z'. Mit der Jobkontrolle ist es im Prinzip
möglich, auf demselben Terminal mehrere Sitzungen parallel
laufenzulassen (auch wenn das im Zeitalter von X11 nicht mehr so
dringend nötig ist, ist es in manchen Situationen hilfreich und auf
jeden Fall nett zu haben, wenn man's sich leisten kann). Als
Jobkontrolle neu war, war es durchaus nicht falsch, zum Beispiel einen
Editor für eine Weile per Jobkontrolle zu suspendieren, um `außerhalb'
desselben etwas anderes zu erledigen, und dann an denselben Punkt
zurückzukehren, wo man aufgehört hatte. (Der GNU Emacs war damals
noch nicht erfunden.) Oder man hatte einen Prozeß angestoßen, der
dann doch länger brauchte, als gedacht -- mit Control-Z und `bg' läuft
er im Hintergrund weiter, und das Terminal ist wieder frei. Wenn
man nur `&' zur Verfügung hat, muß man sich am Anfang entscheiden,
ob der Prozeß im Vorder- oder Hintergrund laufen soll, und kann das
dann nicht mehr revidieren.
Was `&' angeht, so gibt es eine Menge Aufgaben, die man profitabel
und nichtinteraktiv im Hintergrund erledigen kann. Dann hat der
Computer auch was zu tun, wenn er sonst dumm dasitzen und darauf
warten würde, daß Du im Editor die nächste Taste drückst.
> 6.) Folgende Keywords aus PEARL machen deutlich, daß Multitasking
> professionell betrieben viel Aufmerksamkeit erfordert:
Naja, PEARL ist ja auch eine Sprache, mit der man Roboter steuert und
solche Sachen. Dafür ist Unix sowieso eigentlich nicht gedacht. Die
Sorte Multitasking, die es bequem macht, unter Unix zu arbeiten, braucht
meistens keine so ausgefeilten Kontrollmöglichkeiten -- mit `fork()',
`pipe()', `dup()' und `wait()' kann man auch schon recht hohe Sprünge
machen.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Emacs can do anything ... just ask it. -- Rob Pike
Anselm Lingnau
Helmut Schellong <sche...@t-online.de>:
> (Wenn doch, dann wäre das aber problematisch: KDO/option, etc.)
Die DOS-Systemaufrufe verstehen `/' durchaus im Unix-Sinn. Nur
COMMAND.COM kann das nicht (ohne weiteres).
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
The purpose of a university is to provide sex for the students, athletics for
the alumni, and parking for the professors. -- Clark Kerr (attr.)
Helmut Schellong
>
> In article <7430t7$dvt$1...@news02.btx.dtag.de>,
> sche...@t-online.de (Helmut Schellong) writes:
>
> > auf die vollständige Beendigung der Arbeit des vorausgehenden
> > Kommandos unbedingt angewiesen ist!
>
> allesamt in den Hintergund, etwa so
>
> { foo ; batz ; butz ;} &
>
> > 2.) Kandidaten sind ohnehin nur nichtinteraktive Kommandos.
> > Viele potentiell geeignete Kandidaten würden sich jedoch
> > eine 50:50-CPU-Konkurrenz liefern - was nix bringt.
>
> Doch, ich muss nicht warten, bis der eine Prozess fertig ist und
> dann auf irgendeine Taste druecken um den neuen Prozess zu starten.
Du argumentierst mit einer ganz anderen Zielsetzung!
Ja, wenn man "{ a;b;c; } &" gibt, erhält man ein Prompt, nach
Enter-Taste, um sogleich weitere Eingaben vornehmen zu können.
Und nach jeder eventuellen Ausgabe eines der Kommandos ist
das Prompt erstmal wieder weg.
Nur, mehr Performance erhält die Kommando-Folge dadurch nicht,
worum es mir aber eigentlich geht.
>
> Und wenn mich die gleichzeitige CPU-Nutzung aus irgendeinem Grunde
> trotzdem stoeren sollte, so schicke ich sie als "{ p1 ; p2 ;} &" los
> und muss trotzdem nicht aehnlich einem pavlowschen Aeffchen auf das
> Ende des einen Prozesses warten und dann den naechsten starten.
>
> > 3.) Paralleles Arbeiten kostet zusätzlich verwaltende CPU-Zeit!
>
> ... und nutzt die CPU idealer aus. Sagen wir, du startest Prozess
> A und wartest bis er endet und startest dann Prozess B. Wenn zwischen
> dem Ende von Prozess A und dem Starten von B ein, zwei Sekunden
> vergehen, dann hat die CPU wahrscheinlich laenger Daeumchen gedreht,
> als der Verwaltungsaufwand gewesen waere.
Es ist ohnehin eine Binsenweisheit, daß die CPU mit einem User
am Keyboard nur etwa 1% mittlere Auslastung hat.
Den csh-Script-Auszug gab ich aus diesem Grunde.
>
> > 4.) Geeignet als bg-Kommando sind vornehmlich Kommandos,
> > die häufig 'schlafen', also z.B. an einer read(), write()
> > oder sleep()-Funktion oft und lange festhängen.
>
> Nein, ich sehe keinen Grund, warum man I/O-intensive Prozesse nicht
> in den Background schicken sollte.
Das hab ich nicht bestritten! (Leseirrtum?)
>
> > 5.) Die obigen Script-Zeilen könnte ich auch per echo
> > aus der bsh heraus zur Eingabe einer csh pipen, die bg kann.
> > Das ist (wegen der Seltenheit) kein sonderliches Problem.
>
> Dann hat man erstens zwei Prozesse statt einem und zweitens ist das
> nicht selten.
JEDES fork() führt ohnehin zu einer weiteren Prozeßkopie.
Und bei mir IST es selten, daß sich bg-Kommandos aus Effizienzgründen
lohnen! (Kommandozeile oder im Script)
>
> > 6.) Folgende Keywords aus PEARL machen deutlich, daß Multitasking
> > professionell betrieben viel Aufmerksamkeit erfordert:
> > TASK PRIORITY SPECIFY INTERRUPT ACTIVATE
> > AT AFTER WHEN EVERY ALL UNTIL DURING USING sema
> > TERMINATE SUSPEND CONTINUE AT AFTER WHEN
> > RESUME PREVENT SEMA REQUEST sema RELEASE sema
> > PRESET RESERVE BOLT FREE ENTER LEAVE bolt
> > Das waren *nur* Multitasking-Keywords!
>
> Die Sprache heisst Perl. Willst du mir jetzt auch noch sagen, dass
> Multitasking per se eine doofe, umstaendliche Sache ist?
Nein, ich arbeite sehr gerne unter Unix - gerade und ausdrücklich
wegen des dort vorhandenen preempt. Multitasking.
Nein, die Sprache heißt PEARL ==
"Process and Experiment Automation Realtime Language"
Mit-Erfinder: Werum/Windauer
Gesellschaft für Kernforschung, Karlsruhe, 1977
PEARL wird gelehrt, wenn werdende E-Ingenieure die Fachrichtung
"Informationsverarbeitung" wählen.
>
> > 7.) Ich bin durchaus sehr erfahren in Multitasking,
> > auf verschiedenen Gebieten, z.B. MikroKontroller.
> > Wenn die bsh das noch nicht bietet, dann vielleicht
> > auch gerade deshalb...
>
> Ach, du wilst deine Shell auf einen Mikrokontroller portieren?
Nein.
Ich kenne mich aber mit parallel laufenden MC-Funktionen
und deren Synchronisation... aus.
Helmut Schellong
>
> sche...@t-online.de (Helmut Schellong) writes:
>
> >Ich ersetze unter DOS / durch \, unter Unix umgekehrt.
>
> Folge: Unter Unix kann ich Dateien wie z. B. "jaja\huhu" nicht mehr
> ansprechen. Na super.
Erstens habe ich *unter Unix* dieses Feature derzeit deaktiviert.
Ich kann es per "#define ..." jederzeit einschalten.
Es geht mir hauptsächlich darum, daß Scripts unter DOS auch
mit "/" laufen.
Daß die Funktion automatisch in die jeweils andere 'Richtung'
umsetzt, ist nun mal so.
Zweitens habe ich bei insgesamt 100000 oder mehr Dateien unter
Unix noch NIEMALS einen "\" im Dateinamen gesehen!
Wer macht denn sowas?!
>
> >ABER: Nur an denjenigen Stellen, wo eindeutig ein Pfadname an eine
> >Systemfunktion übergeben wird ! ! !
> > Z.B.: fd= open(path, ...);
> >Bei
> > externen Kommandos,
> > 'extern kdo arg...' und
> > 'system kdo arg...' (explizit & implizit)
> >bleiben alle Argumente unbehandelt!
>
> Das heißt, es ist auch noch inkonsistent, je nach dem ob ich ein
> internes oder externes Kommando aufrufe. Na super.
Was soll denn dieser Quatsch?!
Wenn ich ein Script habe, das keinerlei externe Kommandos
aufruft -und das sind fast alle!- ist ein solches Script
eben ohne die geringste Aenderung portabel!
Das ist doch ein Vorteil!
Die bsh hat nun mal so viele Dinge intern, daß man in der Regel
NUR 'bsh(.exe)' braucht!
Das wird auch noch ausgeweitet.
Das ist eine DER Stärken der 'bsh'!
>
> >> b.) Wenn überhaupt, dann \ -> /, denn das geht sogar unter MS-DOS.
>
> >Wie bitte!?
> >C:\> help label
>
> >Innerhalb von label-Namen nicht erlaubt:
>
> > * ? / \ | . , ; : + = [ ] ( ) & ^ < > "
>
> Eben. Deshalb funktioniert unter DOS ja auch / als Pfadseparator,
> weils in Dateinamen nicht erlaubt ist. Wohlgemerkt: Unter DOS, nicht
> in dem mitgelieferten Kommandointerpreter namens command.com.
Hää, wie soll man denn ohne command.com unter DOS arbeiten?!
Auch System-Funktionen weisen "/" zurück!
Helmut Schellong
>
> Im Artikel <73vjil$lqh$1...@news00.btx.dtag.de> schrieb
> Helmut Schellong <sche...@t-online.de>:
>
> > Mit diesem Absatz widersprichst Du einigen anderen Stellungnahmen,
> > die Shells gerade wegen der externen Prozesse schlechtgemacht hatten...
>
> Man darf das nicht so schwarzweiß sehen. Das Teure ist ja in vielen
> Fällen nicht die Rechenzeit auf dem Computer, sondern die Denkzeit der
> Leute, die ihn programmieren. Wenn man die paar hundert Dienstprogramme,
> die ein typisches Unix mitbringt und von denen viele als Bausteine für
> Shellskripten gedacht sind (weil das, was sie tun, so trivial ist, daß
> man mit ihnen sonst nicht viel anfangen kann, zum Beispiel `uniq'), alle
> in die Shell einbauen wollte, dann hätte man eine Menge zu tun und das
> Resultat wäre recht groß und unhandlich. Statt dessen macht man den
> Kompromiß, sie als externe Prozesse laufen zu lassen, was zwar
> prinzipiell langsamer ist, aber heute auch keinen so großen Unterschied
> mehr macht. (Außerdem kann man dann mehr als eine Shell haben ... und es
> soll zum Beispiel tatsächlich Leute geben, die die C-Shell mögen :^)).
Mir gefiel die csh auch nur bei der interaktiven Arbeit in der
Kommandozeile gegenüber der sh besser.
csh ist bei den Maskierungen (Zeichen mit Spezialbedeutung)
reichlich experimental.
Den KdoZ-Editor der ksh finde ich irgendwie doof - leider, denn die
ksh ist ansonsten die beste Standard-Shell, und das SCO-Exemplar
ist sau-schnell.
Den KdoZ-Editor der bsh -ein erweiterter doskey- finde ich jedoch
am allerbesten.
Ich muß sagen, mit 'doskey' hat MS was sehr praktisches gebracht...
>
> Daß man für viele Sachen in einer Sprache wie Perl sowieso gegenüber
> den gängigen Shells uneinholbar viel schneller ist, wenn man sich
> nicht gerade ziemlich dumm anstellt, steht auf einem anderen Blatt.
> Aber auch in Perl-Programmen kann es sich lohnen, Aufgaben gezielt
> an externe Programme zu delegieren. Ein gezieltes `who' oder `ps'
> ist im Zweifelsfalle einfacher, als sich die Daten `zu Fuß' in Perl
> zu verschaffen.
>
> Das Grundprinzip ist immer, ein Programm erst mal zum Laufen zu bringen
> und dann zu schauen, wo man es schneller machen kann (falls nötig). Wenn
> ich eine Stunde über ein Programm nachdenke, ist es egal, ob es zum
> Ablauf zehn Sekunden oder zwei Minuten braucht -- das fällt dann im
> Vergleich zu der Zeit, die ich schon aufgewendet habe, nicht mehr ins
> Gewicht. Wenn es allerdings zwei Minuten braucht und ich drei Tage
> Arbeit reinstecken müßte, um es auf zehn Sekunden runterzubringen, muß
> man schon überlegen, ob die zusätzliche Mühe sich lohnt, und dabei
> Faktoren betrachten wie den, wie oft das Programm laufen muß usw. Das
> gilt natürlich für Programme in jeder Sprache.
>
Diesem Beitrag kann ich nahezu in Vollkommenheit zustimmen.
Das Konzept beispielsweise der bsh unterliegt diesen 'gesunden'
Kompromissen.
Einerseits wird dem BS was aufoktroyiert (4 TmpFiles), andererseits
enthält die bsh eine sorgfältig ausgesuchte Sammlung an Internals,
die sie in erster Linie *unabhängig und portabel* macht.
Daß jedoch ein internes Kommando der bsh im Mittel nur 500 Byte
CODE belegt, ist schon weit überdurchschnittlich kompakt und schnell.
...
Michael Staats
>Daß die Funktion automatisch in die jeweils andere 'Richtung'
>umsetzt, ist nun mal so.
Weil Du sie so geschrieben hast, richtig. Und mich, sollte ich jemal
die shell benutzen, daran hindert, eine Datei "ccc\bla" zu nennen.
>Zweitens habe ich bei insgesamt 100000 oder mehr Dateien unter
>Unix noch NIEMALS einen "\" im Dateinamen gesehen!
>Wer macht denn sowas?!
Solche Dateien können immer wieder mal durch falsches copy&paste,
ausgetickte Modem-Verbindungen etc. entstehen. Und wenn solche
Dateinamen halbintelligent geändert werden, kann ich sie nicht mal
löschen.
"Wer macht denn sowas" ist genau die Frage, die sich Mickeysoft
Programmierer jeden Tag stellen, mit ihrer eingeschränkten Phantasie
keine Antwort finden und Krüppelsoftware abliefern.
Ich werde jedenfalls keine shell verwenden, die die Zahl der nicht
erlaubten Zeichen in Dateinamen um den Faktor 1.5 erhöht.
>> Das heißt, es ist auch noch inkonsistent, je nach dem ob ich ein
>> internes oder externes Kommando aufrufe. Na super.
>Was soll denn dieser Quatsch?!
Quatsch? Ich finde es nett, wenn ich z. B.
test "$a" = "$b"
unabhängig davon, ob test jetzt intern oder extern ist, tippen
kann. Wenn das bei Dir je nach dem, ob extern oder intern was anderes
macht, dann ist das inkonsistent.
[ ... ]
>Hää, wie soll man denn ohne command.com unter DOS arbeiten?!
Wie bitte? Ich denke, wir reden hier über den supergeilen
ich-kann-alles-besser shell Ersatz. Wofür brauche ich denn dann noch
command.com? command.com ist doch das erste, was man durch was
besseres ersetzt.
Tschüß,
Michael
René Scholz
>> >> b.) Wenn überhaupt, dann \ -> /, denn das geht sogar unter MS-DOS.
>> Eben. Deshalb funktioniert unter DOS ja auch / als Pfadseparator,
>> weils in Dateinamen nicht erlaubt ist. Wohlgemerkt: Unter DOS, nicht
>> in dem mitgelieferten Kommandointerpreter namens command.com.
>
>Hää, wie soll man denn ohne command.com unter DOS arbeiten?!
Deine DOS-Kenntnisse erschöpfen sich wohl in C:\help ?
Ich benutze seit vielen Jahren eine Shell names DCOM (leider läuft die unter
nwdos nicht als root-shell), mit Superuser, Usern, Passwörtern u.ä.
command.com erscheint dagegen als eine Art rsh (reduced shell).
>Auch System-Funktionen weisen "/" zurück!
Es ex. ein Syscall (DOS-int), durch den sich das Parameterzeichen ändern
läßt.
Siehe auch PC-Intern oder den guten alten Peter Norten.
rené
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren" (Benjamin Franklin)
==> Voland @IRC <== 2048/0xF11D6871 2A8D 3F92 4EB8 E55C 3605 D571 38C8 E2B8
m...@informatik.uni-jena.de http://www.thur.de/~Voland/
Helmut Schellong
>
> sche...@t-online.de (Helmut Schellong) writes:
>
> >Daß die Funktion automatisch in die jeweils andere 'Richtung'
> >umsetzt, ist nun mal so.
>
> Weil Du sie so geschrieben hast, richtig. Und mich, sollte ich jemal
> die shell benutzen, daran hindert, eine Datei "ccc\bla" zu nennen.
>
> >Zweitens habe ich bei insgesamt 100000 oder mehr Dateien unter
> >Unix noch NIEMALS einen "\" im Dateinamen gesehen!
> >Wer macht denn sowas?!
>
> Solche Dateien können immer wieder mal durch falsches copy&paste,
> ausgetickte Modem-Verbindungen etc. entstehen. Und wenn solche
> Dateinamen halbintelligent geändert werden, kann ich sie nicht mal
> löschen.
Doch!
Ganz einfach: rm dat\\ei
Ich sagte doch, daß bei ext keine Umwandlung stattfindet.
Ich komm doch an die open()-Funktion von /bin/rm gar nicht ran!
Außerdem hatte die bsh bis vor kurzem kein internes Löschkommando,
das habe ich nur hinzugefügt, damit man nicht:
[ $T == / ] && rm $datei
[ $T == \ ] && DEL $datei
geben muß, um ein portables Script herzustellen.
>
> "Wer macht denn sowas" ist genau die Frage, die sich Mickeysoft
> Programmierer jeden Tag stellen, mit ihrer eingeschränkten Phantasie
> keine Antwort finden und Krüppelsoftware abliefern.
>
> Ich werde jedenfalls keine shell verwenden, die die Zahl der nicht
> erlaubten Zeichen in Dateinamen um den Faktor 1.5 erhöht.
Dieser Punkt ist ja okay!
Ich sagte doch, daß ich das bei der Unix-Version nicht aktiviert
habe, weil ich weiß, daß dort 254 Zeichen erlaubt sind - nur
'/' und '\0' gehen nicht...
Desweiteren befindet sich bisher KEINE Unix-Variante der bsh
in anderen H„nden als meinen!
Insofern ist das doch ohnehin theoretisch!
>
> >> Das heißt, es ist auch noch inkonsistent, je nach dem ob ich ein
> >> internes oder externes Kommando aufrufe. Na super.
>
> >Was soll denn dieser Quatsch?!
>
> Quatsch? Ich finde es nett, wenn ich z. B.
> test "$a" = "$b"
> unabhängig davon, ob test jetzt intern oder extern ist, tippen
> kann. Wenn das bei Dir je nach dem, ob extern oder intern was anderes
> macht, dann ist das inkonsistent.
He, he, he - falsch verstanden!
Bei diesem Beispiel wird überhaupt nix umgewandelt!
Hier werden zwei Zeichenketten: memcmp_F(a, b, l) zugeführt,
hier ist kein Anlaß für eine Umwandlung!
Umwandlung nur bei:
> aaa/bbb/ccc
[ -s aaa/bbb/ccc ] || ...
grep ... aaa/bbb/ccc
etc.
Dies sind nun mal interne Kommandos, die Vorrang(!) haben.
Externe muß man so aufrufen:
/bin/test
/usr/bin/grep
extern grep aaa\bbb\ccc
Grep (unter DOS)
etc.
Bisher mußte ich so machen:
T=/
[ `ver s` == dos ] && T=\
...
> aaa${T}bbb${T}ccc
bei portablen Scripts.
Ja, merkt denn keiner, daß das doch konsistent ist?!
Die Variable T muß nur noch bei 'extern' verwendet werden;
ein Script nur mit 'intern' ist trotz '/' unter DOS lauffähig,
auch bei Eingaben, ohne irgendwelche Aenderung!
Umwandlung NUR bei:
CvSlash(path); DelSlash(path);
open(char *path, ...);
stat(char *path, &St);
etc.
innerhalb der bsh - und NUR bei der DOS-Version.
Der Operator '=' ist obsolet, neu ist '=='.
> >Hää, wie soll man denn ohne command.com unter DOS arbeiten?!
>
> Wie bitte? Ich denke, wir reden hier über den supergeilen
> ich-kann-alles-besser shell Ersatz. Wofür brauche ich denn dann noch
> command.com? command.com ist doch das erste, was man durch was
> besseres ersetzt.
Das war halt ein Mißverständnis, an Alternativ-Startup-Shells
hatte ich hierbei nicht gedacht...
Die bsh kann ich zwar unter Unix als Login-Shell verwenden,
aber sie ist grundsätzlich nicht als solche von vornherein
konzipiert worden, weil sie zu Anfang eine nichtinteraktive
Script-Maschine sein sollte.
command.com belegt unter DOS nur einige wenige KByte im
Basisspeicher!
Die bsh würde als DOS-Start-Shell wohl nicht laufen - wozu auch,
es spielt doch keine Rolle, ob sich command.com in's HMA/UMB
gelegt hat oder nicht.
Die bsh wßre mir zu unportabel bzw. zu stark unterschiedlich
geworden, was ich nicht wollte.
Anwender der bsh haben die Scripts mit der Endung .bsh unter
Windows 'bsh.exe' zugeordnet und brauchen nur einen
Doppelklick auf so ein Script machen.
Die würden das zumeist gar nicht wollen, ihren command.com
mattsetzen und gegen die bsh (als root-Shell) austauschen...
Ich hab die bsh so konzipiert, daß jedes komplett großgeschriebene
Kommando (z.B. DIR) an die Funktion system("DIR"); übergeben
wird, so daß die Original-Shell (COMSPEC) damit gestartet wird.
Unter Unix: 'system type cmdname', falls $SHELL==/bin/sh .
'system dir' geht unter DOS natürlich auch.
Dies ist nötig, da DIR command.com-intern ist.
Die anderen Shells will ich also durchaus auch nutzen.
Wenn ich zur Zeit die bsh um 'klassische' Kommandos erweitere,
dann deshalb, damit Scripts weniger oder keine
Portabilitäts-Schalter brauchen.
Ein internes Kommando funktioniert nämlich überall gleich.
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> wrote:
> >Hää, wie soll man denn ohne command.com unter DOS arbeiten?!
>
Nein, nun sei mal nich so gehässig.
Ich habe durchaus eine 'System-Reference' zu DOS,
und hab sie gelesen und voll verstanden...
>
> Ich benutze seit vielen Jahren eine Shell names DCOM (leider läuft die unter
> nwdos nicht als root-shell), mit Superuser, Usern, Passwörtern u.ä.
> command.com erscheint dagegen als eine Art rsh (reduced shell).
>
> >Auch System-Funktionen weisen "/" zurück!
> Es ex. ein Syscall (DOS-int), durch den sich das Parameterzeichen ändern
> läßt.
> Siehe auch PC-Intern oder den guten alten Peter Norten.
>
Das ist in diesem Zusammenhang aber kein Gegenargument!
Wäre auch ziemlich 'abenteuerlich', sowas zu schalten.
Desweiteren akzeptiere ich derartig systemspezifische Dinge
in Verbindung mit der bsh keinesfalls!
Es ärgert mich schon genug, daß ich gerade die Funktion
_dos_setfileattr() einbinden mußte, um das externe
'attrib.exe' vermeiden zu können!
Mit chmod() kann man's leider nicht erledigen.