Am Dienstag, 24. Juni 2003 17:55 schrieb Axel Heinrici:

Hi

On Tuesday 24 June 2003 17:29, Martin Schmiderer wrote:

...

...

irgendwas kriege ich hier nicht auf die Reihe: wenn ich alle Dateien suchen will, die z.B. mit ".txt" aufhören und "egal" enthalten, geht das nicht mit find / -iname "*.txt" | grep egal , weil das die gelieferten Pfade durchsuchen würde und also alles liefert, was mit ".txt" aufhört und im Pfad irgendwo "egal" enthält. So weit kapier ich noch alles.

Warum geht es aber nicht mit find / -iname "*.txt" | cat | grep egal ?

Weil cat nur die Dateinamen bekommt und auch nur Dateinamen an grep übergibt. Du brauchst noch etwas das in die Dateien reinschaut die find liefert.

...

Hallo *,

was Du suchst ist find / -iname '*.txt' -exec grep egal {} \;

man find ist das was Du lesen solltest.

Naja, da kommen dann aber nur die Zeilen aus irgendwelchen Dateien raus die "egal" enthalten. Ich vermute mal, dass da aber die Dateinamen der Dateien die "egal" enthalten rauskommen soll.

mfg Axel

Ok das ist mir auch klar, nur denke ich das das in der manpage zu find / grep echt gut dokumentiert ist ;-) Und ich will niemandem den spass nehmen selbst auf die loesung des Problems zu kommen ;-) ;-) regards Martin -- ________________________________creating IT solutions Martin Schmiderer science + computing ag System Administration Hagellocher Weg 71-75 phone +49 7071 9457 225 72070 Tuebingen, Germany fax +49 7071 9457 211 www.science-computing.de

Hmm, muss mal was fragen hier. Es ging darum, alle Dateien zu finden, die ein "egal" im Dateinamen tragen und auf ".txt" enden. Alle Loesungen, ausser meine, versuchen das mit grep oder xargs usw. zu loesen. Ich verstehe diese Vorgehensweise nicht. Ein einfaches find pfad -iname "*egal*.txt" -print tut es doch. Beispiel: thertw@einstein:~> ll /tmp/ [...] /tmp/dasistmirdochegaldatei.txt /tmp/dasist mirdochegaldatei .txt [...] thertw@einstein:~> find /tmp -iname "*egal*.txt" -print 2> /dev/null /tmp/dasistmirdochegaldatei.txt /tmp/dasist mirdochegaldatei .txt thertw@einstein:~> Funktioniert doch, auch mit Leerzeichen. Oder war etwas anderes gesucht? Dann habe ich die Frage nicht verstanden :-) Oder haben die anderen Loesungen irgendwelche Vorteile? Gruesse, Thomson

Bernd Brodesser schrieb:

[...] Da hat der Fragesteller nicht eindeutig gefragt. Ich zitiere mal:

| irgendwas kriege ich hier nicht auf die Reihe: wenn ich alle Dateien suchen | will, die z.B. mit ".txt" aufhören und "egal" enthalten,

Was heißt hier "egal" enthalten? Du gehst davon aus, daß egal Teil des Dateinamens ist, die anderen gingen davon aus, daß egal Bestandteil des Dateninhaltes ist.

Aah, *an den Kopf klatsch*, ja, so kann man es auch auffassen. Jetzt werden mir auch die anderen Postings klar :-) Danke fuer die Erhellung. Macht auf diese Art und Weise gesehen vielleicht sogar mehr Sinn. Gruesse, Thomson

Jürgen Vollmer schrieb:

Thomas Hertweck

...

Hmm, muss mal was fragen hier. Es ging darum, alle Dateien zu finden, die ein "egal" im Dateinamen tragen und auf ".txt" enden. Alle Loesungen, ausser meine, versuchen das mit grep oder xargs usw. zu loesen. Ich verstehe diese Vorgehensweise

nein, es ging nicht darum den Pfadnamen einer Datei zu untersuchen, sondern den Inhalt der Dateien, die auf .txt enden.

Bernd hatte das schon gemailt. Die Frage ist aber nicht eindeutig formuliert. Mir geht es auch nicht darum, den Pfadnamen zu durchsuchen, sondern den Dateinamen!

Hier nochmal die Ausgangsfrage:

Horst Jäger :

...

irgendwas kriege ich hier nicht auf die Reihe: wenn ich alle Dateien suchen will, die z.B. mit ".txt" aufhören und "egal" enthalten, geht das nicht mit find / -iname "*.txt" | grep egal , weil das die gelieferten Pfade --------------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ durchsuchen würde und also alles liefert, was mit ".txt" aufhört und im -^^^^^^^^^^^^^^^^^^^ Pfad irgendwo "egal" enthält. So weit kapier ich noch alles.

Aus der Frage laesst sich nicht eindeutig Deine Interpre- tation ableiten. Horst koennte auch einfach gemeint haben, er suche eine Datei names *egal*.txt, moechte aber nicht Ausgaben finden, wo ein *egal* im Pfad(!) (d.h. nicht Dateinamen) vorkommt, eine Datei aber auf *.txt endet. Ich habe das halt so interpretiert, andere haben es anders interpretiert - jedenfalls gibt es jetzt Loesungen fuer beide Faelle :-) Wobei ich zugeben muss, dass die andere Betrachtungsweise mir mittlerweile auch logischer erscheint. Manchmal denkt man etwas verquer. Deswegen gehe ich jetzt auch ins Bett :-) CU, Thomson

Hallo an alle! Danke für die viele Hilfe. Zwei Punkte hätte ich: 1. "man find ist das was Du lesen solltest." haben einige geantwortet. Dazu muss ich ne Grundsatzerklärung loswerden: Ich finde nichts auf der Welt so grausam wie die manpages und es ist mir bisher erst ein einziges Mal passiert, dass mir eine manpage geholfen hat. Man muss glaube ich schon ein recht hohes Niveau haben (zumindest linuxmäßig) um damit was anfangen zu können. Ich ziehe mir immer reflexmäßig die mps rein, hab jedes Mal wieder gleichermaßen nix davon und muß jemand fragen der sich auskennt. Speziell in diesem Fall: "man find" kann man gebrauchen wenn man eigentlich weiss wie's geht und nur die genaue Syntax vergessen hat. Ich bin relativ neu in Sachen Linux und kann damit aber auch gar nichts anfangen. "Man" ist ein Nachschlagewerk für Profis und zum Lernen absolut nicht zu gebrauchen (gut, ich habe mal von einem 4jährigen Kind gehört, das sich vom Ablesen der Sender auf einem alten Röhrenradio selbst Lesen beigebracht hat und dessen erstes Wort "Luxembourg" war - das hätte sicher auch mit den manpages Linux lernen können). 2. Zu den Lösungen: find / -iname '*.txt' -exec grep egal {} \; tut's, aber klappt nicht mit z.B. egal* . Das Problem hatte ich früher schon: man muss Anführungszeichen setzen ("egal*" ) und das klappt auch nicht - jemand hat mich auch in seiner Mail davor gewarnt. xargs dito ... Allgemein: ich habe bestimmt 20 Lösungsansätze von euch gemailt bekommen, aber keiner tut's mit "*". Wie geht: sowohl Dateinamen als auch Inhalt mit * ? Bitte schreibt mir ruhig Drohbriefe oder Obszönitäten, aber nicht: lies die manpages. Horst

On Wednesday 25 June 2003 16:21, Kristian Koehntopp wrote:

On Wed, Jun 25, 2003 at 04:12:13PM +0200, Horst Jäger wrote: grep verwendet keine Shell Globs ("*", "?", "[a-z]"), sondern Grep Regular Expressions. Statt "*" schreibst Du also ".*" (. ist ein beliebiges Zeichen, und * sind Null oder mehr Wiederholungen des vorhergehenden Zeichens), statt "?" schreibst Du "." und "[a-z]" wird tatsächlich auch "[a-z]" beschrieben.

Heute ging ja noch so ein sed-Beispiel über die Liste. Vor dem Urlaub wäre es für mich noch Bahnhof gewesen. An Pfingsten habe ich mir nun endlich Lerning Perl (das Kamelbuch) von O'Reilly gegeben (stand schon ewig hier rum). Hatte auch großen Nachholbedarf in Punkto Regular Expressions. Das Kapitel 7 beschäftigt sich ausgiebig und mit vielen gut verständlichen Beispielen zur Thematik Regular Expressions. Kann ich wärmstens empfehlen. Gibt sicher auch online was in der Art. Hat jemand von Euch vielleicht einige Links dafür parat? Robert

On Mit, 25 Jun 2003 at 16:21 (+0200), Kristian Koehntopp wrote:

On Wed, Jun 25, 2003 at 04:12:13PM +0200, Horst Jäger wrote: [...]

...

find / -iname '*.txt' -exec grep egal {} \; tut's, aber klappt nicht mit z.B. egal* . Das Problem hatte ich früher schon: man muss Anführungszeichen setzen ("egal*" ) und das klappt auch nicht - jemand hat mich auch in seiner Mail davor gewarnt.

grep verwendet keine Shell Globs ("*", "?", "[a-z]"), sondern Grep Regular Expressions. Statt "*" schreibst Du also ".*" (. ist ein beliebiges Zeichen, und * sind Null oder mehr Wiederholungen des vorhergehenden Zeichens), statt "?" schreibst Du "." und "[a-z]" wird tatsächlich auch "[a-z]" beschrieben.

Die regex sind doch aber im angegebenen Fall total überflüssig. Der Befehl grep -l egal datei findet genauso jede Datei, in der die *Zeichenfolge* egal auftaucht, wie grep -l "egal.*" datei oder grep -l ".*egal.*" datei Horst, was hast Du denn getestet? Ich bin nach wie vor der Meinung, das viele der vorgeschlagenen Lösungen genau das tun, was Du willst. Jan

Am Mit, 2003-06-25 um 16.12 schrieb Horst Jäger:

Hallo an alle!

Danke für die viele Hilfe. Zwei Punkte hätte ich:

1. "man find ist das was Du lesen solltest." haben einige geantwortet. Dazu muss ich ne Grundsatzerklärung loswerden:

Ich finde nichts auf der Welt so grausam wie die manpages und es ist mir bisher erst ein einziges Mal passiert, dass mir eine manpage geholfen hat. Man muss glaube ich schon ein recht hohes Niveau haben (zumindest linuxmäßig) um damit was anfangen zu können. [...] "Man" ist ein Nachschlagewerk für Profis und zum Lernen absolut nicht zu gebrauchen

2. Zu den Lösungen:

find / -iname '*.txt' -exec grep egal {} \; tut's, aber klappt nicht mit z.B. egal* . Das Problem hatte ich früher schon: man muss Anführungszeichen setzen ("egal*" ) und das klappt auch nicht - jemand hat mich auch in seiner Mail davor gewarnt.

xargs dito ...

Allgemein: ich habe bestimmt 20 Lösungsansätze von euch gemailt bekommen, aber keiner tut's mit "*".

Wie geht: sowohl Dateinamen als auch Inhalt mit * ?

Bitte schreibt mir ruhig Drohbriefe oder Obszönitäten, aber nicht: lies die manpages.

Horst

Hallo Horst, das mit den Manpages kann ich teilweise nachvollziehen. Als ich mit Unix 1985 begann, gab es nur Manpages und englische Handbücher. Bis ich mit vi umgehen konnte, hat es ca. 1 Jahr gedauert, und ich entdecke heute noch neue Funktionen. man bash ist für Anfänger die absolute Todesseite. Allerdings sind viele (kürzere) Manpages auch für Anfänger lesbar und zumindest teilweise verständlich. Man muss manchmal den Mut haben, die Seite nur teilweise zu verstehen und den Rest durch Probieren herauszufinden oder als für das momentane Problem unwichtig beiseite zu legen. Man kann nicht alles gleichzeitig verstehen, und alles über Linux weiß sowieso niemnand. Ich persönlich stehe mit "info" auf Kriegsfuß. Es mag praktisch sein für den, der vom Emacs (Editor) kommt. Zur Not finde ich die notwendigsten Infos, aber nach Möglichkeit suche ich woanders. Zu dem "*": Es gibt in Unix/Linux 2 verschiedene "Ebenen", auf denen mit sog. "Mustern" gearbeitet wird. Die eine ist die Ersetzung von Dateinamen, dabei steht der * für eine beliebige Folge von Zeichen und das ? für ein Einzelzeichen. Dies wird durch die bash und andere shells benutzt. Die andere ist die Ersetzung von Dateiinhalten oder Strings, hier steht der "." für ein Einzelzeichen. Der * wiederholt 0 bis n-mal das vorstehende Muster. Deshalb ist ".*" jedes Zeichen beliebig oft. Daneben gibt es Auswahlen von Einzelzeichen, z.B. [afx], die auch mit * verlängert werden können, Zeichenbereiche [a-x] , ..., ... und ... . Diese Ausdrücke werden von Editoren und anderen Programmen unterstützt. Hier die Übersicht zu behalten, ist zu Anfang schon schwierig, insbesondere dadurch, dass die einfache Faustregel Dateiname/Inhalt dann nicht mehr gilt, wenn der Dateiname als String weiterverarbeitet wird. Hier kann man aus Platzgründen nur auf Manpages oder zum Lernen auf Bücher verweisen. Anstelle von Drohbriefen: Lies die Manpage! ;-) Aber lies sie nicht allein, sondern nur zusätzlich zu weiteren Quellen. Vieles wird plötzlich klar(er), wenn man die Informationen übereinander legt. Gruß, Wolfgang PS: Ich habe mich oben sicher nicht streng technisch richtig ausgedrückt, aber vielleicht ist es so ein bischen verständlicher.

Am Mit, 2003-06-25 um 20.53 schrieb Kristian Koehntopp:

On Wed, Jun 25, 2003 at 05:32:09PM +0200, Wolfgang Hinsch wrote:

kdehelp verwenden (Alt-F2, info:/dir eingeben).

Kommt auch, wenn man vom Rettungsring aus klickt. Bedienung ist zugegeben komfortabler, aber es fehlt eine vernünftige Gruppierung wie in man (1-8). Außerdem sind für relativ wenige Kommandos info-Pages vorhanden, und die Weiterleitung auf man läuft nicht.

...

Zu dem "*": Es gibt in Unix/Linux 2 verschiedene "Ebenen", auf denen

mit

...

sog. "Mustern" gearbeitet wird.

Seit einigen Jahren 3:

- Shell Globs (aka Shell Wildcards, also "*", "?" und "[a-z]". Wird in sh, csh, ksh, bash, zsh und anderen verwendet. - Posix Regular Expressions mit leichten Variationen, wird in grep/egrep, sed, vi und vielen anderen verwendet. - PCRE, Perl Compatible Regular Expressions, ein recht mächtiger Superset von Posix Regular Expressions. PCRE wird von perl verwendet, von Exim (ja, einem Mailer) und von PHP, sowie von zunehmend mehr Tools.

OK, für Perl muss ich mir irgendwann einmal Zeit nehmen. Für alles, was eine Druckseite übersteigt, greife ich zu C oder C++. Ich hasse (/\$?*\*[&%$``].)*.!

Kristian

Schätze, Deine 2 PM waren verklickt. Gruß, Wolfgang

Am Don, 2003-06-26 um 21.17 schrieb Bernd Brodesser:

* Wolfgang Hinsch schrieb am 26.Jun.2003:

An den info-Pages mag ich nicht die fehlende Einheitlichkeit. Wenn man was sucht ist man oft aufgeschmissen.

Nett, dass man hier mal jemanden trifft, der auch kein info-Fan ist. Man fühlt sich sonst ja fast wie ein Dissident;-)

...

OK, für Perl muss ich mir irgendwann einmal Zeit nehmen. Für alles, was eine Druckseite übersteigt, greife ich zu C oder C++. Ich hasse (/\$?*\*[&%$``].)*.!

Dann nimm Dir keine Zeit für perl, Du wirst enttäuscht sein, oder besser noch, nimm Dir doch Zeit für perl und lerne die RegExp lieben. Du wirst Dich wundern was man damit alles machen kann. Da hilft einem C oder C++ auch nicht weiter. Klar geht es damit, die meisten Programme, die RegExp benutzen sind ja in C geschrieben, und es gibt auch eine C-Bibliotheksfunktion regex Siehe man 3 regex

Da habe ich mich offensichtlich missverständlich ausgedrückt. Klar sind regex eine super Sache, auch wenn es sie jetzt in 3 Haupversionen gibt. Mir geht es mehr um den Rest der shell-Programmierung. Versuche nur einmal, Texte oder Konfig-Files in bash einzulesen. Natürlich geht das. Man muss nur immer sorgfältig Backslashes und Anführungszeichen und Hochkommata und wissen die Götter was noch setzen und daran denken, dass bei der Übergabe in eine sub-shell der \ verschwindet und deshalb \\\* schreiben, und wenn man aus irgendeinem Grund etwas ändert und eine weitere shell ins Spiel kommt, nur mal eben in \\\\\\* ändern, ....

Aber wie willst Du es machen, wenn Du etwa

durch ersetzen willst, die ... für beliebige Zeichen stehen aber kein > und kein Zeilenumbruch darin sein darf?

Klar da kann man mit viel Aufwand eine unflexible C-Routine bauen oder aber s/]*\)Ende>//g nehmen.

Das ist ein Super-Beispiel bezüglich der Lesbarkeit. Stell Dir nur das ganze noch komplexer und über eine halbe Seite ausgedehnt vor. Im Grunde ist es ähnlich unflexibel wie C. Während man es schreibt, ist eigentlich alles klar. Muss man es nach einem halben Jahr verändern, geht das zwar mit sehr wenig Aufwand, aber man braucht vorher einige Zeit, um zu verstehen, was da passiert und nachher u.U. noch mehr Zeit für Fehlersuche. Wobei ich im konkreten Fall natürlich auch bash nehmen würde, da gebe ich Dir recht. Mir geht es im Grunde weniger um regex als um Sachen wie IFS, Thema Dateinamen mit Leerzeichen und anderen Verzierungen dank M$. Hier bin ich mit einer Sprache wie C++ um einiges schneller und sicherer. Allerdings nicht bei einem Dreizeiler. Übrigens ist es für mich immer eine Sache der Abwägung, wie oft wird das Programm aufgerufen/wie schnell muss es fertig sein/wieviel Aufwand ist gerechtfertigt/muss es später angepasst werden. Besonders schön ist es, ein älteres, von mehreren geändertes shell-Script lesen und verstehen zu müssen. Ein Kollege hat früher mal bash-Programme geschrieben, die komplexe Datenumwandlungen und Berechnungen durchführten. Funtioniert, ist super-langsam, unlesbar, nicht zu warten und zieht jede Menge Rechnerleistung (da fast nur am forken). Ich hatte früher einmal awk benutzt, da waren einige Sachen übersichtlicher. Ich denke, dass Perl da auch verschiedene Verbesserungen gegenüber bash bringt. Gruß, Wolfgang

* Horst Jäger schrieb am 25.Jun.2003:

1. "man find ist das was Du lesen solltest." haben einige geantwortet. Dazu muss ich ne Grundsatzerklärung loswerden:

Ich gebe Dir Recht, daß die manpage in erster Linie als Nachschlagewerk gedacht sind, und nicht als Tutorial. Trotzdem sind sie gut. Wenn man was nachschlagen will, dann stört nichts mehr als irgend ein blabla rundherum, den man zum Lernen zweifelsohne braucht. Es sind zwei verschiedene Dinge. Wenn Dich jemand auf manpages hinweist, so versteh das doch nicht als Klatsche. So ist das ganz bestimmt nicht gemeint. Man sieht es Dir doch nicht an, inwieweit Du schon Erfahrung mit Linux hast. Auch wenn Du ein Newbie bist, so heißt das nicht allzuviel. Die Lernkurve ist nun mal bei Linux steil. find ist ein mächtiges Werkzeug, mit dem man massig viel machen kann. Daher ist es vielleicht auch besser, wenn Du nicht als erstes sowas kompliziertes machst, wie nach bestimmten Dateien mit bestimmten Inhalten zu suchen. Es nützt doch nichts, wenn Du hier von der Liste Kochrezepte erhälst, bist aber selber nicht in der Lage sie abzuwandeln, vielleicht abgesehen von anderen Namen. Es wäre schon gut, wenn Du das alles auch verstehst. Und das willst Du offensichtlich auch.

find / -iname '*.txt' -exec grep egal {} \; tut's, aber klappt nicht mit z.B. egal* . Das Problem hatte ich früher schon: man muss Anführungszeichen setzen ("egal*" ) und das klappt auch nicht - jemand hat mich auch in seiner Mail davor gewarnt.

Du hast ja schon eine Menge Hinweise bekommen. Aber Deine Anmerkung zu den Anführungszeichen weist darauf hin, daß Du etwas ganz Grundsätzliches noch nicht verstanden hast. Es ist für einen Anfänger auch nicht leicht zu durchblicken, nämlich, was macht die shell und was macht ein einzelnes Programm. Bitte sei mir nicht böse, wenn ich Dir was erzähle, was Du schon weißt. Aber ich fange lieber von unten an, als daß ich was vorraussetze, was Du nicht weißt. Als erstes sollte Dir klar sein, was man macht, wenn man an der Konsole sitzt, oder einem Xterm, oder der KDE-Konsole oder was es sonst noch so an Terminalemulatoren gibt. Man gibt was ein, und bekommt evtl. was zurück und dann kommt ein Prompt, wo man wieder was eingeben kann. Dies alles macht die shell, meist ist es die bash, eine spezielle shell, andere shells sind ksh, tcsh, csh, zsh und viele andere. Meist hat man bei Linux aber die bash und da gehe ich mal von aus, daß Du die auch hast. Die bash benutzt Du interaktiv. Das heißt, Du gibst was am Prompt ein, die shell macht was draus und Du bekommst das nächste Prompt. Normalerweise gibt man aber Befehle ein, die die shell nicht selber bearbeitet sondern das Kommando aufruft, das man angibt. Mal als Beispiel (Als Prompt wähle ich den UNIX-Standardprompt $, auch wenn SuSE da ein > nach Geraffele nimmt) $ ls -s /etc Wenn man sowas eingibt (das $ nicht, das soll der Prompt sein) dann ruft die shell den Befehl ls mit zwei Argumente auf, nämlich -s und /etc ls weiß damit was anzufangen, nämlich zum einen, daß es wegen des -s noch an jeder Datei die Größe mit ausgibt und zum anderen daß es die Dateien, die im Verzeichnis /etc stehen ausgeben soll. Jetzt mal angenommen, Du hast im Arbeitsverzeichnis ein Verzeichnis Test Verzeichnis Also mit Leerzeichen im Namen. Wen Du nun folgendes eingibst: $ ls Test Verzeichnis so ruft die shell den Befehl ls mit zwei Argumenten auf, einmal mit Test und zum anderen mit dem Argumenten Verzeichnis. Das sind beides keine Options. Also interpretiert ls beide Argumente als Dateinamen. Wenn es sowohl eine Datei oder Verzeichnis Test als auch Verzeichnis gibt, so gibt ls dies aus. Wenn es beide nicht gibt, so gibt es eine Fehlermeldung. In jedem Fall aber ist es nicht das, was man will, denn man will ja den Inhalt des Verzeichnisses Test Verzeichnis. Was also ist zu machen? Man muß das Leerzeichen, das die shell als Ternner zwischen den Argumenten interpretiert, maskieren. Das geht mit einem Backslash: $ ls Test\ Verzeichnis Nun ruft die shell den Befehl ls mit nur einem Argument auf, nämlich mit dem Argument Test Verzeichnis Man beachte, daß in dem Argument der Backslash \ nicht mehr vorkommt. ls sieht somit den Backslash nicht, und das ist auch gut so. Denn das Verzeichnis heißt ja Test Verzeichnis und nicht Test\ Verzeichnis. ls sieht wieder, daß Test Verzeichnis keine Option ist und gibt den Inhalt dieses Verzeichnisses aus, so wie gewünscht. Nun ist das mit den Backslashes etwas umständlich, wenn man mehere Leerzeichen hat. Daher gibt es noch andere Möglichkeiten: $ ls "Test Verzeichnis" Hier wird auch wieder der Befehl ls mit dem einen Argument Test Verzeichnis aufgerufen, also ganz genau wie im Beispiel davor. Es gibt mithin keinen Unterschied für ls. Eine weitere Möglichkeit wäre: $ ls 'Test Verzeichnis' Auch hier passiert genau das Gleiche. (Bitte ' nicht mit ` verwechseln, denn ` macht tatsächlich was völlig anderes als ') Sicherlich wußtest Du schon, was " und ' machen, aber wichtig ist zu sehen, was die shell macht, und was der Befehl. Ganz klar erkennt man das an Folgendem: $ ls foo* Hier ersetzt die shell den * mit allen Dateien und Verzeichnisse, die im aktuellen Verzeichnis stehen und mit foo beginnen. Angenommen dies sind foo, foobar und foobaz, dann macht die shell aus dem foo* folgendes: foo foobar foobaz und ruft den Befehl ls nun mit den drei Argumenten foo, foobar und foobaz auf. Es ist genauso als ob man $ ls foo foobar foobaz gesagt hätte. Der Befehl ls weiß nichts von dem * Wenn es keine Datei und kein Verzeichnis im Arbeitsverzeichnis gibt, das mit foo anfängt, so ersetzt die shell den * nicht und ls bekommt das Argument foo*. ls gibt dann eine Fehlermeldung aus, da es diese Datei ja nicht gibt. Hat man aber ein Verzeichnis das foo* heißt, also mit dem Stern, so muß man den wieder maskieren. Hier gleich alle drei Möglichkeiten: $ ls foo\* $ ls "foo*" $ ls 'foo*' in allen drei Fällen ruft die shell den Befehl ls mit dem einen Argument foo* auf. Hier erkennt ls, daß es sich nicht um eine Option handelt, und zeigt den Inhalt des Verzeichnisses foo* an. Wie auch immer ls interpretiert den * nicht. Das macht die shell, wenn ls den * von der shell durchgereicht bekommt, dann ist es für ls ein ganz normaler Bestandteil des Namens. Darum wird man in der manpage von ls auch nichts über den * finden, den ls macht damit nichts. Die manpages sind ja auch nicht nur für bash und andere shell Benutzer da, man kann ls ja etwa auch aus einem C Programm heraus aufrufen. Da kann man dann auch nicht mit * arbeiten, da muß man sich selber darum kümmern. (oder eine shell aufrufen, die das für einem macht) Wenn man das verstanden hat, dann versteht man z.B auch, warum $ mv *.old *.bak nicht funktionieren kann. Solltest Du noch Fragen haben, so frage bitte. Gilt natürlich auch für jeden anderen. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11

Am Mittwoch, 25. Juni 2003 16:27 schrieb Peter Wiersig:

Martin Schmiderer wrote:

...

man find ist das was Du lesen solltest.

Sicher nicht. "info find" ist ne andere Sache. Das sollte man mal lesen. Ist auch eher im Buch-Form.

Peter

Ich finde schon das der erste weg die manpage sein kann. Wenn man sich noch gar nicht mit Linux auskennt dann ist auch die info ganz schoen heftig zu lesen. Ich habe auch schon einige Buecher gewaelzt (von Koffler bis Hunt usw...) und ich bin wahrlich noch kein Meister (eher im gegenteil), aber in eine manpage schauen hat sich bis jetzt immer gelohnt (auch wenn ich nur den Hinweis auf die info befolgt habe ;-) Aber Linux macht super spass und ausprobieren/experimentieren ist einfach toll :-) regards Martin -- ________________________________creating IT solutions Martin Schmiderer science + computing ag System Administration Hagellocher Weg 71-75 phone +49 7071 9457 225 72070 Tuebingen, Germany fax +49 7071 9457 211 www.science-computing.de

Hallo flo, * Florian Gross schrieb am 24.Jun.2003:

Du machst dir das zu einfach. cat gibt wohl Dateiinhalte aus, aber in deinem Fall weiß das arme cat ja nicht mal, was es machen soll. Du machst dir das etwas zu einfach. So wie du das machen willst, mußt du erst die Dateinamen ermitteln und dann jeden Dateinamen an cat übergeben, also in der Art: find -iname "*.txt" | cat text1 text 2 usw.

Hä?

Das geht natürlich viel eleganter, nur weiß ich nicht, wie man sowas macht. Das wissenaber sicher andere hier. ;-)

Aber ich hoffe, daß du wenigstens erkennst, was dein Denkfehler war. (und daß ich mich halbwegs verständlich ausgedrückt habe)

Nein. ;) cat gibt die Inhalte von Dateien aus und hängt sie aneinander (conCATernat) Dabei gibt cat einfach die Inhalte der Dateien aus, die im Argument stehen, dabei steht - für die Standardeingabe. Wenn es kein Argument gibt, so wird ebenfalls die Standardeingabe genommen. Ist übrigens ein typisches Verhalten für Linuxbefehle. Bei Deiner obigen Zeile find -iname "*.txt" | cat text1 text2 schreibt find zwar was in die pipe rein, aber cat liest nichts aus, sondern gibt den Inhalt von text1 und von text2 aus. Was Dein Vorredner wollte ist in etwa das, was xargs macht. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0