Empfehlung fuer Literatur zur shell-Programmierung?
Framstag
Was gibts denn an empfehlenswerter Literatur (Buch oder auch nur Text-File)
zur csh-Programmierung?
Ich hab zwar schon diverse Unix-Lehrbuecher durchgeblaettert, aber dieses
Thema wird immer nur kurz gestreift und es sind mir auch viel zuwenige
Beispiele drin (das trifft auch fuer die man-page zu).
Es sollte schon wesentlich mehr sein, als nur ein Referenzwerk.
Bitte nicht als Antwort: "shell-Programmierung ist nur was fuer Arme, nimm
ne richtige (Compiler-) Sprache!"
/---Ulli Horlacher---Rechenzentrum Uni Ulm---Oberer Eselsberg---7900 Ulm---\
\ ora...@dulruu51.bitnet | ora...@rz.uni-ulm.de | fram...@uni-ulm.de /
\------------------------------------------------------------------------/
| "Diesen Knackarsch zu verhuellen.. waere schon ne TOTSUENDE" - Zotty|
Harald Fuchs
Was gibts denn an empfehlenswerter Literatur (Buch oder auch nur Text-File)
zur csh-Programmierung?
Wenn Du Dir unbedingt sowas antun willst: als csh-Bibel gilt im allgemeinen
Anderson, Gail und Paul: The UNIX C Shell Field Guide
Prentice-Hall 1986
Bitte nicht als Antwort: "shell-Programmierung ist nur was fuer Arme, nimm
ne richtige (Compiler-) Sprache!"
Csh-Programmierung ist nur was fuer Arme, nimm ne richtige Sprache wie
Bourne-Shell oder Perl.
--
Harald Fuchs <h...@informatik.uni-kl.de>
Patrick M. Hausen
ORA...@rzmain.rz.uni-ulm.de (Framstag) writes:
> Hallo Leude,
Moin Framstag!
> Was gibts denn an empfehlenswerter Literatur (Buch oder auch nur Text-File)
> zur csh-Programmierung?
>
> Ich hab zwar schon diverse Unix-Lehrbuecher durchgeblaettert, aber dieses
> Thema wird immer nur kurz gestreift und es sind mir auch viel zuwenige
> Beispiele drin (das trifft auch fuer die man-page zu).
> Es sollte schon wesentlich mehr sein, als nur ein Referenzwerk.
Versuch mal S.R.Bourne (Jawohl, _der_ Bourne), "Das UNIX System".
Der erlaeutert die Programmierung der (Bourne-)Shell ziemlich
exzessiv, bis hin zu einem "Tennisranglistensystem" in sh, sed und awk.
"Der Profi" benutzt zwar C- oder Korn-Shell und wahrscheinlich Perl,
aber wenn Du den Bourne verdaut hast, kannst Du ja mit der C-Shell Doku
weitermachen.
> Bitte nicht als Antwort: "shell-Programmierung ist nur was fuer Arme, nimm
> ne richtige (Compiler-) Sprache!"
Das wird Dir wahrscheinlich keiner antworten. Die Shell-Programmierung ist
doch der Gag an Unix. C gibt's auf meinem Atari auch bis zum Exzess.
(Frag doch mal Matthias Urlichs, wieviel % seines Mail-Systems Scripts
sind. - Wuerde mich auch interessieren, hallo Matthias :-))
Grusz, Paddy
--
||| Patrick M. Hausen | phone : +49 721 699234 (voice and carrier)
||| Gerwigstr. 11 | e-mail: p...@cutie.ka.sub.org (UUCP)
/ | \ D-7500 Karlsruhe 1, Germany | uk9u@dkauni2 (BITNET)
"These mist covered mountains are a home now for me,
but my home is the lowlands and always will be." (Dire Straits)
Matthias Urlichs
schreibt p...@cutie.ka.sub.org (Patrick M. Hausen):
< In article <1991Oct18.1...@rusmv1.rus.uni-stuttgart.de>
< ORA...@rzmain.rz.uni-ulm.de (Framstag) writes:
<
< > Was gibts denn an empfehlenswerter Literatur (Buch oder auch nur Text-File)
< > zur csh-Programmierung?
< >
< > Ich hab zwar schon diverse Unix-Lehrbuecher durchgeblaettert, aber dieses
< > Thema wird immer nur kurz gestreift und es sind mir auch viel zuwenige
< > Beispiele drin (das trifft auch fuer die man-page zu).
<
< aber wenn Du den Bourne verdaut hast, kannst Du ja mit der C-Shell Doku
< weitermachen.
<
Das Teil hat einen ad-hoc-Parser, der nicht rekursiv arbeitet und dem daher
nicht zuzumuten ist, mit einigermassen komplexen Strukturen was vernuenftiges
anzufangen.
< > Bitte nicht als Antwort: "shell-Programmierung ist nur was fuer Arme, nimm
< > ne richtige (Compiler-) Sprache!"
< Das wird Dir wahrscheinlich keiner antworten. Die Shell-Programmierung ist
< doch der Gag an Unix. C gibt's auf meinem Atari auch bis zum Exzess.
< (Frag doch mal Matthias Urlichs, wieviel % seines Mail-Systems Scripts
< sind. - Wuerde mich auch interessieren, hallo Matthias :-))
<
Viele. Die gesamte Routerei ist in zsh geschrieben (die Skriptsprache, die
der Router vom zmailer compretiert (will sagen, das Teil wird in einen
Zwischencode compiliert, der dann interpretiert wird)), das Drumherum zur
Abrechnungsverwaltung in Perl. Der Mailer selber macht nur die Headeranalyse,
fragt das Skript, welche Adressen wo hingeroutet und welche Header wie
umgeschrieben werden sollen (RFC822 mit einer Skriptsprache auseinander-
pfluecken zu wollen ist hoffnungslos), und schreibt den Krempel in ein paar
Dateien, die dann von einem anderen Programm interpretiert werden (und von
dem dann die Programme aufgerufen werden, die die Mail wieder versenden.)
Der zsh-Skriptteil ist ca 80 kByte gross, wobei vieles schon beim zmailer
dabei war.
Die einzigen C-Teile stecken in der Anpassung vom Mailer an mein System.
Irgendwas anderes in C zu schreiben ist mir zu aufwendig -- String- und
Speicherhandling explizit aufzurufen anstelle, wie in Perl, den Krempel
einfach hinzuschreiben, ist mir zuwider, und Aenderungen lassen sich in so
ein Perl- oder (beim Mailer) ein zsh-Skript schneller einbauen und austesten.
Gegen sh+sed+awk-Programmierung habe ich was. Abgesehen von der
Ineffizienz, staendig zu forken und irgendwelche Fitzelprogramme aufzurufen,
um diverse Datenstroeme zu vermauscheln, haette ich fuer die taegliche Arbeit
gerne eine Programmiersprache und nicht eine Kombination aus
Befehlszeilenausfuehrer(sh), Reportgenerator(awk), Datenstromeditor(sed),
und Kleinkram (cut/sort/comm/diff/...).
Perl ist nicht perfekt, aber es tut das, was ich machen will, mit dem
geringsten Aufwand an Arbeit fuer mich und mit minimal groesserem Aufwand
fuer das System.
--
Matthias Urlichs -- url...@smurf.sub.org -- url...@smurf.ira.uka.de /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/
Kristian Koehntopp
>Was gibts denn an empfehlenswerter Literatur (Buch oder auch nur Text-File)
>zur csh-Programmierung?
Keins. csh ist zur Programmierungs nicht zu empfehlen.
: use /bin/sh
>Bitte nicht als Antwort: "shell-Programmierung ist nur was fuer Arme, nimm
>ne richtige (Compiler-) Sprache!"
Compilersprachen sind was fuer DOSler. Unter UNIX nimmt man
cron, sh und awk. Manche auch cron, ksh und perl, aber das sind
dann mutierte Turbo-PASCAListen (Vor den Flames aus .ka.* in
Deckung geh' :-).
Ich habe sh-Programmierung nach der Manualpage, dem Bourne und
laengeren Shell-Sessions erlernt. Klappt ganz gut. Es hilft
auch, wenn man anderer Leute Scripte liest.
$ find / -type f -print | xargs file | grep "commands text"
oder so.
Kristian
Kristian Koehntopp, Harmsstrasse 98, 2300 Kiel, +49 431 676689
"Ich bin ein .signature Virus. Mach' mit und kopiere mich in Deine .signature."
Framstag
> Gegen sh+sed+awk-Programmierung habe ich was. Abgesehen von der
> Ineffizienz, staendig zu forken und irgendwelche Fitzelprogramme aufzurufen,
> um diverse Datenstroeme zu vermauscheln, haette ich fuer die taegliche Arbeit
> gerne eine Programmiersprache und nicht eine Kombination aus
> Befehlszeilenausfuehrer(sh), Reportgenerator(awk), Datenstromeditor(sed),
> und Kleinkram (cut/sort/comm/diff/...).
> Perl ist nicht perfekt, aber es tut das, was ich machen will, mit dem
> geringsten Aufwand an Arbeit fuer mich und mit minimal groesserem Aufwand
> fuer das System.
Da komm ich ja auf ganz neue Ideen :-)
Perl: hab schon einiges darueber gehoert. Seh ich das richtig, dass das
eine Mischung aus (c)sh,awk und sed + neue features ist?
Laeuft das auch als Interpreter, so dass ich wie bei einer shell interaktiv
Variablen abfragen und setzen kann?
Ansonst kann ich ja gleich eine klassische Compilersprache benutzen. Darin
seh ich den eigentlichen Vorteil.
Gibt es darueber ein Buch oder ist im perl.tar.Z (oderwieauchimmerdas-
heissenmag) eine ordentliche Doku (=mit vielen Beispielen :-) mit dabei?
Joachim Astel
> Perl ist nicht perfekt, aber es tut das, was ich machen will, mit dem
> geringsten Aufwand an Arbeit fuer mich und mit minimal groesserem Aufwand
> fuer das System.
Leider ist Perl schon fast wieder die eierlegende Wollmilchsau und daher
vergleichsweise gross. Wenn auf einem kleineren System mit wenig Haupt-
speicher immer erst das etwa 300 KB grosse Perl-System executed werden
muss, bevor ueberhaupt was laeuft, geht das mit kleinen Futzelprogrammen
zum Teil etwas schneller...
Darueberhinaus ist Perl zwar logisch aufgebaut, aber ziemlich kryptisch
anzusehen. Haette Larry Wall die Sprache nicht ein wenig 'netter' ge-
stalten koennen? :-)
-Achim
Matthias Urlichs
schreibt ORA...@rzmain.rz.uni-ulm.de (Framstag):
< In <nw#d#p...@smurf.sub.org> url...@smurf.sub.org writes:
<
< > [ Perl ]
<
< Da komm ich ja auf ganz neue Ideen :-)
<
< Perl: hab schon einiges darueber gehoert. Seh ich das richtig, dass das
< eine Mischung aus (c)sh,awk und sed + neue features ist?
<
Perl is an interpreted language optimized for scanning
arbitrary text files, extracting information from those text
files, and printing reports based on that information. It's
also a good language for many system management tasks. The
language is intended to be practical (easy to use,
efficient, complete) rather than beautiful (tiny, elegant,
minimal). It combines (in the author's opinion, anyway)
some of the best features of C, sed, awk, and sh, so people
familiar with those languages should have little difficulty
with it. (Language historians will also note some vestiges
of csh, Pascal, and even BASIC-PLUS.) Expression syntax
corresponds quite closely to C expression syntax. Unlike
most Unix utilities, perl does not arbitrarily limit the
size of your data--if you've got the memory, perl can slurp
in your whole file as a single string. Recursion is of
unlimited depth. And the hash tables used by associative
arrays grow as necessary to prevent degraded performance.
Perl uses sophisticated pattern matching techniques to scan
large amounts of data very quickly. Although optimized for
scanning text, perl can also deal with binary data, and can
make dbm files look like associative arrays (where dbm is
available). Setuid perl scripts are safer than C programs
through a dataflow tracing mechanism which prevents many
stupid security holes. If you have a problem that would
ordinarily use sed or awk or sh, but it exceeds their
capabilities or must run a little faster, and you don't want
to write the silly thing in C, then perl may be for you.
There are also translators to turn your sed and awk scripts
into perl scripts. OK, enough hype.
< Laeuft das auch als Interpreter, so dass ich wie bei einer shell interaktiv
< Variablen abfragen und setzen kann?
<
Du hast nen interaktiven Debugger, den du durchaus als Shell missbrauchen
kannst.
< Ansonst kann ich ja gleich eine klassische Compilersprache benutzen. Darin
< seh ich den eigentlichen Vorteil.
<
Die klassische Compilersprache mit eingebauter Speicherverwaltung,
Patternmatching, assoziativen Arrays, und einer Edit-...-Debug-Zeit von zwei
Sekunden, moechte ich mal sehen. ;-)
< Gibt es darueber ein Buch oder ist im perl.tar.Z (oderwieauchimmerdas-
< heissenmag) eine ordentliche Doku (=mit vielen Beispielen :-) mit dabei?
<
Der Manualschnipsel ist ziemlich laenglich und beschreibt eigentlich alles.
Beispielprogramme finden sich auch zur Genuege, und ein Buch gibt's auch --
das "Camel Book", aus der O'Reilly-Nutshell-Serie. Geschrieben von Larry Wall
(dem Autor von Perl) und Randall Schwartz. Beide findet mensch auch in
comp.lang.perl.
Matthias Urlichs
schreibt dowj...@jattmp.nbg.sub.org (Joachim Astel):
< url...@smurf.sub.org (Matthias Urlichs) schreibt:
< > Perl ist nicht perfekt, aber es tut das, was ich machen will, mit dem
< > geringsten Aufwand an Arbeit fuer mich und mit minimal groesserem Aufwand
< > fuer das System.
<
< Leider ist Perl schon fast wieder die eierlegende Wollmilchsau und daher
< vergleichsweise gross. Wenn auf einem kleineren System mit wenig Haupt-
< speicher immer erst das etwa 300 KB grosse Perl-System executed werden
< muss, bevor ueberhaupt was laeuft, geht das mit kleinen Futzelprogrammen
< zum Teil etwas schneller...
<
ich auch ein Shellskript.
Aber sobald's mehr wird, ist die Zeit zm Starten von Perl auch nicht groesser
als die fuer eine Shell und meinetwegen awk oder sed, nicht zu vergessen der
Aufwand fuer's fork()en.
< Darueberhinaus ist Perl zwar logisch aufgebaut, aber ziemlich kryptisch
< anzusehen. Haette Larry Wall die Sprache nicht ein wenig 'netter' ge-
< stalten koennen? :-)
<
Frag ihn doch... ;-)
Peter Cleve
>Perl: hab schon einiges darueber gehoert. Seh ich das richtig, dass das
>eine Mischung aus (c)sh,awk und sed + neue features ist?
[ ...... ]
>Ansonst kann ich ja gleich eine klassische Compilersprache benutzen. Darin
>seh ich den eigentlichen Vorteil.
Es hat auch seine Vorteile wenn man sich nicht um die Groesse
irgentwelcher Strings kuemmern muss, oder die Speicherverwaltung voellig
vom Interpreter geregelt wird.
>Gibt es darueber ein Buch oder ist im perl.tar.Z (oderwieauchimmerdas-
>heissenmag) eine ordentliche Doku (=mit vielen Beispielen :-) mit dabei?
Programming Perl, von Larry Wall u. Randal L. Schwartz, erschienen bei
O'Reilly & Associates, ISBN: 0-937175-64-1
Tschau
--
Peter Cleve, Hildesheimer Str. 316, 3014 Laatzen 3, Tel. 05102/1854 (Voice)
Energiesparen ist das moralische Aequivalent zum Krieg. (Jimmy Carter)
Framstag
> ORA...@rzmain.rz.uni-ulm.de (Framstag) writes:
> >Was gibts denn an empfehlenswerter Literatur (Buch oder auch nur Text-File)
> >zur csh-Programmierung?
>
> Keins. csh ist zur Programmierungs nicht zu empfehlen.
>
> : use /bin/sh
>
Und warum? Ich dachte immer, dass csh eine bessere Alternative zur sh
waere, da sh von AT&T (=sowieso mies) und csh von BSD (=sowieso gut) ist ;-)
/---Ulli Horlacher---Rechenzentrum Uni Ulm---Oberer Eselsberg---7900 Ulm---\
\ ora...@dulruu51.bitnet | ora...@rz.uni-ulm.de | fram...@uni-ulm.de /
\------------------------------------------------------------------------/
| "Diese Messe macht mich fertig: jetzt schau ich schon den Frauen |
| nach anstelle den Computern!" Flynn auf der SYSTEMS 24.10.91 |
Matthias Urlichs
schreibt ORA...@rzmain.rz.uni-ulm.de (Framstag):
< In <11...@tpki.toppoint.de> kr...@tpki.toppoint.de writes:
<
< > ORA...@rzmain.rz.uni-ulm.de (Framstag) writes:
< > >Was gibts denn an empfehlenswerter Literatur (Buch oder auch nur Text-File)
< > >zur csh-Programmierung?
< >
< > Keins. csh ist zur Programmierungs nicht zu empfehlen.
<
< waere, da sh von AT&T (=sowieso mies) und csh von BSD (=sowieso gut) ist ;-)
<
Nur hat das Teil keinen vernuenftigen Parser und verkraftet daher manche
verschachtelten Strukturen nicht, vor allem dann nicht, wenn noch Pipes mit
im Spiel sind. Schon so simple Sachen wie
#!/bin/sh
for i ; do
< mach irgendwas mit Datei $i >
done | < mach irgendwas mit dem Resultat >
sind unter der csh nicht drin. Siehe csh(1):
The foreach, switch, and while statements, as well as the
if-then-else form of the if statement require that the major
keywords appear in a single simple command on an input line
as shown later.
Oder versuch mal, einem Programm unter der csh ein Argument mit Newline drin
mitzugeben (zB fuer ein awk/perl/was-auch-immer-Skript). Das funktioniert noch.
Innerhalb von `` geht's aber ploetzlich nicht mehr.
Kommentar: Leider daneben.
Peter Funk
mu> < Und warum? Ich dachte immer, dass csh eine bessere Alternative zur sh
mu> < waere, da sh von AT&T (=sowieso mies) und csh von BSD (=sowieso gut) ist ;-)
mu> <
mu> Die csh ist zum interaktiven Arbeiten hervorragend.
mu> Nur hat das Teil keinen vernuenftigen Parser und verkraftet daher manche
mu> verschachtelten Strukturen nicht, vor allem dann nicht, wenn noch Pipes mit
mu> im Spiel sind. Schon so simple Sachen wie
[...gutes Beispiel geloescht...]
Sehr schoen. Und was lernen wir daraus ? Man nimmt die 'csh' als Login
Shell, nutzt eventuell die 'aliases' fuer haeufig gebrauchte One-Liner
und verwendet fuer Shell-Skripte die "real shell" (/bin/sh) --manchmal
ein wenig gewuerzt mit 'sed' und 'awk'-- und schon kommt man im
wirklichen Leben wunderbar zurecht....
Was ? Hoere ich da gerade einen Aufschrei des Entsetzens und Protestes
durch die Gemeinde gehen ? Ja ja ich weiss, es gibt da noch 'perl'
und etliche andere tolle Shells (bash, tcsh, zsh, ksh ...), die
alle ihre Vorteile haben. Das man sie dazu, teilweise gratis bekommt,
weiss ich auch.
Aber irgendwie erinnern mich die Leute, die sowas benutzen, stets
an jene Zeitgenossen, die mit einem 12 Meter langen Wohnmobil
zum Camping fahren und sich am Zielort erst dann wohl fuehlen,
wenn sie sich einen Vormittag lang damit beschaeftigt haben,
eine 40 Quadratmeter grosse Flaeche mittels Klappsesseln, Vorzelt
und anderem Zubehoer so umzugestalten, dass sie wie die heimische
Terrasse aussieht.
Wenn ich auf ein fremdes UNIX komme, brauche ich nur "mein Handtuch
ausrollen" (.cshrc,.login,.exrc einspielen) und kann mich dann auch ohne
dieses ganze Gedoens zurecht finden... ;-)
Gruss, Peter
-=-=-
Peter Funk \\ ArtCom GmbH, Schwachhauser Heerstr. 78, D-2800 Bremen 1
Work at home: Oldenburger Str.86, D-2875 Ganderkesee 1/phone : top secret
Matthias Urlichs
schreibt p...@artcom0.north.de (Peter Funk):
< In <2-ad!x...@smurf.sub.org> url...@smurf.sub.org (Matthias Urlichs) writes:
<
<mu> Die csh ist zum interaktiven Arbeiten hervorragend.
<mu> Nur hat das Teil keinen vernuenftigen Parser und verkraftet daher manche
<mu> verschachtelten Strukturen nicht, vor allem dann nicht, wenn noch Pipes mit
<mu> im Spiel sind. Schon so simple Sachen wie
< [...gutes Beispiel geloescht...]
<
< Sehr schoen. Und was lernen wir daraus ? Man nimmt die 'csh' als Login
< Shell, nutzt eventuell die 'aliases' fuer haeufig gebrauchte One-Liner
< und verwendet fuer Shell-Skripte die "real shell" (/bin/sh) --manchmal
< ein wenig gewuerzt mit 'sed' und 'awk'-- und schon kommt man im
< wirklichen Leben wunderbar zurecht....
<
< Was ? Hoere ich da gerade einen Aufschrei des Entsetzens und Protestes
< durch die Gemeinde gehen ? Ja ja ich weiss, es gibt da noch 'perl'
< und etliche andere tolle Shells (bash, tcsh, zsh, ksh ...), die
< alle ihre Vorteile haben. Das man sie dazu, teilweise gratis bekommt,
< weiss ich auch.
< Wenn ich auf ein fremdes UNIX komme, brauche ich nur "mein Handtuch
< ausrollen" (.cshrc,.login,.exrc einspielen) und kann mich dann auch ohne
< dieses ganze Gedoens zurecht finden... ;-)
<
OK, ich schlepp halt noch mein Zelt (in Form von einer Disk mit den
Perl-Sourcen :-) mit rum, und baue das mal schnell auf ("sh Configure;make").
Ausserdem werden bei Perl Uebersetzer von awk/sed nach Perl mitgeliefert,
so dass ich den Krempel nicht auch noch lernen muss. ;-)
Allein mit dem Handtuch kommst du spaetests dann nicht mehr weiter,
wenn's anfaengt zu regnen. :-)
Auf andere tolle Shells (ich verwende lokal auch die bash fuers interaktive
Arbeiten, im csh+vi-Modus ;-) kann ich anderswo verzichten, genauso wie auf
den ganzen uebrigen Krempel, der so im Laufe der Zeit uebers Netz wandert und
sich in meinen rc-Files niederschlaegt; Sachen wie (Zitat aus ~/.cshrc)
alias l "/bin/ls -F \!* | colm -v -g2
braucht's wirklich nicht unbedingt ueberall...
Heiko Schlichting
>mu> < Und warum? Ich dachte immer, dass csh eine bessere Alternative zur sh
>mu> < waere, da sh von AT&T (=sowieso mies) und csh von BSD (=sowieso gut) ist ;-)
>mu> <
>mu> Die csh ist zum interaktiven Arbeiten hervorragend.
>mu> Nur hat das Teil keinen vernuenftigen Parser und verkraftet daher manche
>mu> verschachtelten Strukturen nicht, vor allem dann nicht, wenn noch Pipes mit
>mu> im Spiel sind. Schon so simple Sachen wie
>[...gutes Beispiel geloescht...]
>
>Sehr schoen. Und was lernen wir daraus ? Man nimmt die 'csh' als Login
>Shell, nutzt eventuell die 'aliases' fuer haeufig gebrauchte One-Liner
>und verwendet fuer Shell-Skripte die "real shell" (/bin/sh) --manchmal
>ein wenig gewuerzt mit 'sed' und 'awk'-- und schon kommt man im
>wirklichen Leben wunderbar zurecht....
Das *KANN* so sein, muss aber nicht so sein. Aus eigener Erfahrung weiss
ich, dass man eigentlich nur dann zufrieden ist, wenn man seine gewohnte
Arbeitsumgebnung hat. Ich habe es nicht geschafft bei uns ein paar Usern
die bei uns gelaeufige Shell (tcsh) aufzudruecken. Die wollten unbedingt
ihre Shell haben, die sie normalerweise benutzen (ksh oder sh).
Das finde ich auch verstaendlich. Mir ging es umgekehrt genauso - wie habe
ich geflucht, dass ich nur die csh und nicht die tcsh bekommen habe (und
mein .cshrc sowie Cursortasten demzufolge nicht mehr funktionieren).
Ich sehe es inzwischen so: es ist wirklich noetig, dass man ueberall die
gleiche Arbeitsumgebung hat, an die man sich gewoehnt hat. Manche Leute
werden dann auch mit einer sh als interactive Shell gluecklich.
>Was ? Hoere ich da gerade einen Aufschrei des Entsetzens und Protestes
>durch die Gemeinde gehen ?
Ja, den hoerst Du.
>Aber irgendwie erinnern mich die Leute, die sowas benutzen, stets
>an jene Zeitgenossen, die mit einem 12 Meter langen Wohnmobil
>zum Camping fahren und sich am Zielort erst dann wohl fuehlen,
>wenn sie sich einen Vormittag lang damit beschaeftigt haben,
>eine 40 Quadratmeter grosse Flaeche mittels Klappsesseln, Vorzelt
>und anderem Zubehoer so umzugestalten, dass sie wie die heimische
>Terrasse aussieht.
Das ist nicht ganz zu vergeleichen. Wenn ich einen Account auf einem anderen
Rechner bekomme, dann ist das ja normalerweise kein 'Urlaub', sondern man
will moeglichst effektiv und schnell ein Problem loesen oder einen Prozess
(Newsfluss?) kontrollieren oder aehnliches. Das geht nun mal am schnellsten,
wenn man eine Shell hat, die die Features liefert, die man ueblicherweise
braucht. Das kann die csh sein, muss aber nicht. Mir fehlen zum Beispiel
Features, die ich unbedingt benoetige (periodisches Ausfuehren von
Befehlen vor dem Prompt, Cursortasten, Anzeige der User, die sich gerade
einloggen etc). Also kann ich fuer *mich* entscheiden, dass die csh nicht
die richtige Shell ist. Natuerlich kann ich darin tippen, aber es nicht
die richtige *Arbeits*umgebung. (in Deinem Beispiel oben hast Du so getan,
als wuerde ein Shell Urlaub bedeuten - die Shell bedeutet doch Arbeit. Wenn
ich Urlaub mache, ruf ich 'irc' auf.)
>Wenn ich auf ein fremdes UNIX komme, brauche ich nur "mein Handtuch
>ausrollen" (.cshrc,.login,.exrc einspielen) und kann mich dann auch ohne
>dieses ganze Gedoens zurecht finden... ;-)
Wenn die Lieblingsshell vorhanden ist, geht das. Natuerlich habe ich mit
meiner tcsh da manchmal Probleme. Aber nur, weil manche Rechner die Shell
nicht haben, soll ich bei meiner taeglichen Arbeit mit einer unkomfortabelen
Shell auskommen? Nein, danke. :-)
Inzwischen lehne ich eigentlich Accounts auf Rechnern ab, die keine tcsh
haben oder das erste, was ich uebersetze ist die tcsh (gefolgt von gawk).
Naja - wie Du siehst, kann man eingefleichste Fans einer bestimmten Shell
*nie* ueberzeugen - schon gar nicht, wenn das einizige Argument ist: "diese
Shell gibt es auf allen Rechern". Schreibst Du eine Diplomarbeit unter
MS-DOS mit dem edlin?
Tschuess, Heiko.
--
|~| Heiko Schlichting | Freie Universitaet Berlin
/ \ he...@fub.uucp | Institut fuer Organische Chemie
/FUB\ he...@methan.chemie.fu-berlin.de | Takustrasse 3
`---' phone +49 30 838-2677; fax ...-5163 | D-1000 Berlin 33 Germany
Juergen Ernst Guenther
> OK, ich schlepp halt noch mein Zelt (in Form von einer Disk mit den
> Perl-Sourcen :-) mit rum, und baue das mal schnell auf ("sh Configure;make").
> Ausserdem werden bei Perl Uebersetzer von awk/sed nach Perl mitgeliefert,
> so dass ich den Krempel nicht auch noch lernen muss. ;-)
Und wo steckst Du bei `richtigen' Rechnern die Diskette rein?
--
----- muf...@asbach.nbg.sub.org ----- asbacco maggiore, zentralfranken -----
(SETQ PI 3.14159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798)
Matthias Urlichs
schreibt muf...@asbach.nbg.sub.org (Juergen Ernst Guenther):
< In <zjc...@smurf.sub.org>, Matthias Urlichs writes:
<
< > OK, ich schlepp halt noch mein Zelt (in Form von einer Disk mit den
< > Perl-Sourcen :-) mit rum, und baue das mal schnell auf ("sh Configure;make").
Bei einem "richtigen" Rechner mache ich einen FTP zur naechsten freundlichen
Archiv-Maschine und hole mir das Zeug.
--
Matthias Urlichs