Hallo,
Ich weiß jetzt nicht genau was hier gemeint ist, aber mit "if [ -a "$i.gz" ]; then" schaue ich doch nur ob $i.gz als File existiert oder nicht... oder mache ich da einen Denkfehler?? ja. Ob ein file existiert schaust Du mit -f nach, ob es auch lesbar ist mit -r. (Wenn es nicht existiert, ist es auch nicht lesbar, die -f Frage kann man sich hier also schenken, -r ist besser.)
Also bezüglich des Parameters -a habe ich meinen Fehler gefunden, ich habe mich auf den Anweisungen welche in "man bash" unter CONDITIONAL EXPRESSIONS zu finden sind, gehalten. Da lag mein Fehler, an "man test" hatte ich nicht gedacht. Thx to David Haller, für den Hinweis... Also ich habe mir das ganze jetzt vereinfacht, in dem ich die Files welche nicht gepackt waren, gepackt habe. Dann habe ich folgendes Skript benutzt um die Daten in eine Datei zu schreiben und die Datei danach zu sortieren. -------------------------------------------------------------- for i in "$@"; do zcat $i >> /tmp/test.txt sort +1 -g -t " " /tmp/test.txt > /tmp/sortiert.txt done -------------------------------------------------------------- Soweit hat auch alles geklappt. Jetzt läuft zuzeit der Webalizer über die Datei (1,2GB). Und das sollte es dann gewesen sein. Erstmal Danke für die viele Hilfe. Das ganze war für mich sehr lehrreich. Aber eine Frage ist da noch.... Könnt ihr mir nicht mal ein paar Doku-Tips, über Skript-Programmierung geben? Es ist nämlich doch sehr mühsam, die Manpages durchzugehen, und zu schauen, was man benutzen könnte für seine Zwecke, wenn man nicht genau weiß was es alles gibt. Besten Dank im vorraus. Björn
Hallo, On Mon, 15 Apr 2002, Bjoern Falkenhagen wrote:
Ich weiß jetzt nicht genau was hier gemeint ist, aber mit "if [ -a "$i.gz" ]; then" schaue ich doch nur ob $i.gz als File existiert oder nicht... oder mache ich da einen Denkfehler?? ja. Ob ein file existiert schaust Du mit -f nach, ob es auch lesbar ist mit -r. (Wenn es nicht existiert, ist es auch nicht lesbar, die -f Frage kann man sich hier also schenken, -r ist besser.)
Also bezüglich des Parameters -a habe ich meinen Fehler gefunden, ich habe mich auf den Anweisungen welche in "man bash" unter CONDITIONAL EXPRESSIONS zu finden sind, gehalten. Da lag mein Fehler, an "man test" hatte ich nicht gedacht. Thx to David Haller, für den Hinweis...
Eben... *eg* Wenn's jetzt (deswegen) besser haengenbleibt, umso besser ;)
Also ich habe mir das ganze jetzt vereinfacht, in dem ich die Files welche nicht gepackt waren, gepackt habe. Dann habe ich folgendes Skript benutzt um die Daten in eine Datei zu schreiben und die Datei danach zu sortieren. -------------------------------------------------------------- for i in "$@"; do zcat $i >> /tmp/test.txt sort +1 -g -t " " /tmp/test.txt > /tmp/sortiert.txt done --------------------------------------------------------------
Jo, sieht gut aus. Wozu das '+1' und '-g'? (rein Neugierdehalber, ich hab bisher mit 'sort' oder 'sort -n' immer alles sortiert bekommen ;) Das '-t " "' sollte IMO ueberfluessig sein (es sei denn, du willst explizit auch tabs als Feldtrenner (fuer '+1'?) ausschliessen)... Aber abgesehen von diesen (meinen!) Fragen bzgl. sort: sieht, ich wiederhole mich gern, recht gut aus. Du koenntest aber immernoch Probleme bekommen: 0. Ich HASSE es, wenn in einer Schleife "$i" fuer Dateinamen verwendet wird. Wenn, dann nehme ich "$f" (file), "$d" (directory|datei), "$v" (verzeichnis), oder am besten sowieso laengere Variablennamen. Also z.B. oben: 'for file in "$@"; ...' 1. Du quotest "$i" beim zcat nicht. Sobald du einen Dateinamen mit SPACE bekommst: PENG! ;) Ein "${VARIABLENNAME}" ist noch einen Tick sicherer ;) 2. wie schon erwaehnt: es gibt "falsche" Dateien im Verzeichnis, (z.B. .bz2 komprimierte, gifs, jpegs usw...) Du solltest also entweder $@ irgendwie pruefen, oder besser gleich '*.gz' verwenden. Oder du erweiterst das script so, dass auch z.B. .bz2 legal sind: for datei in "$@" do case "$datei" in .bz2) bzcat "${datei}" >> /tmp/test.txt;; .gz) zcat "${datei}" >> /tmp/test.txt;; *) echo "Fehler: kann Datei $datei nicht ..." >&2;; esac done 3. Du ueberpruefst weder die Existenz von /tmp/test.txt noch die von /tmp/sortiert.txt Ja! Bisher war das "overkill", aber fuer ein echtes script solltest du besser beide Dateinamen mittels 'mktemp(1)' erzeugen lassen, das bietet zumindest einen (einfachen) und etwas sichereren Weg so eine temporaere Datei anzulegen... Lese bitte auch die "verknuepften" manpages mkstemp(3) und mktemp(3). Ich sach nur: ==== mktemp(3) ==== BUGS Never use mktemp(). [..] ==== mktemp(1) ist IIRC sicherer, die Details muesste ich aber auch in den Quelltexten nachlesen...
Soweit hat auch alles geklappt. Jetzt läuft zuzeit der Webalizer über die Datei (1,2GB). Und das sollte es dann gewesen sein.
*g* Aber bitte beachte obige Punkte, falls du das script mehr als einmal einsetzen willst...
Erstmal Danke für die viele Hilfe. Das ganze war für mich sehr lehrreich.
*g* Ich hoffe, das geht auch noch weiter ;)
Aber eine Frage ist da noch.... Könnt ihr mir nicht mal ein paar Doku-Tips, über Skript-Programmierung geben?
Kaum ;) Ich kann wohl zu gut englisch, mir reicht 'man bash' ;) Ansonsten: der "Advanced Bash Scripting Guide" vom linuxdoc.org Project sollte dir helfen, kann gut sein, dass der bei dir schon irgendwo auf der Platte oder den CDs rumfaehrt (koennte z.B. im RPM 'books' sein, Serie 'doc'). Dateiname ist evtl. 'absg*' oder so. Auf http://www.linuxdoc.org/ bekommst du den aber auf jeden Fall. Fuer Grundlagen (auf Deutsch) gibt's auch einiges, z.B. http://www.selflinux.de/. Leider bin hier ich relativ ueberfragt... Schau vielleicht auch mal ins Archiv (such nach o.g. URLs, damit solltest du in den richtigen Threads landen)...
Es ist nämlich doch sehr mühsam, die Manpages durchzugehen, und zu schauen, was man benutzen könnte für seine Zwecke, wenn man nicht genau weiß was es alles gibt.
Oh, _dafuer_ gibt's noch ne bessere Methode: Schau dir ein gutes, von der Komplexitaet "herausforderndes" script an, und "ackere" das dann, mit der manpage "nebendran" durch... An scripten kann ich z.B. die von teTeX empfehlen... (mktex* z.B.)... Mit "durchackeren" meine ich dabei: verstehe jede Zeile! Falls du etwas nicht schon (genau!) kennst, such in der manpage, lese das dann durch, verstehe es, probiere es aus, teste, spiel damit rum, usw... Als Anregung/Uebung (*eg*): a) Erklaere (im Detail) was die folgende Zeile macht und finde einen passenden Namen fuer 'x': x() { echo "'${1/##*\/}' in '${1%\/*}'"; } b) was macht dann anschliessend: x $0 Klar, das Beispiel ist relativ sinnfrei, kann einem aber, wenn man ins Detail geht (und versteht! -> man bash!), zumindest 3 Teilbereiche der bash naeherbringen ;) -dnh PS: (v.a. auch an Bernd) sollte "man" nicht sowas mal sammeln? Und dann, sowohl mit der "offiziellen" Erklaerung des "Autors" und der/den besten "Loesungen" vielleicht veroeffentlichen??? Mich duenkt, es gibt "Bedarf" an sowas ;) PPS: Lehmann's hatte zu dem Thema in ihrem Quiz auch eine "nette" Aufgabe, die mit einem ':' begann... *eg* -- Du sollst nicht mit der 42 rumschmeissen, du Nasenbär. Jetzt hättest du sie fast kaputt gemacht. Das ist so etwas wie unsere Bibel. Verschrotte lieber deine 666. Diese Zahl ist Satanswerk. [WoKo in dag°]
* David Haller schrieb am 15.Apr.2002:
On Mon, 15 Apr 2002, Bjoern Falkenhagen wrote:
-------------------------------------------------------------- for i in "$@"; do zcat $i >> /tmp/test.txt sort +1 -g -t " " /tmp/test.txt > /tmp/sortiert.txt done --------------------------------------------------------------
2. wie schon erwaehnt: es gibt "falsche" Dateien im Verzeichnis, (z.B. .bz2 komprimierte, gifs, jpegs usw...) Du solltest also entweder $@ irgendwie pruefen, oder besser gleich '*.gz' verwenden. Oder du erweiterst das script so, dass auch z.B. .bz2 legal sind:
for datei in "$@" do case "$datei" in .bz2) bzcat "${datei}" >> /tmp/test.txt;; .gz) zcat "${datei}" >> /tmp/test.txt;; *) echo "Fehler: kann Datei $datei nicht ..." >&2;; esac done
Wobei die Endung ja nicht stimmen muß. Um das zu überprüfen gibt es file.
etwas nicht schon (genau!) kennst, such in der manpage, lese das dann durch, verstehe es, probiere es aus, teste, spiel damit rum, usw...
Als Anregung/Uebung (*eg*):
a) Erklaere (im Detail) was die folgende Zeile macht und finde einen passenden Namen fuer 'x':
x() { echo "'${1/##*\/}' in '${1%\/*}'"; }
b) was macht dann anschliessend:
x $0
URGS! Ist das nicht ein wenig heftig? Ich meine für einen Anfänger? Ich überlegt z.B warum da überhaupt was ersetzt wird, wo das ganze doch in '..' steht. Hm. Und wieso im ersten Ausdruck alles weggenommen wird, wenn etwas mit # beginnt. Ich hätte nur auf das, bzw. die # am Anfang getippt. Ahja, das mit den '...' ist klar, es steht innerhalb von "..." ok. Und das alles ersetzt wird ist auch klar, wir sind in der bash und das ist kein RegExp. Ok, schon verstanden. Bin aber auch nicht unbedingt ein absoluter Anfänger. ;)
Klar, das Beispiel ist relativ sinnfrei, kann einem aber, wenn man ins Detail geht (und versteht! -> man bash!), zumindest 3 Teilbereiche der bash naeherbringen ;)
-dnh
PS: (v.a. auch an Bernd) sollte "man" nicht sowas mal sammeln? Und dann, sowohl mit der "offiziellen" Erklaerung des "Autors" und der/den besten "Loesungen" vielleicht veroeffentlichen??? Mich duenkt, es gibt "Bedarf" an sowas ;)
Was meinst Du mit "sowas"? Solche Aufgaben? Bernd -- LILO funktioniert nicht? Hast Du /etc/lilo.conf verändert und vergessen, lilo aufzurufen? Ist Deine /boot-Partition unter der 1024 Zylindergrenze? Bei anderen LILO Problemen mal in der SDB nachschauen: http://localhost/doc/sdb/de/html/rb_bootdisk.html |Zufallssignatur 6
Am Mon, 15 Apr 2002 schrieb Bernd Brodesser:
* David Haller schrieb am 15.Apr.2002:
On Mon, 15 Apr 2002, Bjoern Falkenhagen wrote:
etwas nicht schon (genau!) kennst, such in der manpage, lese das dann durch, verstehe es, probiere es aus, teste, spiel damit rum, usw...
Als Anregung/Uebung (*eg*):
a) Erklaere (im Detail) was die folgende Zeile macht und finde einen passenden Namen fuer 'x':
x() { echo "'${1/##*\/}' in '${1%\/*}'"; }
Muß das nicht entweder echo "'${1##*\/}' in ... oder aber echo "'${1/#*\//}' in ... heißen? Wobei bei letzterem Vorschlag der dritte Slash wegfallen kann.
Ahja, das mit den '...' ist klar, es steht innerhalb von "..." ok.
Ist aber hier mehr zur Verwirrung als aus konkretem Grund eingesetzt. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Hallo, On Mon, 15 Apr 2002, Christoph Maurer wrote:
Am Mon, 15 Apr 2002 schrieb Bernd Brodesser:
* David Haller schrieb am 15.Apr.2002:
etwas nicht schon (genau!) kennst, such in der manpage, lese das dann durch, verstehe es, probiere es aus, teste, spiel damit rum, usw...
Als Anregung/Uebung (*eg*):
a) Erklaere (im Detail) was die folgende Zeile macht und finde einen passenden Namen fuer 'x':
x() { echo "'${1/##*\/}' in '${1%\/*}'"; }
Muß das nicht entweder echo "'${1##*\/}' in ... oder aber echo "'${1/#*\//}' in ... heißen? Wobei bei letzterem Vorschlag der dritte Slash wegfallen kann.
Nein. Das Ergebnis waere ein anderes. War schon Absicht ;)
Ahja, das mit den '...' ist klar, es steht innerhalb von "..." ok.
Ist aber hier mehr zur Verwirrung als aus konkretem Grund eingesetzt.
Noe. Nimm einen (kranken) Dateinamen wie z.B. (ein Name!): /tmp/test/kranke_dateinamen/"foo" und "bar" -dnh -- Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec [from the fortune file]
Am Die, 16 Apr 2002 schrieb David Haller:
Hallo,
On Mon, 15 Apr 2002, Christoph Maurer wrote:
Am Mon, 15 Apr 2002 schrieb Bernd Brodesser:
* David Haller schrieb am 15.Apr.2002:
etwas nicht schon (genau!) kennst, such in der manpage, lese das dann durch, verstehe es, probiere es aus, teste, spiel damit rum, usw...
Als Anregung/Uebung (*eg*):
a) Erklaere (im Detail) was die folgende Zeile macht und finde einen passenden Namen fuer 'x':
x() { echo "'${1/##*\/}' in '${1%\/*}'"; }
Muß das nicht entweder echo "'${1##*\/}' in ... oder aber echo "'${1/#*\//}' in ... heißen? Wobei bei letzterem Vorschlag der dritte Slash wegfallen kann.
Nein. Das Ergebnis waere ein anderes. War schon Absicht ;)
Und was ist dann ${1/##*\/} Ich zitiere mal die relevanten Teile von man bash ${parameter##word} The word is expanded to produce a pattern just as in pathname expansion. If the pattern matches the beginning of the value of parameter, then the result of the expansion is the expanded value of parameter with the shortest matching pattern (the ``#'' case) or the longest matching pattern (the ``##'' case) deleted. If parameter is @ or *, the pattern removal operation is applied to each posi tional parameter in turn, and the expansion is the resultant list. If parameter is an array variable subscripted with @ or *, the pattern removal opera tion is applied to each member of the array in turn, and the expansion is the resultant list. ${parameter/pattern/string} ${parameter//pattern/string} The pattern is expanded to produce a pattern just as in pathname expansion. Parameter is expanded and the longest match of pattern against its value is replaced with string. In the first form, only the first match is replaced. The second form causes all matches of pattern to be replaced with string. If pattern begins with #, it must match at the beginning of the expanded value of parameter. If pattern begins with %, it must match at the end of the expanded value of parameter. If string is null, matches of pattern are deleted and the / fol lowing pattern may be omitted. If parameter is @ or *, the substitution operation is applied to each positional parameter in turn, and the expansion is the resultant list. If parameter is an array vari able subscripted with @ or *, the substitution operation is applied to each member of the array in turn, and the expansion is the resultant list. Das heißt ${1##*\/} schneidet von $1 ab dem Anfang das längste mögliche */ Muster ab(##), sprich, den kompletten Pfadnamen (basename) ${1/#*\/} macht das gleiche, nur das bei Patternsearch automatisch der längste Match ersetzt wird, # bedeutet hier, daß der Match von Anfang an stattfinden muss. Dein Vorschlag ${1/##*\/} bedeutet jedoch IMHO, daß das Suchmuster um es mal in Regex-Syntax zu schreiben ^#.*/ ist, oder was sehe ich falsch. Bei der Syntax ${parameter/pattern gibt es bei pattern nicht die Sonderbedeutung ##. Dein Beispiel führt nämlich auch, abgespeichert z.B. unter /home/ma/tmp/testscript und auch so aufgerufen zur Ausgabe '/home/ma/tmp/testscript' in '/home/ma/tmp' Dazu brauchst Du die ganze Parameter Substitution nicht, da hätte es auch echo "'$1' in ${1%\/*}'" getan. Mein Vorschlag führt hingegen zu 'testscript' in '/home/ma/tmp' was doch wohl eher beabsichtigt war.
Ahja, das mit den '...' ist klar, es steht innerhalb von "..." ok.
Ist aber hier mehr zur Verwirrung als aus konkretem Grund eingesetzt.
Noe. Nimm einen (kranken) Dateinamen wie z.B. (ein Name!):
/tmp/test/kranke_dateinamen/"foo" und "bar"
Okay, sehe ich ein... Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Hallo, On Tue, 16 Apr 2002, Christoph Maurer wrote:
Am Die, 16 Apr 2002 schrieb David Haller:
On Mon, 15 Apr 2002, Christoph Maurer wrote:
Am Mon, 15 Apr 2002 schrieb Bernd Brodesser:
* David Haller schrieb am 15.Apr.2002:
x() { echo "'${1/##*\/}' in '${1%\/*}'"; }
Muß das nicht entweder echo "'${1##*\/}' in ... [..] Nein. Das Ergebnis waere ein anderes. War schon Absicht ;)
Und was ist dann ${1/##*\/}
Aeh, ja, war ein Felher (beim einfuegen) meinerseits, siehe die andere Mail... Gemeint war genau das '${1##*\/}' *seufz* ;) [..]
Ahja, das mit den '...' ist klar, es steht innerhalb von "..." ok.
Ist aber hier mehr zur Verwirrung als aus konkretem Grund eingesetzt.
Noe. Nimm einen (kranken) Dateinamen wie z.B. (ein Name!):
/tmp/test/kranke_dateinamen/"foo" und "bar"
Okay, sehe ich ein...
Gelle? Da sind '' um den Namen doch recht praktisch, oder? *eg* Von "Perversitaten" mit nem '' oder ' ' im Dateinamen will ich gar nicht erst anfangen ;) Hm. Da faellt mir was nettes ein: $ cd /tmp/test/kranke_dateinamen $ touch 't^H_e^H_s^H_t^H_' $ touch 't^Hte^Hes^Hst^Ht' $ ls -1b "foo"\nund\n"bar" t\b_e\b_s\b_t\b_ t\bte\bes\bst\bt $ ls | less "foo" und "bar" test test [line 1/5 (END)] Wobei das erste "test" unterstrichen, und das zweite "test" fett ist. Evtl. stellt das (hinter den 'touch'es) auch der ein oder andere MUA so dar *LOL* Klar, das Beispiel _war_ konstruiert, aber wenn man _dieses_ Beispiel mal verstanden hat... Und Teile verwende ich fast taeglich. Ein von mir z.B. fast praktisch _jedem_ script, das ich schreibe, verwendetes Feature ist eben z.B.: echo "foo='$foo'" Fuer das debugging sehr hilfreich, besonders, wenn der Inhalt von $foo mal laenger wird und/oder ueber mehrere Zeilen geht. Und soo selten sind mehrzeilige Variableninhalte ja auch wieder nicht, ich sage nur $ echo "IFS='$IFS'" IFS=' ' *hehe* Wenn man sowas dann mal an solchen "fiesen" Beispielen durch- exerziert hat, dann irritiert einen sowas auch nicht mehr :)) -dnh, dem schon ein paar weitere Beispiele einfallen: "Tricks" mit $IFS, a la ': ${foo:-bar}' usw... So generell eben "Spielereien", die man in den "ueblichen" Beispielen eben _nicht_ findet ;) Man moege sich z.B. mal die autoconf-scripte und/oder teTeX's mk*-scripte anschauen... Da kann man _verdammt_ viel bei lernen :) -- Manche wollen 'n Fisch, andere wollen fischen lernen. Fische verteilen ist langweilig, da hätt ich auch Besseres zu tun. -- Karen Eisenberg
* David Haller schrieb am 16.Apr.2002:
Gelle? Da sind '' um den Namen doch recht praktisch, oder? *eg* Von "Perversitaten" mit nem '' oder ' ' im Dateinamen will ich ^^^^
Das sieht Recht Merkwürdig aus. Ein grünes ', jedenfalls bei meinem mutt, hier im vi sehe ich '^H'
gar nicht erst anfangen ;) Hm. Da faellt mir was nettes ein:
$ cd /tmp/test/kranke_dateinamen $ touch 't^H_e^H_s^H_t^H_' $ touch 't^Hte^Hes^Hst^Ht' $ ls -1b "foo"\nund\n"bar" t\b_e\b_s\b_t\b_ t\bte\bes\bst\bt $ ls | less "foo" und "bar" test test [line 1/5 (END)]
Wobei das erste "test" unterstrichen, und das zweite "test" fett ist. Evtl. stellt das (hinter den 'touch'es) auch der ein oder andere MUA so dar *LOL*
Würde es vielleicht, wenn Du echte ^H verwendet hättest und nicht ^ und dann ein H. ;) Mal sehen, wie das aussieht: t_e_s_t_ tteesstt Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
Hallo, On Wed, 17 Apr 2002, Bernd Brodesser wrote:
* David Haller schrieb am 16.Apr.2002:
Gelle? Da sind '' um den Namen doch recht praktisch, oder? *eg* Von "Perversitaten" mit nem '' oder ' ' im Dateinamen will ich ^^^^
Das sieht Recht Merkwürdig aus. Ein grünes ', jedenfalls bei meinem mutt, hier im vi sehe ich '^H'
Jup. Jetzt im xemacs taucht das ^H auch wieder auf :)
gar nicht erst anfangen ;) Hm. Da faellt mir was nettes ein:
$ cd /tmp/test/kranke_dateinamen $ touch 't^H_e^H_s^H_t^H_' $ touch 't^Hte^Hes^Hst^Ht' [ls | less] Wobei das erste "test" unterstrichen, und das zweite "test" fett ist. Evtl. stellt das (hinter den 'touch'es) auch der ein oder andere MUA so dar *LOL*
Würde es vielleicht, wenn Du echte ^H verwendet hättest und nicht ^ und dann ein H. ;)
Mift, ich hab gepennt und das reinkopiert... Da wurden eben ^ + H draus.
Mal sehen, wie das aussieht:
t_e_s_t_ tteesstt
in mutt: gruen und normal (ist bei mir im mutt halt so eingestellt :) im xemacs: wieder mit den C-h :) -dnh -- Computers make very fast, very accurate mistakes.
David Haller schrieb am 17.04.2002 um 16:14:28 +0200: Hallo David,
Hallo,
On Wed, 17 Apr 2002, Bernd Brodesser wrote:
* David Haller schrieb am 16.Apr.2002:
Gelle? Da sind '' um den Namen doch recht praktisch, oder? *eg* Von "Perversitaten" mit nem '' oder ' ' im Dateinamen will ich ^^^^
Das sieht Recht Merkwürdig aus. Ein grünes ', jedenfalls bei meinem mutt, hier im vi sehe ich '^H'
Jup. Jetzt im xemacs taucht das ^H auch wieder auf :)
gar nicht erst anfangen ;) Hm. Da faellt mir was nettes ein:
$ cd /tmp/test/kranke_dateinamen $ touch 't^H_e^H_s^H_t^H_' $ touch 't^Hte^Hes^Hst^Ht' [ls | less] Wobei das erste "test" unterstrichen, und das zweite "test" fett ist. Evtl. stellt das (hinter den 'touch'es) auch der ein oder andere MUA so dar *LOL*
Würde es vielleicht, wenn Du echte ^H verwendet hättest und nicht ^ und dann ein H. ;)
Mift, ich hab gepennt und das reinkopiert... Da wurden eben ^ + H draus.
Mal sehen, wie das aussieht:
t_e_s_t_ tteesstt
in mutt: gruen und normal (ist bei mir im mutt halt so eingestellt :) im xemacs: wieder mit den C-h :)
und unterstrichen. Das erste zumindest und das zweite ist gelb und nicht gruen. Stell Deinen mutt mal vernünftig ein ;-))))) Bis denne, Michael -- ---------------------------------------------------------- Michael Schulz, Institut f. Geophysik, Universität Münster Corrensstr. 24, 48149 Münster Tel.: 0251-8333938, e-mail: michael@earth.uni-muenster.de
Hallo, On Mon, 15 Apr 2002, Bernd Brodesser wrote:
* David Haller schrieb am 15.Apr.2002:
for datei in "$@" do case "$datei" in .bz2) bzcat "${datei}" >> /tmp/test.txt;; .gz) zcat "${datei}" >> /tmp/test.txt;; *) echo "Fehler: kann Datei $datei nicht ..." >&2;; esac done
Wobei die Endung ja nicht stimmen muß. Um das zu überprüfen gibt es file.
Ack. Aber, naja, zcat und bzcat beschweren sich ggfs. auf stderr ;)
etwas nicht schon (genau!) kennst, such in der manpage, lese das dann durch, verstehe es, probiere es aus, teste, spiel damit rum, usw...
Als Anregung/Uebung (*eg*):
a) Erklaere (im Detail) was die folgende Zeile macht und finde einen passenden Namen fuer 'x':
x() { echo "'${1/##*\/}' in '${1%\/*}'"; }
b) was macht dann anschliessend:
x $0
URGS! Ist das nicht ein wenig heftig? Ich meine für einen Anfänger?
Ja *hehe*. Aber wenn man _das_ mal auseinandergepfriemelt und dann auch noch verstanden hat, dann hat man IMO 3 Features der bash wohl zu einem guten Teil verstanden, was der Zweck der Uebung waere :)
Ich überlegt z.B warum da überhaupt was ersetzt wird, wo das ganze doch in '..' steht. Hm. Und wieso im ersten Ausdruck alles weggenommen wird, wenn etwas mit # beginnt. Ich hätte nur auf das, bzw. die # am Anfang getippt.
Ahja, das mit den '...' ist klar, es steht innerhalb von "..." ok. Und das alles ersetzt wird ist auch klar, wir sind in der bash und das ist kein RegExp. Ok, schon verstanden. Bin aber auch nicht unbedingt ein absoluter Anfänger. ;)
Siehste? Auch ich muss da mehrfach hinsehen und evtl. in man bash nachlesen ;) Es sollte ja eben eine "Nuss" zum knacken sein :)
PS: (v.a. auch an Bernd) sollte "man" nicht sowas mal sammeln? Und dann, sowohl mit der "offiziellen" Erklaerung des "Autors" und der/den besten "Loesungen" vielleicht veroeffentlichen??? Mich duenkt, es gibt "Bedarf" an sowas ;)
Was meinst Du mit "sowas"? Solche Aufgaben?
Jep. Aufgaben, die, wenn man sie versteht(!), einen bestimmten Bereich, ein bestimmtes Feature weitestgehend verdeutlichen... Ein anderes Beispiel koennte z.B. "' und ` und generell das "quoting" illustrieren... Am besten noch anhand/mit "kaputten" Dateinamen ;) Oder irgendwas zu 'for' und 'xargs' oder so :) Was konkretes muesste ich aber auch erst basteln... -dnh -- 16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend. --- Eric S. Raymond, "The Cathedral and the Bazaar"
participants (5)
-
B.Brodesser＠t-online.de -
Bjoern Falkenhagen -
Christoph Maurer -
David Haller -
Michael Schulz