Hallo, eigentlich würde ich kppp für den Online-Zugang lieber benutzen wie kinternet, da ich bei erstem Programm noch ein Kostenprotokoll erstellt bekomme. Doch wie konfigurieren? Beim Starten von Kppp gab's schon die erste Fehlermeldung: "Sie haben keine ausreichende Berechtigung zur Ausführung von /usr/sbin/pppd. Bitte stellen Sie sicher, das Kppp root gehört und das SUID-Bit gesetzt ist." Ich habe dann die SUID-Bits sowohl für kppp als auch pppd gesetzt. Das sieht dann wie folgt aus: ls -l kppp [ /opt/kde3/bin ] ----> -rwsr-xr-x 1 root root ...... kppp ls -l pppd [ /usr/sbin ] ----> -rwsr-xr-x 1 root dialout ..... pppd Mitglieder der Gruppe 'dialout' sind alle normalen Benutzer auf dem Rechner. Wenn man dann kppp startet, wählt zwar das Modem, aber nach einer gewissen Zeit (nach dem CONNECT, s. u.) gibt's dann Fehlermeldungen. Im Login-Skript-Fenster von Kppp taucht auf: ATZ OK ATM1L3 OK ATDT019160 CONNECT 46666 V42bis "Fehler - kppp: Der pppd-Dämon wurde unerwartet beendet! Rückgabewerte: 2. Siehe 'man pppd' für eine Erklärung der Fehlerkodes oder lesen Sie die kppp FAQ auf http://devel-home.kde.rog/~kppp/index.html." Unter Details in diesem Fenster ergibt sich dann: Auszug aus der PPP-Logdatei: 'linux pppd[1199]: unrecognized option 'passwordfd'. Weiter unten steht zu lesen: Kppp-Diagnose (nur eine Vermutung): "Sie haben eine ungültige Option an pppd übergeben. Siehe "man pppd" für eine komplette Liste gültiger Parameter.' Jetzt wie weiter? Mit den 'man pppd' komme ich nicht weiter. Kann mir ein geduldiger erfahrener User hier weiterhelfen? Eigenes Niveau: Anfänger (Umsteiger von M$). Gruß Thomas -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Hallo Thomas, hallo Leute, Am Montag, 13. Januar 2003 09:32 schrieb Thomas GRIESSEMER:
Wenn man dann kppp startet, wählt zwar das Modem, aber nach einer gewissen Zeit (nach dem CONNECT, s. u.) gibt's dann Fehlermeldungen.
Im Login-Skript-Fenster von Kppp taucht auf:
[...] ATDT019160 CONNECT 46666 V42bis
"Fehler - kppp: Der pppd-Dämon wurde unerwartet beendet! Rückgabewerte: 2. Siehe 'man pppd' für eine Erklärung der Fehlerkodes oder lesen Sie die kppp FAQ auf http://devel-home.kde.rog/~kppp/index.html." Unter Details in diesem Fenster ergibt sich dann: Auszug aus der PPP-Logdatei: 'linux pppd[1199]: unrecognized option 'passwordfd'. Weiter unten steht zu lesen: Kppp-Diagnose (nur eine Vermutung): "Sie haben eine ungültige Option an pppd übergeben. Siehe "man pppd" für eine komplette Liste gültiger Parameter.'
Damit hat Kppp sogar recht, es gibt anscheinend keine Option passwordfd für pppd. Schau mal in die /etc/ppp/options, ob Du dort eine Zeile findest, in der passwordfd steht. Der Einfachheit halber: grep passwordfd /etc/ppp/options | grep -v "^#" (Zur Erklärung: grep sucht in der /etc/ppp/options nach Zeilen, die passwordfd enthalten. Die Suchergebnisse werden dann an ein zweites grep weitergegeben ("gepiped"), das alle Zeilen ausfiltert, die mit # beginnen, also ein Kommentar sind.) Falls etwas ausgegeben wird, bearbeite (als root) die /etc/ppp/options und setze ein # vor die Zeile, in der passwordfd steht.
Jetzt wie weiter? Mit den 'man pppd' komme ich nicht weiter.
... und ich komme bei solchen Fragen selten _ohne_ man pppd weiter ;-)
Kann mir ein geduldiger erfahrener User hier weiterhelfen?
Na, das werden wir dann ja sehen.
Eigenes Niveau: Anfänger (Umsteiger von M$).
Tja, das war ich auch mal ;-) Gruß Christian Boltz -- Aber warum willst Du den Rechner eigentlich herunterfahren? Linux- rechner bootet man nicht alle paar Tage, sondern alle paar Monate, wenn man einen neuen Kernel installiert hat oder neue Hardware integrieren will und dafür den Strom abstellen muß. --- Bernd Brodesser
Hallo Christian ... On Tue, 14 Jan 2003, christian.boltz@nexgo.de wrote:
Am Montag, 13. Januar 2003 09:32 schrieb Thomas GRIESSEMER:
[...]
Damit hat Kppp sogar recht, es gibt anscheinend keine Option passwordfd für pppd.
Schau mal in die /etc/ppp/options, ob Du dort eine Zeile findest, in der passwordfd steht. Der Einfachheit halber: grep passwordfd /etc/ppp/options | grep -v "^#"
Falls Du dort nichts findest schau mal in in /etc/ppp/peers/ppp nach. Ich glaube mich dunkel zu erinnern daß sich dort etwas mit passwordfd.so befindet was imho ein SuSE eigenes Plugin für pppd ist. Bye, Michael -- Unsere tägliche Identifikation erspare uns heute ... http://www.notcpa.org
Am Mit, 2003-01-15 um 03.16 schrieb Michael Strauss:
Falls Du dort nichts findest schau mal in in /etc/ppp/peers/ppp nach. Ich glaube mich dunkel zu erinnern daß sich dort etwas mit passwordfd.so befindet was imho ein SuSE eigenes Plugin für pppd ist.
Korrrekt. Ciao, Torsten -- Homepage: http://www.hall-music.de/ letzte Änderung: 01.09.2002
Hallo, On Tue, 14 Jan 2003, Christian Boltz wrote:
grep passwordfd /etc/ppp/options | grep -v "^#"
*tsk* Christian, willst du nicht mal ein wenig ueber 'man grep', 'man sed', v.a. aber ueber 'man 7 regex' "meditieren"? *scnr* grep '^[^#]*passwordfd' ... Und generell gilt IMO: Immer wenn mehr als ein grep noetig waere (d.h. wenn sich's nicht zu einer RE wie oben zusammenfassen laesst) ist 'sed' richtig: sed -n '/^#/d;/passwordfd/p' Oder in diesem einfachen Falle: sed -n '/^[^#*]passwordfd/p' Achso: "echt" aequivalent zu Christians grep-Konstrukt waere wohl: sed -n '/passwordfd/{/^#/d;p;}' [erst: nur Zeilen mit passwordfd ausfiltern, dann Kommentare loeschen und dann den Rest ausgeben...] Geeigneter ist aber wohl mein grep-Konstrukt... Ich habe mir aber eben den "Reflex" angeeignet, dass wenn ich 2 (oder mehr) "grep"s sehe, diese erstmal nach sed zu "uebersetzen" ;) -dnh, grep, sed, awk und perl in eben diese Stufung verwendend... PS: awk und perl gingen natuerlich auch, sind aber wohl noch mehr overkill als es (hier) sed schon ist ;) -- Die Deutsche Sprache ist also nicht ursprünglich deutsch, sondern ein Konglomerat aus verschiedenen anderen Sprachen, die aber auch nicht ursprünglich sind, sondern wieder Konglomerate aus verschiedenen noch anderen Sprachen, die... [Volker Tanner in suse-talk]
Hallo David, hallo Leute, David, willst Du mir etwa einen Award verleihen? ;-) Am Mittwoch, 15. Januar 2003 05:21 schrieb David Haller:
On Tue, 14 Jan 2003, Christian Boltz wrote:
grep passwordfd /etc/ppp/options | grep -v "^#"
*tsk*
Christian, willst du nicht mal ein wenig ueber 'man grep', 'man sed', v.a. aber ueber 'man 7 regex' "meditieren"? *scnr*
"Wollen" schon, aber derzeit treibe ich mich eher mit vi in der aktuellen Fontlinge-CVS-Version herum ;-) Ach so: ich hätte mir die passende RegEx
grep '^[^#]*passwordfd' ...
schon zusammenbasteln können (zumindest die Grundlagen von RegEx habe ich inzwischen im Kopf), aber ein hinterhergejagtes | grep -v geht mir (noch...) leichter aus der Hand ;-)
Und generell gilt IMO: Immer wenn mehr als ein grep noetig waere (d.h. wenn sich's nicht zu einer RE wie oben zusammenfassen laesst) ist 'sed' richtig:
sed -n '/^#/d;/passwordfd/p'
Ist natürlich auch eine Möglichkeit ;-)
Oder in diesem einfachen Falle:
sed -n '/^[^#*]passwordfd/p'
Was ja nix anderes als grep mit der RegEx wäre ;-)
Achso: "echt" aequivalent zu Christians grep-Konstrukt waere wohl:
sed -n '/passwordfd/{/^#/d;p;}'
[erst: nur Zeilen mit passwordfd ausfiltern, dann Kommentare loeschen und dann den Rest ausgeben...]
Ah, der Bereichsoperator. Den hast Du mir ja mal recht ausführlich per PM erklärt. Ich glaube sogar, dass ich die Erklärung noch halbwegs im Kopf habe ;-) (BTW: wolltest Du die Erklärung nicht mal irgendwo auf Deiner Homepage einbauen?)
Geeigneter ist aber wohl mein grep-Konstrukt... Ich habe mir aber eben den "Reflex" angeeignet, dass wenn ich 2 (oder mehr) "grep"s sehe, diese erstmal nach sed zu "uebersetzen" ;)
;-)
-dnh, grep, sed, awk und perl in eben diese Stufung verwendend...
Schöne Zusammenstellung ;-) Ich habe nur das Problem, dass ich von awk gar keine und von perl (schreibend) recht wenig Ahnung habe ;-) Naja, perl eigne ich mir gaaanz langsam an ;-) Gruß Christian Boltz PS: keine Zufallssig (oder ist mir da eine Mail abhanden gekommen?) --
Daaaaaavid, wo bleibt eigentlich mal 'ne anständige Statistik? *JAUL* Ich mach ja schon... [Ratti und David Haller in suse-linux]
Hallo, On Thu, 16 Jan 2003, Christian Boltz wrote:
David, willst Du mir etwa einen Award verleihen? ;-)
Nein ;) Aber die Tendenz dazu, dass es in Richtung eines solchen Awards geht, andeuten wollend ;)
Am Mittwoch, 15. Januar 2003 05:21 schrieb David Haller:
On Tue, 14 Jan 2003, Christian Boltz wrote:
grep passwordfd /etc/ppp/options | grep -v "^#"
*tsk*
Christian, willst du nicht mal ein wenig ueber 'man grep', 'man sed', v.a. aber ueber 'man 7 regex' "meditieren"? *scnr*
s/l /&wieder /
"Wollen" schon, aber derzeit treibe ich mich eher mit vi in der aktuellen Fontlinge-CVS-Version herum ;-)
Ahso. Dann is gut. Da is noch einiges zu tun (hab neulich mal reingeschaut)... *veg* Loeblich das, also :))
Ach so: ich hätte mir die passende RegEx
grep '^[^#]*passwordfd' ...
schon zusammenbasteln können (zumindest die Grundlagen von RegEx habe ich inzwischen im Kopf), aber ein hinterhergejagtes | grep -v geht mir (noch...) leichter aus der Hand ;-)
Ja, mir auch! Aber ich bemuehe mich, zumindest wenn ich dann sowas in mails schreibe, das dann schon wegzuoptimieren, bzw. mir so eine Zusammenfassung von "grep"s (o.ae.) zum Reflex werden zu lassen. Nein, meine .bash_history zeig ich nicht her! ;) [..]
Oder in diesem einfachen Falle: sed -n '/^[^#*]passwordfd/p'
Was ja nix anderes als grep mit der RegEx wäre ;-)
Eben :) sed "kann" eine Obermenge dessen, was grep kann (ich hab' heut hier ein anderes IMHO nettes Beispiel gemailt: gleichzeitig 'head -2' plus 'tail -2' ;)
Achso: "echt" aequivalent zu Christians grep-Konstrukt waere wohl:
sed -n '/passwordfd/{/^#/d;p;}'
[erst: nur Zeilen mit passwordfd ausfiltern, dann Kommentare loeschen und dann den Rest ausgeben...]
Ah, der Bereichsoperator. Den hast Du mir ja mal recht ausführlich per PM erklärt.
Ah, ja, stimmt, du warst das :))
Ich glaube sogar, dass ich die Erklärung noch halbwegs im Kopf habe ;-) (BTW: wolltest Du die Erklärung nicht mal irgendwo auf Deiner Homepage einbauen?)
Jo, mal schauen... Aber auf meiner HP gibt's wichtigeres zu tun... *seufz* *ichhassehtml*
-dnh, grep, sed, awk und perl in eben diese Stufung verwendend...
Schöne Zusammenstellung ;-)
*g* IMHO: Diese Reihenfolge entspricht eben (IMHO) der "Maechtigkeit". Man kann das jew. zuerst genannte Programm durch alle jew. danach genannten Programme[1] "nachbilden" ('grep foo bar' in perl?: "perl -pe '$_ if /foo/;' bar") Allerdings gibt's eben in eben dieser Reihenfolge auch einen "Performance"-Malus (der zumindest bei "Einzeilern" bei perl beim "startup" oft signifikant ist)... $ T='find . -type f -maxdepth 1' $ time $T > /dev/null real 0m0.064s $ time $T | xargs echo >/dev/null 2>&1 real 0m0.077s $ time $T | xargs grep foo >/dev/null 2>&1 real 0m0.807s $ time $T | xargs sed -n '/foo/p' >/dev/null 2>&1 real 0m9.067s $ time $T | xargs awk '/foo/{print}'/dev/null 2>&1 real 0m4.676s $ time $T | xargs perl -pe 'if(/foo/) {$_;}' >/dev/null 2>&1 real 0m4.651s $ time $T | xargs perl -pe '$_ if /foo/' >/dev/null 2>&1 real 0m4.646s $ unset T [hab ich die Zeilenlaenge nicht "schick" verkuerzt? *scnr*] Warum sed bei diesem Beispiel aber so elendiglich lahm ist, ist mir schleierhaft... Naja... Jedenfalls: es gibt gute Gruende, das jew. einfachste Programm zu verwenden, mit dem die geforderte Aufgabe geloest werden kann...
Ich habe nur das Problem, dass ich von awk gar keine und von perl (schreibend) recht wenig Ahnung habe ;-)
Naja, zu awk finden sich hier ja im Archiv inzwischen einige gute Beispiele und die Doku (v.a. das 'info gawk') ist recht gut. Mit awk lassen sich halt sehr viele Sachen performant "erschlagen", fuer die man sonst perl bemuehen muesste... Klassisches Beispiel ist das aufsummieren von irgendwelchen Werten, z.B. von ls, oder von df... ==== ein Stueck (der "Kern") aus ~/bin/dfall und gekuerzt ==== df $DFARGS \ | awk ' BEGIN { CONVFMT="%i"; } /^Filesystem/{ printf "%-12s %-9s %14s %14s %14s %s %s %s\n", $1, $2, $3, $4, $5, $6, $7, $8; } !/^Filesystem/{ blks+=$2; used+=$3; avail+=$4; printf "%-12s %14s %14s %14s %4s %s\n", $1, $2, $3, $4, $5, $6; } END{ CONVFMT="%.6g"; # default percent=((used * 100.00) / blks); printf "%37s %14s %14s %-4s\n", "--------------", "--------------", "--------------", "----"; printf "%-12s %14.f %14.f %14.f% 6.1f%s\n", " ", blks, used, avail, percent, "%" ; printf "%22s %14.f %14.f %14.f\n", "unit/1024:", blks/1024, used/1024, avail/1024; }' ==== Das ohne perl nachzubilden waere ein recht grosser Aufwand... Und in perl wuerde der code recht aehnlich aussehen ;) Kurz: awk lohnt sich :) Ahso: Die Ausgabe von dfall ist z.B.: ==== $ dfall | tail -4 /dev/hda10 26153976 23862372 963032 96% /data2 -------------- -------------- -------------- ---- 87324676 74284576 8604180 85.1% unit/1024: 85278 72544 8403 ==== [note: das script muss ich nochmal ueberarbeiten, vorab => PM]
Naja, perl eigne ich mir gaaanz langsam an ;-)
Auch das lohnt sich!
PS: keine Zufallssig (oder ist mir da eine Mail abhanden gekommen?)
Nein.
--
Daaaaaavid, wo bleibt eigentlich mal 'ne anständige Statistik? *JAUL* Ich mach ja schon... [Ratti und David Haller in suse-linux]
Jup. Sorry! Koemmt RSN. -dnh [1] Ausnahme: awk kann IIRC eine Sache, die in perl umstaendig geschrieben werden muesste. In der perl-Doku steht dazu (IIRC): "awk has to be better for something" *g* -- Oh, I am a C programmer and I'm okay I muck with indices and structs all day And when it works, I shout hoo-ray Oh, I am a C programmer and I'm okay [BSD fortune file]
Hallo David, hallo Leute, Am Freitag, 17. Januar 2003 06:56 schrieb David Haller:
On Thu, 16 Jan 2003, Christian Boltz wrote:
David, willst Du mir etwa einen Award verleihen? ;-)
Nein ;) Aber die Tendenz dazu, dass es in Richtung eines solchen Awards geht, andeuten wollend ;)
;-)
Am Mittwoch, 15. Januar 2003 05:21 schrieb David Haller:
On Tue, 14 Jan 2003, Christian Boltz wrote:
grep passwordfd /etc/ppp/options | grep -v "^#"
*tsk*
Christian, willst du nicht mal ein wenig ueber 'man grep', 'man sed', v.a. aber ueber 'man 7 regex' "meditieren"? *scnr*
s/l /&wieder /
;-)
"Wollen" schon, aber derzeit treibe ich mich eher mit vi in der aktuellen Fontlinge-CVS-Version herum ;-)
Ahso. Dann is gut. Da is noch einiges zu tun
Du hast aber schon die CVS-Version getestet, oder? Also, was ist noch alles zu machen? Bugs, Probleme, unverständliches oder umständliches (Bedienung der Scripte?) und/oder Verbesserungsvorschläge kannst Du mir gern mal mailen - oder gleich auf fontlinge-devel ;-) (BTW: falls per PM, bitte dazuschreiben, ob ich es auf fontlinge-devel weiterleiten darf/soll)
(hab neulich mal reingeschaut)... *veg* Loeblich das, also :))
*freu*
Ach so: ich hätte mir die passende RegEx
grep '^[^#]*passwordfd' ...
schon zusammenbasteln können (zumindest die Grundlagen von RegEx habe ich inzwischen im Kopf), aber ein hinterhergejagtes | grep -v geht mir (noch...) leichter aus der Hand ;-)
Ja, mir auch! Aber ich bemuehe mich, zumindest wenn ich dann sowas in mails schreibe, das dann schon wegzuoptimieren, bzw. mir so eine Zusammenfassung von "grep"s (o.ae.) zum Reflex werden zu lassen.
Nein, meine .bash_history zeig ich nicht her! ;)
*LoL*
[..]
Oder in diesem einfachen Falle: sed -n '/^[^#*]passwordfd/p'
Was ja nix anderes als grep mit der RegEx wäre ;-)
Eben :) sed "kann" eine Obermenge dessen, was grep kann (ich hab' heut hier ein anderes IMHO nettes Beispiel gemailt: gleichzeitig 'head -2' plus 'tail -2' ;)
Klar.
-dnh, grep, sed, awk und perl in eben diese Stufung verwendend...
Schöne Zusammenstellung ;-)
*g*
IMHO: Diese Reihenfolge entspricht eben (IMHO) der "Maechtigkeit". Man kann das jew. zuerst genannte Programm durch alle jew. danach genannten Programme[1] "nachbilden" ('grep foo bar' in perl?: "perl -pe '$_ if /foo/;' bar")
Allerdings gibt's eben in eben dieser Reihenfolge auch einen "Performance"-Malus (der zumindest bei "Einzeilern" bei perl beim "startup" oft signifikant ist)...
Jepp, klar.
Jedenfalls: es gibt gute Gruende, das jew. einfachste Programm zu verwenden, mit dem die geforderte Aufgabe geloest werden kann...
Klar, aber wie gesagt:
Ich habe nur das Problem, dass ich von awk gar keine und von perl (schreibend) recht wenig Ahnung habe ;-)
Naja, zu awk finden sich hier ja im Archiv inzwischen einige gute Beispiele und die Doku (v.a. das 'info gawk') ist recht gut. Mit awk lassen sich halt sehr viele Sachen performant "erschlagen", fuer die man sonst perl bemuehen muesste...
Ja, klar, aber die unterschiedliche Syntax für soviele verschiedene Programme ist ja auch nicht immer ganz leicht zu merken. Außerdem braucht jede Sprache Einarbeitungszeit - mal mehr, mal weniger. Da ich ja als Winzer nur abends oder sonntags an den Computer komme, beschränke ich mich da eben auf die Programmiersprachen [1], die ich öfters brauchen kann, z. B. Bash, PHP und seit kurzem ein wenig Perl.
Klassisches Beispiel ist das aufsummieren von irgendwelchen Werten, z.B. von ls, oder von df...
==== ein Stueck (der "Kern") aus ~/bin/dfall und gekuerzt ==== [...]
Interessant. Wenn ich so ein Beispiel mal irgendwo (z. B. in der Liste) finde, kann es durchaus sein, dass ich es auch verwende. Aber zum awk lernen konnte ich mich bisher nicht entschließen ;-)
Das ohne perl nachzubilden waere ein recht grosser Aufwand... Und in perl wuerde der code recht aehnlich aussehen ;)
Kurz: awk lohnt sich :)
... wenn man genug Zeit zum Lernen hat ;-)
Naja, perl eigne ich mir gaaanz langsam an ;-)
Auch das lohnt sich!
;-) Gruß Christian Boltz [1] "Programmiersprachen" in diesem Zusammenhang bitte etwas weiter auslegen. Ich zähle z. B. in diesem Fall auch awk dazu, obwohl das eigentlich nur ein kleines Programm und keine Programmiersprache im eigentlichen Sinn ist ;-) --
Hat jemand eine derartige Konstellation und kann mir kurz den Kopp auf die Tischplatte haun ? ;-) *autsch* Tut das nicht weh? [> Oli Weiss und Christian Boltz in suse-linux]
Hallo, On Fri, 17 Jan 2003, Christian Boltz wrote:
Am Freitag, 17. Januar 2003 06:56 schrieb David Haller:
On Thu, 16 Jan 2003, Christian Boltz wrote:
"Wollen" schon, aber derzeit treibe ich mich eher mit vi in der aktuellen Fontlinge-CVS-Version herum ;-) Ahso. Dann is gut. Da is noch einiges zu tun Du hast aber schon die CVS-Version getestet, oder?
Nein. Getestet noch gar nicht *eg*
Also, was ist noch alles zu machen? [..]
(hab neulich mal reingeschaut)... *veg* Loeblich das, also :)) *freu*
Wenn ich was seh, werde ich mich vertrauensvoll an euch wenden ;) [..]
Nein, meine .bash_history zeig ich nicht her! ;)
*LoL*
Ja, ich nehm auch oefter haarstraeubende Umwege! Ich Dubbel hab mir heute doch glatt mal die ~/.bashrc genullt! Mit nem tee... *ARGH* Sowas dummes hab ich schon lange nicht mehr veranstaltet (zum Glueck ;) Naja, ich hab diverse Kopien davon, die letzte war zwar nicht ganz aktuell, aber die eine Aenderung (oder so) seitdem war nicht so wichtig (und gross ist meine .bashrc sowieso nicht) *lol* [..]
Jedenfalls: es gibt gute Gruende, das jew. einfachste Programm zu verwenden, mit dem die geforderte Aufgabe geloest werden kann...
Klar, aber wie gesagt:
Ich habe nur das Problem, dass ich von awk gar keine und von perl (schreibend) recht wenig Ahnung habe ;-)
Naja, zu awk finden sich hier ja im Archiv inzwischen einige gute Beispiele und die Doku (v.a. das 'info gawk') ist recht gut. Mit awk lassen sich halt sehr viele Sachen performant "erschlagen", fuer die man sonst perl bemuehen muesste...
Ja, klar, aber die unterschiedliche Syntax für soviele verschiedene Programme ist ja auch nicht immer ganz leicht zu merken.
Och, soviel ist das nun auch nicht. Gerade sed hat ja eine sehr ueberschaubare Syntax, und die von awk ist auch recht einfach. Und die Gemeinsamkeiten sind doch immer wieder interessant. "Merken" muss man sich aber sowieso nur "sed kann ...", "awk kann ..." und perl den rest ;) Die Details (also z.B. wie ein 'gsub' in awk "parametriert" ist o.ae.), sowas hat man schnell mal eben in der manpage nachgeschlagen! (wobei bei awk die info ausfuehrlicher ist, aber die manpage reicht mir bei sowas meist ;) Hm. Da faellt mir ein, ich sollte mir doch endlich 'man bash' komplett reinziehen oder gar ausdrucken, hab die Tage mal wieder was komplett neues gelernt (extglob is "cool" ;) Der "Trick" ist IMO generell nicht, dass man irgendwas auswendig kann, sondern dass man sich merkt, wo's $PROGGIE dokumentiert ist -- und sei's im Web... Denk einfach mal an perl! Wolltest du da alle Module "beherrschen", dann koenntest du dir wohl kaum noch sonst was merken. Das ist also uninteressant. Interessant ist, wie du mit man/perldoc oder ggfs. less (bei !pod-dokumentiertem Zeug) an die Infos rankommst.
Außerdem braucht jede Sprache Einarbeitungszeit - mal mehr, mal weniger.
Ack. Aber gerade sed/awk erstaunlich wenig, fuer das was man damit machen kann ;)
Da ich ja als Winzer
Huch? ->f'up2p
nur abends oder sonntags an den Computer komme, beschränke ich mich da eben auf die Programmiersprachen [1], die ich öfters brauchen kann, z. B. Bash, PHP und seit kurzem ein wenig Perl.
php kann man fuer mehr als einen CGI-Ersatz verwenden? Auch performance-maessig?
Klassisches Beispiel ist das aufsummieren von irgendwelchen Werten, z.B. von ls, oder von df...
==== ein Stueck (der "Kern") aus ~/bin/dfall und gekuerzt ==== [...]
Interessant. Wenn ich so ein Beispiel mal irgendwo (z. B. in der Liste) finde, kann es durchaus sein, dass ich es auch verwende. Aber zum awk lernen konnte ich mich bisher nicht entschließen ;-)
Glaub mir, es lohnt sich ;) Ich bin selbst noch awk-Neuling (und kannte davor u.a. sed und perl), aber (g)awk ist oft einfach 1. verdammt elegant und 2. obendrein performant... mal abgesehen von dem printf gewuerge (das man ja u.a. auch von printf(3), printf(1) und perl kennt) in meinem "dfall" Beispiel... Allerdings ist printf z.B. immer noch wesentlich angenehmer als 'cout' in C++... Oder "System.out.println"[2] *schauder*... Achso, wenn ich hier (ohne laengeren Kommentar) mal solche Schnipsel absonder, erklaeren wuerde ich sie bei Interesse/Nachfrage[1] meist, nicht immer aber in aller Ausfuehrlichkeit ;) manpage lesen (die englischen!) will ich nicht ersetzen -- aber beim Verstehen derselben (z.B. wenn's an der Sprache hapert) helfe ich gern ;)
Kurz: awk lohnt sich :)
... wenn man genug Zeit zum Lernen hat ;-)
IMHO: nicht nur dann ;) [sig] Hui! Da hab ich was verpasst *snarf* *g* -dnh ObSigComment: me, I prefer off-white on black ;) [1] ich habe keine Lust (bzw. hab's mir abgewoehnt) zu so nem Schnipsel, sagen wir, ne halbe Stunde ne Erklaerung "ins Blaue" zu schreiben... Wenn's jemand wirklich interessiert und trotz manpage Studium nicht versteht kann der/die ja Nachfragen... [2] und das mir, der schon zu nem '#define p printf' tendiert ;) Wer behauptet hier ich sei faul??? (der hat recht ;) --
I hate black text on a white background on CRTs. Too damned bright. You're right. Black text on a black background is so much more restful. -- J. Bowden and Tanuki in asr
Hallo David, hallo Leute, Am Samstag, 18. Januar 2003 07:09 schrieb David Haller:
On Fri, 17 Jan 2003, Christian Boltz wrote:
Am Freitag, 17. Januar 2003 06:56 schrieb David Haller:
On Thu, 16 Jan 2003, Christian Boltz wrote: [Fontlinge] [...] (hab neulich mal reingeschaut)... *veg* Loeblich das, also :))
*freu*
Wenn ich was seh, werde ich mich vertrauensvoll an euch wenden ;)
Schön ;-)
[..]
Nein, meine .bash_history zeig ich nicht her! ;)
*LoL*
Ja, ich nehm auch oefter haarstraeubende Umwege! Ich Dubbel hab mir heute doch glatt mal die ~/.bashrc genullt! Mit nem tee... *ARGH* Sowas dummes hab ich schon lange nicht mehr veranstaltet (zum Glueck ;) Naja, ich hab diverse Kopien davon, die letzte war zwar nicht ganz aktuell, aber die eine Aenderung (oder so) seitdem war nicht so wichtig (und gross ist meine .bashrc sowieso nicht) *lol*
Naja, Fehler kommen ja immer wieder mal vor ;-)
Ja, klar, aber die unterschiedliche Syntax für soviele verschiedene Programme ist ja auch nicht immer ganz leicht zu merken.
Och, soviel ist das nun auch nicht. Gerade sed hat ja eine sehr ueberschaubare Syntax, und die von awk ist auch recht einfach. Und die Gemeinsamkeiten sind doch immer wieder interessant. "Merken" muss man sich aber sowieso nur "sed kann ...", "awk kann ..." und perl den rest ;) Die Details (also z.B. wie ein 'gsub' in awk "parametriert" ist o.ae.), sowas hat man schnell mal eben in der manpage nachgeschlagen! (wobei bei awk die info ausfuehrlicher ist, aber die manpage reicht mir bei sowas meist ;)
Klar, aber wie immer ein "aber": Bevor ich (für einmalige Anwendung) lange in den Manpages stöbere, geht es meist schneller, einen weniger performanten Befehl (oder Befehlskette) zu verwenden ;-) Wenn ich mir mal ein Script schreibe, das häufig läuft oder schon von Haus aus eine sehr lange Laufzeit hat, schau ich dann erster mal auf die Performance ;-)
Hm. Da faellt mir ein, ich sollte mir doch endlich 'man bash' komplett reinziehen oder gar ausdrucken, hab die Tage mal wieder was komplett neues gelernt (extglob is "cool" ;)
;-) Ich richte mir übrigens gerade eine .bash_complete ein (ist keine übliche Datei, aber der Name erschien mir passend ;-) Da stehen dann etliche complete-Befehle drin, die mir hinterher Tipparbeit sparen (z. B. alle --options für fontlinge_* ;-)
Der "Trick" ist IMO generell nicht, dass man irgendwas auswendig kann, sondern dass man sich merkt, wo's $PROGGIE dokumentiert ist -- und sei's im Web... Denk einfach mal an perl! Wolltest du da alle Module "beherrschen", dann koenntest du dir wohl kaum noch sonst was merken. Das ist also uninteressant. Interessant ist, wie du mit man/perldoc oder ggfs. less (bei !pod-dokumentiertem Zeug) an die Infos rankommst.
Jepp.
Außerdem braucht jede Sprache Einarbeitungszeit - mal mehr, mal weniger.
Ack. Aber gerade sed/awk erstaunlich wenig, fuer das was man damit machen kann ;)
Da ich ja als Winzer
Huch? ->f'up2p
Ja, da staunst Du, was? Ich hab jetzt 3 Jare Lehrzeit und 2 Wintersemester für den "Staatlich geprüften Wirtschafter [...]" (den vollen Titel spar ich Dir mal ;-) hinter mir und bin jetzt an den Vorbereitungen für die Meisterprüfung. Ich bastle aber nebenbei auch an ein paar Webseiten, z. B. die Seite der Schülerarbeiten der SLFA Neustadt und der Homepage des Netzwerks europäischer Weinbauschulen http://www.wein-vin-vinum.net (Design ist nicht von mir, dafür aber der HTML- und PHP-Code) Ach so, wegen des f'up: Da es nur ein paar Zeilen geworden sind, hab ichs noch in diese Mail eingebaut. Wir können uns aber gern per PM weiterunterhalten ;-)
nur abends oder sonntags an den Computer komme, beschränke ich mich da eben auf die Programmiersprachen [1], die ich öfters brauchen kann, z. B. Bash, PHP und seit kurzem ein wenig Perl.
php kann man fuer mehr als einen CGI-Ersatz verwenden?Auch performance-maessig?
Gute Frage. Ich habe die Performance noch nicht getestet, hatte aber noch keine Probleme damit. Es kommt wohl immer darauf an, was man machen will. Für komplexe Aufgaben/Scripte, die hinterher dann aber nur wenig Output liefern, ist wohl ein CGI besser. Wenn man aber nur z. B. eine Sprachumschaltung, einfach zu handelnde Menüs (Einträge und Optik getrennt und hinterher include'd) oder eine automagisch gebaute Sitemap (aus den Menüdateien gebaut) will, ist PHP IMHO einfacher zu handhaben, da man es nach Belieben in HTML-Code einbetten kann (z. B. <a href="test.php?lang=<?php echo $lang ?>">), die automagische Sitemap ist natürlich ein wenig aufwendiger ;-) Außerdem hab ich bei wein-vin-vinum.net nur PHP zur Verfügung und keine CGIs. Hat mich aber bisher nicht gestört ;-) BTW: Wenn Du die Performance von PHP mal testen willst, probier z. B. mal die Fontlinge WebGUI aus und lass dann viele Schriftarten auf einmal anzeigen. Falls Du dann noch Lust hast, das Ganze als CGI nachzubauen... [...]
Interessant. Wenn ich so ein Beispiel mal irgendwo (z. B. in der Liste) finde, kann es durchaus sein, dass ich es auch verwende. Aber zum awk lernen konnte ich mich bisher nicht entschließen ;-)
Glaub mir, es lohnt sich ;) Ich bin selbst noch awk-Neuling (und kannte davor u.a. sed und perl), aber (g)awk ist oft einfach 1. verdammt elegant und 2. obendrein performant... mal abgesehen von dem printf gewuerge (das man ja u.a. auch von printf(3), printf(1) und perl kennt) in meinem "dfall" Beispiel... Allerdings ist printf z.B. immer noch wesentlich angenehmer als 'cout' in C++... Oder "System.out.println"[2] *schauder*...
;-) Wie gesagt, wegen Zeitmangel bleibe ich derzeit lieber bei den bekannten Programmen.
Achso, wenn ich hier (ohne laengeren Kommentar) mal solche Schnipsel absonder, erklaeren wuerde ich sie bei Interesse/Nachfrage[1] meist, nicht immer aber in aller Ausfuehrlichkeit ;) manpage lesen (die englischen!) will ich nicht ersetzen -- aber beim Verstehen derselben (z.B. wenn's an der Sprache hapert) helfe ich gern ;)
Jepp, klar.
Kurz: awk lohnt sich :)
... wenn man genug Zeit zum Lernen hat ;-)
IMHO: nicht nur dann ;)
Ja, aber ohne Zeit zum Lernen wird es wohl nix ;-)
[2] und das mir, der schon zu nem '#define p printf' tendiert ;) Wer behauptet hier ich sei faul??? (der hat recht ;)
*g* Ich bin ja auch manchmal faul, z. B. bau ich in PHP gelegentlich Links mit einer Funktion makelink($description, $url) anstatt direkt mit <a href> (ist übrigens auch übersichtlicher ;-) . Oder ich lass mir die Sitemap automatisch basteln. Oder beim Login automatisch /v/l/m und eine Konsole (mit fontlinge-cvs als Startverzeichnis), dazu KMail und den Konquereor öffnen. Oder ich trage mir die --long-options von Programmen als complete-Befehl in einem Script ein, das beim Login ausgeführt wird. Oder... (Wo wir gerade beim Thema sind - ich bin gerade zu faul, um diese Liste fortzusetzen ;-) Gruß Christian Boltz -- Auaauaaua, sorry, Leute, das war nicht gewollt, da hat mir KMail nen Streich gespielt (Wieso probier ich Depp das überhaupt, wenn ich Mutt hab?) Tschulljung. [Thomas Dreher in suse-linux]
Hallo, On Sun, 19 Jan 2003, Christian Boltz wrote:
Am Samstag, 18. Januar 2003 07:09 schrieb David Haller:
On Fri, 17 Jan 2003, Christian Boltz wrote:
Am Freitag, 17. Januar 2003 06:56 schrieb David Haller:
On Thu, 16 Jan 2003, Christian Boltz wrote: Ja, klar, aber die unterschiedliche Syntax für soviele verschiedene Programme ist ja auch nicht immer ganz leicht zu merken.
Och, soviel ist das nun auch nicht. Gerade sed hat ja eine sehr ueberschaubare Syntax, und die von awk ist auch recht einfach. Und die Gemeinsamkeiten sind doch immer wieder interessant. "Merken" muss man sich aber sowieso nur "sed kann ...", "awk kann ..." und perl den rest ;) Die Details (also z.B. wie ein 'gsub' in awk "parametriert" ist o.ae.), sowas hat man schnell mal eben in der manpage nachgeschlagen! (wobei bei awk die info ausfuehrlicher ist, aber die manpage reicht mir bei sowas meist ;)
Klar, aber wie immer ein "aber": Bevor ich (für einmalige Anwendung) lange in den Manpages stöbere, geht es meist schneller, einen weniger performanten Befehl (oder Befehlskette) zu verwenden ;-)
Mir geht's eher um den Lerneffekt -- wenn man's nicht verwendet, dann lernt man nie, was damit alles geht und verwendet dann z.B. komplizierteste Konstrukte mit bash/sed z.B. was ein paar Zeichen in awk elegant loesen... Ich erinnere ans aufsummieren: ==== df | awk ' BEGIN { sum = 0; } ! /^F/ { ## Zeilenfilter, ggfs. ueberfluessig, ersetzt aber ## z.B. ein grep [-v] vorher sum += $4; ## aufsummieren } END { print sum; ## und am ENDe die summe ausgeben. }' ==== Ja, das kann man so in der shell _inklusive_ Kommentaren eingeben. Es geht aber natuerlich auch knapper (v.a. da Variablen automatisch verwendet werden koennen), z.B.: df | awk '!/^F/{s+=$4}END{print s}' Mach das mal mit bash / sed (aber ohne awk/perl)... Ein weiteres Beispiel was sich wunderbar erschlagen liesse, waere z.B. Dateilistings auszuwerten, z.B.: ==== find /usr/src/linux/ -type f -printf "%t\n" | awk ' { wd[$1]++ yr[$5]++ } END { sort="sort +1 -rn" for(d in wd) print d" "wd[d] | sort close(sort) for(y in yr) print y" "yr[y] | sort close(sort) }' ==== (das zweite 'close(sort)' kann man auch weglassen) Und du siehst, dass Kernelentwickler wenig an Montagen, aber viel an Donnerstagen arbeiten ;) Zum Vergleich hab ich das auch mal in perl gemacht: ==== find /usr/src/linux/ -type f -printf "%t\n" | perl -ne ' chomp; split(/\s+/); $wd{$_[0]}++; $yr{$_[4]}++; END { foreach ( sort { $wd{$b} <=> $wd{$a} } (keys %wd) ) { print "$_ $wd{$_}\n"; } foreach ( sort{ $yr{$b} <=> $yr{$a} } (keys %yr) ) { print "$_ $yr{$_}\n"; } }' ==== Beide Varianten sind (bei mir, mit und ohne das 'find' davor) in etwa gleich schnell. Allerdings find ich das mit dem sortieren eher suboptimal (im Vergleich zur awk-Loesung)... Und ja, in perl ist man flexibler, "ich mag perl"[tm] [1] ;) Ich will grep _und_ sed _und_ awk _und_ perl! Da das 'find' vornedran aber die meiste Zeit verbraucht, hab ich beides mal ueber vom 'find' erzeugte Datei laufen lassen: real: beide etwa gleich (~.600s) awk: user 0m0.120s (schwankt zw. .100 und .150) perl: user 0m0.190s (zw. .180 und .200) Naja, wie gesagt, die "Performance" spielt nicht die grosse Rolle... Aber: Auffallend, wie sehr sich awk und perl aehneln, man kann's sogar noch genauer uebernehmen ( '| sort' via pipe(2) (lt. strace)): ==== find /usr/src/linux/ -type f -printf "%t\n" | perl -ne ' chomp; split(/\s+/); $wd{$_[0]}++; $yr{$_[4]}++; END { open(SORT, "|sort +1 -rn") or die $!; foreach (keys %wd) { print SORT "$_ $wd{$_}\n"; } close(SORT); open(SORT, "|sort +1 -rn") or die $!; foreach (keys %yr) { print SORT "$_ $yr{$_}\n"; } close(SORT); }' ==== Das witzige ist (IMO), dass perl auch so ca. gleichschnell ist, ich haette gedacht, die pipes waeren "teurer" ;)
Wenn ich mir mal ein Script schreibe, das häufig läuft oder schon von Haus aus eine sehr lange Laufzeit hat, schau ich dann erster mal auf die Performance ;-)
Mir geht's mehr um die Effektivitaet (der "Arbeit"), zu der die "Performance" nur einen Teil beitraegt. Aber ich _achte_ auf die Performance. Natuerlich haenge ich oefter mal einfach ein 'grep -v blubb' noch hinter ne laengere "Piperei", aber ab einer gewissen Anzahl von Pipes und/oder "Verrenkungen" frag ich mich, ob es nicht hoechste Eisenbahn wird, ein paar davon mittels sed/awk/perl wegzurationalisieren. ;) Naja, wenn z.B. ein 'java -jar' oder so beteiligt ist, dann spielt das sicher auch keine Rolle mehr *g*
Ich richte mir übrigens gerade eine .bash_complete ein (ist keine übliche Datei, aber der Name erschien mir passend ;-) Da stehen dann etliche complete-Befehle drin, ^^^^^^^^^^^^^^^^?
nur abends oder sonntags an den Computer komme, beschränke ich mich da eben auf die Programmiersprachen [1], die ich öfters brauchen kann, z. B. Bash, PHP und seit kurzem ein wenig Perl.
php kann man fuer mehr als einen CGI-Ersatz verwenden?Auch performance-maessig?
Gute Frage. Ich habe die Performance noch nicht getestet, hatte aber noch keine Probleme damit. Es kommt wohl immer darauf an, was man machen will. Für komplexe Aufgaben/Scripte, die hinterher dann aber nur wenig Output liefern, ist wohl ein CGI besser.
Jo. Zumal hier, mit php-3.0.11 (ohne ZEND)... ;) Wobei: php hat doch nen Kommandozeilen/"script" Modus, oder? *hehe* dann koennte man perverserweise php fuer CGI nehmen! Besser ist natuerlich perl (da bes. mit caching recht performant), oder C++, oder C... Besonders bei C muss man aber hoellisch aufpassen, dass man keine ganze Serie von Scheunentoren ins System aufmacht...
Wenn man aber nur z. B. eine Sprachumschaltung, einfach zu handelnde Menüs (Einträge und Optik getrennt und hinterher include'd) oder eine automagisch gebaute Sitemap (aus den Menüdateien gebaut) will, ist PHP IMHO einfacher zu handhaben, da man es nach Belieben in HTML-Code einbetten kann (z. B. <a href="test.php?lang=<?php echo $lang ?>">),
if(HTTPD == "Apache") { [ ] du kennst das Feature von Apache, zuerst Dateien $name.$lang auszuliefern, sofern vorhanden? Also z.B. test.php.de statt test.php, wenn lang=de? Also quasi macht Apache dann: if test -f "$URL.$lang"; then return "$URL.$lang"; else if test -f "$URL"; return "$URL"; else return 404; fi; fi Und das bei allen Dateien (AFAIR). }
die automagische Sitemap ist natürlich ein wenig aufwendiger ;-)
perldoc HTML::GenToc
Außerdem hab ich bei wein-vin-vinum.net nur PHP zur Verfügung und keine CGIs. Hat mich aber bisher nicht gestört ;-)
Bei mir waere's genau andersrum, aber ich such mir grad eh nen Web-Hoster/Email-Provider, und da achte ich u.a. darauf ;)
BTW: Wenn Du die Performance von PHP mal testen willst, probier z. B. mal die Fontlinge WebGUI aus und lass dann viele Schriftarten auf einmal anzeigen.
Mal schauen ;)
Falls Du dann noch Lust hast, das Ganze als CGI nachzubauen...
*g*
[...]
Interessant. Wenn ich so ein Beispiel mal irgendwo (z. B. in der Liste) finde, kann es durchaus sein, dass ich es auch verwende. Aber zum awk lernen konnte ich mich bisher nicht entschließen ;-)
*hehe* s.o.
Glaub mir, es lohnt sich ;) [..] ;-) Wie gesagt, wegen Zeitmangel bleibe ich derzeit lieber bei den bekannten Programmen.
s.o. Das schoene an den genannten Tools ist ja, dass du die bisherige Arbeit oft uebernehmen kannst... Von grep nach sed nach awk nach perl, und awk z.B. ist IMO schon dann sehr praktisch, wenn du nur etwas meht als ein awk '{print $4}' kennst.
[2] und das mir, der schon zu nem '#define p printf' tendiert ;) Wer behauptet hier ich sei faul??? (der hat recht ;)
*g* Ich bin ja auch manchmal faul, z. B. [..] Oder... (Wo wir gerade beim Thema sind - ich bin gerade zu faul, um diese Liste fortzusetzen ;-)
*g* -dnh [1] muss mal nach nem TMTOWTDI T-Shirt schauen ;) -- 25: Multithreaded Wir mußten ein Flußdiagramm malen, um es zu debuggen. (Kristian Köhntopp)
Hallo David, hallo Leute, Am Montag, 20. Januar 2003 07:16 schrieb David Haller:
On Sun, 19 Jan 2003, Christian Boltz wrote:
Am Samstag, 18. Januar 2003 07:09 schrieb David Haller:
On Fri, 17 Jan 2003, Christian Boltz wrote: [...] Klar, aber wie immer ein "aber": Bevor ich (für einmalige Anwendung) lange in den Manpages stöbere, geht es meist schneller, einen weniger performanten Befehl (oder Befehlskette) zu verwenden ;-)
Mir geht's eher um den Lerneffekt -- wenn man's nicht verwendet, dann lernt man nie, was damit alles geht
ist ein Argument ;-)
und verwendet dann z.B. komplizierteste Konstrukte mit bash/sed z.B. was ein paar Zeichen in awk elegant loesen... Ich erinnere ans aufsummieren:
==== df | awk ' BEGIN { sum = 0; } ! /^F/ { ## Zeilenfilter, ggfs. ueberfluessig, ersetzt aber ## z.B. ein grep [-v] vorher sum += $4; ## aufsummieren } END { print sum; ## und am ENDe die summe ausgeben. }' ====
Ja, das kann man so in der shell _inklusive_ Kommentaren eingeben. Es geht aber natuerlich auch knapper (v.a. da Variablen automatisch verwendet werden koennen), z.B.:
df | awk '!/^F/{s+=$4}END{print s}'
Mach das mal mit bash / sed (aber ohne awk/perl)...
Geht sogar ohne sed, nur mit bash ;-) df | { while read line ; do set -- $line sum=$[ $sum + $4 ] done echo $sum } Ich behaupte ja nicht, dass das einfacher ist, aber es geht ;-) BTW: Die Klammerung mit {} deshalb, da ja durch die Pipe eine Subshell geöffnet wird und $sum nach Ende der Schleife (=Subshell) nicht mehr verfügbar wäre :-| Die {} Klammern erzeugen ja auch keinen eigenen Prozess im Gegensatz zu () ;-)
Ein weiteres Beispiel was sich wunderbar erschlagen liesse, waere z.B. Dateilistings auszuwerten, z.B.:
Ich versuch das mal zu verstehen.
==== find /usr/src/linux/ -type f -printf "%t\n" | awk '
Also, find liefert Zeilen mit dem Dateidatum a la Tue Jul 31 19:30:08 2001
{ wd[$1]++ yr[$5]++ }
Jetzt zählt Du für $1 (Wochentag) und $5 (Jahr) zusammen, und zwar geschickterweise in einem Array mit den Keys $1, also "Mon", "Tue" usw. Das gleiche natürlich fürs Jahr. Nette Idee, ein Array so zu missbrauchen ;-)
END {
Wird wohl erst ausgeführt, wenn obiges beendet ist, also keine weitere Eingabedaten mehr kommen.
sort="sort +1 -rn"
???
for(d in wd) print d" "wd[d] | sort close(sort)
Sehe ich das richtig, dass Du hier die Wochentage (und weiter unten die Jahreszahlen) an sort pipst, also awk gar nicht selber sortiert?
for(y in yr) print y" "yr[y] | sort close(sort) }' ====
(das zweite 'close(sort)' kann man auch weglassen)
Na denn. Wenn ich man awk richtig verstehe, wird hier die Pipe (was meine obige Theorie bestätigt ;-) wieder geschlossen. Klar, braucht man nicht, wenn das Programm eh zu Ende ist. (MIST! Jetzt hast Du mich doch dazu gebracht, mir Zeit für awk zu nehmen ;-)
Und du siehst, dass Kernelentwickler wenig an Montagen, aber viel an Donnerstagen arbeiten ;)
*g* Schön, dann hab ich ja gleich mehr Vertrauen in den Kernel, wenn es kein Montagsmodell ist ;-)
Zum Vergleich hab ich das auch mal in perl gemacht:
==== find /usr/src/linux/ -type f -printf "%t\n" | perl -ne ' chomp; split(/\s+/); $wd{$_[0]}++; $yr{$_[4]}++; END {
Soweit OK und einigermaßen klar, aber...
foreach ( sort { $wd{$b} <=> $wd{$a} } (keys %wd) ) { print "$_ $wd{$_}\n"; } foreach ( sort{ $yr{$b} <=> $yr{$a} } (keys %yr) ) { print "$_ $yr{$_}\n"; }
... awk hat nicht selbst sortieren müssen ;-) (und die Sortierung, wie Du sie von Perl hier machen lässt, hängt mir noch ein wenig zu hoch ;-) Liegt wohl daran, dass ich mit Perl auch erst angefangen habe.)
}' ====
Beide Varianten sind (bei mir, mit und ohne das 'find' davor) in etwa gleich schnell. Allerdings find ich das mit dem sortieren eher suboptimal (im Vergleich zur awk-Loesung)...
Naja, in awk hast Du, soweit ich das verstehe, die Daten einfach an sort gepiped, das kann man also IMHO nicht direkt vergleichen.
Und ja, in perl ist man flexibler, "ich mag perl"[tm] [1] ;) Ich will grep _und_ sed _und_ awk _und_ perl!
;-)
Aber: Auffallend, wie sehr sich awk und perl aehneln, man kann's sogar noch genauer uebernehmen ( '| sort' via pipe(2) (lt. strace)):
==== find /usr/src/linux/ -type f -printf "%t\n" | perl -ne ' chomp; split(/\s+/); $wd{$_[0]}++; $yr{$_[4]}++; END { open(SORT, "|sort +1 -rn") or die $!; foreach (keys %wd) { print SORT "$_ $wd{$_}\n"; } close(SORT); open(SORT, "|sort +1 -rn") or die $!; foreach (keys %yr) { print SORT "$_ $yr{$_}\n"; } close(SORT); }' ====
Ah ja, da kommen wir der awk-Variante schon wieder ein Stück näher. Diesmal versteh ichs sogar auf Anhieb ;-)
Das witzige ist (IMO), dass perl auch so ca. gleichschnell ist, ich haette gedacht, die pipes waeren "teurer" ;)
Naja, sort ist ein kleines Programm. Der Zeitaufwand zum Starten und zum Lesen von Platte geht also recht schnell ;-) Ach so, diesmal halt ich nicht mit einer nur-bash-Variante dagegen, weil ich auf Anhieb nicht weiß, wie ich an eine Auflistung der Keys (Mon, Tue usw.) komme...
Wenn ich mir mal ein Script schreibe, das häufig läuft oder schon von Haus aus eine sehr lange Laufzeit hat, schau ich dann erster mal auf die Performance ;-)
Mir geht's mehr um die Effektivitaet (der "Arbeit"), zu der die "Performance" nur einen Teil beitraegt.
Klar, meinte ich ja.
Aber ich _achte_ auf die Performance. Natuerlich haenge ich oefter mal einfach ein 'grep -v blubb' noch hinter ne laengere "Piperei", aber ab einer gewissen Anzahl von Pipes und/oder "Verrenkungen" frag ich mich, ob es nicht hoechste Eisenbahn wird, ein paar davon mittels sed/awk/perl wegzurationalisieren. ;)
;-)
Ich richte mir übrigens gerade eine .bash_complete ein (ist keine übliche Datei, aber der Name erschien mir passend ;-) Da stehen dann etliche complete-Befehle drin, ^^^^^^^^^^^^^^^^?
Kennst Du nicht? *wunder* Dann probier mal folgendes (hoffentlich ist das in Deiner alten SuSE schon so eingerichtet): mkdir /tmp/completetest cd /tmp/completetest touch test test.ps test.txt test.pdf acroread t<tab> -> wird zu acroread test.pdf ergänzt, obwohl es noch andere t*-Dateien gibt. Das hast Du complete zu verdanken, da es in /etc/profile.d/complete.bash (wird von /etc/bash.bashrc gesourced) vordefiniert ist, dass acroread nur pdfs mag. complete wird dazu folgendermaßen aufgerufen: complete -o filenames -d -X '.[^./]*' -F _exp_ acroread Ebenso ist es beim cd-Befehl. Der zeigt auch nur Verzeichnisse an, wen man <tab><tab> drückt. Bedank Dich dafür bei complete -o dirnames -d -F _cd_ cd Oder noch besser und für mich recht nützlich: bei den Fontlingen nur noch den Anfang der --commands tippen: cb@tux:~> fontlinge_base --<tab><tab> --copy --debug --move --verbose --dbinsert --forcepreviews --my_preview= --dbkeep --look --previews Möglich ist das duch complete -d -W "--copy --move --previews --forcepreviews --my_preview= --dbinsert --dbkeep --look --debug --verbose" fontlinge_base (eine Zeile) Eine ausführliche Erklärung zu complete findet sich in man bash /complete *\[-abcd [PHP]
Gute Frage. Ich habe die Performance noch nicht getestet, hatte aber noch keine Probleme damit. Es kommt wohl immer darauf an, was man machen will. Für komplexe Aufgaben/Scripte, die hinterher dann aber nur wenig Output liefern, ist wohl ein CGI besser.
Jo. Zumal hier, mit php-3.0.11 (ohne ZEND)... ;)
Wobei: php hat doch nen Kommandozeilen/"script" Modus, oder?
AFAIK ja.
*hehe* dann koennte man perverserweise php fuer CGI nehmen!
*g* Ginge wohl, aber damit wäre ein Hauptvorteil von PHP weg, nämlich die Mischbarkeit von HTML und PHP. Nö, falsch, habs gerade getestet: cb@tux:~> echo 'Gruesse <?php echo "von PHP\n" ?>' | php X-Powered-By: PHP/4.2.2 Content-type: text/html Gruesse von PHP Man kann also auch HTML und PHP mischen, wenn man php direkt aufruft und nicht über den Webserver. Auch die <?php ... ?> Tags sind notwendig, alles was außerhalb davon steht, wird unbearbeitet ausgegeben.
Wenn man aber nur z. B. eine Sprachumschaltung, einfach zu handelnde Menüs (Einträge und Optik getrennt und hinterher include'd) oder eine automagisch gebaute Sitemap (aus den Menüdateien gebaut) will, ist PHP IMHO einfacher zu handhaben, da man es nach Belieben in HTML-Code einbetten kann (z. B. <a href="test.php?lang=<?php echo $lang ?>">),
if(HTTPD == "Apache") { [ ] du kennst das Feature von Apache, zuerst Dateien $name.$lang auszuliefern, sofern vorhanden? Also z.B. test.php.de statt test.php, wenn lang=de? Also quasi macht Apache dann: [...]
Ja, kenn ich. Aber ich habe keine Lust, das Layout in 3 verschiedenen Dateien (1 pro Sprache) zu pflegen, wenn ich alles auch in einer haben kann ;-) und nur a) ganz oben ein paar Zeilen PHP, wo ich in einem switch-Block ein paar Variablen abhängig von der gewünschten Sprache festlege b) an der Stelle, wo der Text hinsoll, ein <?php echo $text ?> Bei Interesse kann ich Dir gern mal ein paar von meinen PHP-Files schicken, da sind recht nützliche Tricks mit drin ;-)
die automagische Sitemap ist natürlich ein wenig aufwendiger ;-)
perldoc HTML::GenToc
Tja, wenn man Perl zur Verfügung hat ;-) Ich habe aber in PHP eine recht gute und flexible Lösung gebastelt.
Außerdem hab ich bei wein-vin-vinum.net nur PHP zur Verfügung und keine CGIs. Hat mich aber bisher nicht gestört ;-)
Bei mir waere's genau andersrum, aber ich such mir grad eh nen Web-Hoster/Email-Provider, und da achte ich u.a. darauf ;)
Anbieten dürfte das fast jeder, nur eben nicht im "Billigpaket" ;-) [...]
Interessant. Wenn ich so ein Beispiel mal irgendwo (z. B. in der Liste) finde, kann es durchaus sein, dass ich es auch verwende. Aber zum awk lernen konnte ich mich bisher nicht entschließen ;-)
*hehe* s.o.
Jepp, schon gesichert ;-) [...]
Wie gesagt, wegen Zeitmangel bleibe ich derzeit lieber bei den bekannten Programmen.
s.o. Das schoene an den genannten Tools ist ja, dass du die bisherige Arbeit oft uebernehmen kannst... Von grep nach sed nach awk nach perl, und awk z.B. ist IMO schon dann sehr praktisch, wenn du nur etwas meht als ein awk '{print $4}' kennst.
Jepp, stimmt.
[1] muss mal nach nem TMTOWTDI T-Shirt schauen ;)
*g* Du weißt, dass es da mehrere Sorten gibt *SCNR* Gruß Christian Boltz --
über browser?, wie wärs mit (ISDN)Telefon - ich hab da reboot und rcsmpppd restart Habe ich mir auch schon überlegt! Aber die Vorstellung war dann doch etwas komisch: "Ja, Schatz! Ich komme gleich ins Bett! Muss nur noch kurz meinen Router (unterm Tisch) anrufen, damit er runterfährt!" [> Andre Fischer und Michael Frank in suse-linux]
participants (5)
-
Christian Boltz -
David Haller -
Nightshade＠sheol.net -
Thomas GRIESSEMER -
Torsten Hallmann