Hallo, wenn ich find als user benutze, bekomme ich immer sehr viele Ausgaben für Dateien auf die ich keine Rechte habe. Kann man diese Ausgabe irgendwie unterbinden? Gruss Karl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Karl! Am Sonntag 07 März 2004 19:32 schrieb Karl Sinn:
wenn ich find als user benutze, bekomme ich immer sehr viele Ausgaben für Dateien auf die ich keine Rechte habe. Kann man diese Ausgabe irgendwie unterbinden?
Ja! Es gibt die Option -group <gruppenname> du kannst also find -group users benutzen, um nur Dateien zu bekommen, die "users" gehören... du kannst auch -user <username> anhängen... Das alles findest du übrigens in den manpages zu find! Schau das nächste mal, wenn du eine spezielle Funktion suchst, erstmal unter man <programm> nach! Aber nur so am Rande... MfG Kilian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAS2/mhuZOt9mSUIYRAm4gAKCTc/7w3jHgsUaNdBpL2zAuiJZWHgCffD+B 1jm9iMgYoxOK6KoZ4zYL2RA= =LHpX -----END PGP SIGNATURE-----
Am Sonntag, 7. März 2004 19:54 schrieb Kilian Kluge:
Am Sonntag 07 März 2004 19:32 schrieb Karl Sinn:
wenn ich find als user benutze, bekomme ich immer sehr viele Ausgaben für Dateien auf die ich keine Rechte habe. Kann man diese Ausgabe irgendwie unterbinden?
Ja! Es gibt die Option -group <gruppenname>
du kannst also find -group users benutzen, um nur Dateien zu bekommen, die "users" gehören... du kannst auch -user <username> anhängen...
Das alles findest du übrigens in den manpages zu find! Schau das nächste mal, wenn du eine spezielle Funktion suchst, erstmal unter man <programm> nach! Aber nur so am Rande...
Und was hat diese Option mit dem Anliegen von Karl zu tun? Er will die Fehlermeldungen unterdrücken, die find auswirft, wenn er zum Lesen von Verzeichnissen keine Rechte hat. Die von Dir genannten Optionen haben damit überhaupt nichts zu tun - sie begrenzen ja die Ergebnismenge, liefern also ein anderes Resultat: jan@roland:~> find /etc -group users -name passwd -print find: /etc/cups/certs: Keine Berechtigung find: /etc/cups/ssl: Keine Berechtigung find: /etc/httpd/ssl.key: Keine Berechtigung find: /etc/news: Keine Berechtigung find: /etc/opt/kde3/share/servicetypes: Keine Berechtigung find: /etc/sysconfig/network/providers: Keine Berechtigung find: /etc/ssl/private: Keine Berechtigung jan@roland:~> find /etc -name passwd -print /etc/passwd find: /etc/cups/certs: Keine Berechtigung find: /etc/cups/ssl: Keine Berechtigung find: /etc/httpd/ssl.key: Keine Berechtigung find: /etc/news: Keine Berechtigung find: /etc/opt/kde3/share/servicetypes: Keine Berechtigung find: /etc/sysconfig/network/providers: Keine Berechtigung /etc/pam.d/passwd find: /etc/ssl/private: Keine Berechtigung jan@roland:~> find /etc -name passwd -print 2>/dev/null /etc/passwd /etc/pam.d/passwd Du siehst den Unterschied? Das, was Karl sucht, findet er mit Sicherheit nicht unter *man find* - höchstens unter *man bash*. Jan
Am Sonntag, 7. März 2004 19:32 schrieb Karl Sinn:
wenn ich find als user benutze, bekomme ich immer sehr viele Ausgaben für Dateien auf die ich keine Rechte habe. Kann man diese Ausgabe irgendwie unterbinden?
Wie bei jedem anderen Befehl auch: Leite die Fehlerausgabe nach /dev/null um (siehst Du sehr oft hier in Beispielen): find ... 2>/dev/null Jan P.S.: Besorg Dir ein Buch zur Shell-Programmierung, wenn Dir "man bash" zu aufwändig ist - sowas ist Grundlagenwissen, ohne dass Du keine 2 Schritte weit auf der Shell kommst.
Am So, den 07.03.2004 schrieb Karl Sinn um 19:32:
wenn ich find als user benutze, bekomme ich immer sehr viele Ausgaben für Dateien auf die ich keine Rechte habe. Kann man diese Ausgabe irgendwie unterbinden?
Unabhängig jetzt mal von Jans korrekter Antwort: Kann es sein, daß du Dateien suchst, indem du mit find / -name "... arbeitest? Das ist korrekt, geht aber häufig anders sehr viel schneller. Jede Nacht läuft auf deinem Rechner "updatedb" und erstellt eine Datenbank mit allen Dateien. Diese kannst du einfach durchsuchen mit locate meinedatei das dauert nur Bruchteile von Sekunden. Das klappt natürlich nur, wenn die Datei beim letzten Lauf von updatedb auch schon vorhanden war. Da updatedb aber auch nichts anderes macht als du mit deinem find, ist es cleverer, eine zweite Shell aufzumachen, dort als root*) "updatedb" aufzurufen (dauert genau so lange wie dein "find") und danach mit "locate" zu suchen. Wenn du nämlich eine zweite (, dritte, vierte,...) Suchze startest, brauchst nur Sekundenbruchteile, statt das Filesystem nochmal komplett zu durchforsten. Und wenn die gesuchte Datei schon länger da ist, spartst du das updatedb sogar komplett. Ist immer einen Versuch wert. *) Zur Ausführung als root: Ich will nix falsches erzählen, auf meinem nicht-Suse-System ist das so. Guck lieber mal in /etc/cron*/updatedb, ob das bei Suse auch so gehandhabt wird. Gruß, Ratti P.S.: locate verwendet keine Pattern. Also /nicht/ eingeben: locate "*gesucht*" sondern einfach locate gesucht Wenn das zuviel findet, kannst du mit "|grep..." verfeinern. -- -o) Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Am Sonntag, 7. März 2004 21:47 schrieb Joerg Rossdeutscher: [...]
Kann es sein, daß du Dateien suchst, indem du mit
find / -name "...
arbeitest? Das ist korrekt, geht aber häufig anders sehr viel schneller.
Jede Nacht läuft auf deinem Rechner "updatedb" und erstellt eine Datenbank mit allen Dateien. Diese kannst du einfach durchsuchen mit
locate meinedatei [...]
Das macht aber nur dann Sinn, wenn auschliesslich nach dem Namen einer Datei gesucht wird - sobald eine andere find-Option (und davon gibt es ja ein paar ;-) benutzt wird oder ein anderes Ausgabeformat als -print oder eine Kommandoverkettung (-exec) muss doch wieder der find ran. Natürlich sollte man soweit wie möglich den Suchbereich einschränken, also nur im Ausnahmefall beginnend bei / suchen. Jan
Hallo Jan, Am Sonntag, 7. März 2004 21:31 schrieb Jan Trippler:
Natürlich sollte man soweit wie möglich den Suchbereich einschränken, also nur im Ausnahmefall beginnend bei / suchen.
Tja, ist mir klar, aber leider habe ich das gesamte Filesystem unter Linux noch nicht so richtig durchschaut. Deshalb bleibt mir im Moment noch nichts anderes übrig als alles zu durchforsten. Ich hoffe das gibt sich im Laufe der Zeit. Gruss Karl
Hallo Joerg, Am Sonntag, 7. März 2004 21:47 schrieb Joerg Rossdeutscher:
find / -name "...
arbeitest? Das ist korrekt, geht aber häufig anders sehr viel schneller.
Ja
Jede Nacht läuft auf deinem Rechner "updatedb" und erstellt eine Datenbank mit allen Dateien. Diese kannst du einfach durchsuchen mit
locate meinedatei
das dauert nur Bruchteile von Sekunden. Das klappt natürlich nur, wenn die Datei beim letzten Lauf von updatedb auch schon vorhanden war. Da updatedb aber auch nichts anderes macht als du mit deinem find, ist es cleverer, eine zweite Shell aufzumachen, dort als root*) "updatedb" aufzurufen (dauert genau so lange wie dein "find") und danach mit "locate" zu suchen.
Danke für den Tipp. Gruss Karl
Hallo! Am Sonntag, 7. März 2004 21:47 schrieb Joerg Rossdeutscher:
Jede Nacht läuft auf deinem Rechner "updatedb" und erstellt eine Datenbank mit allen Dateien. Diese kannst du einfach durchsuchen mit
locate meinedatei
das dauert nur Bruchteile von Sekunden.
Wenn ich häufiger hintereinander eine Suche starte, und sonst nichts mache, ist die zweite, ... Suche auch immer deutlich schneller als die erste. Anscheinend behält das Betriebssystem dann die Daten in irgendeinem Cache,
Das klappt natürlich nur, wenn die Datei beim letzten Lauf von updatedb auch schon vorhanden war. Da updatedb aber auch nichts anderes macht als du mit deinem find, ist es cleverer, eine zweite Shell aufzumachen, dort als root*) "updatedb" aufzurufen (dauert genau so lange wie dein "find") und danach mit "locate" zu suchen. Wenn du nämlich eine zweite (, dritte, vierte,...) Suchze startest, brauchst nur Sekundenbruchteile, statt das Filesystem nochmal komplett zu durchforsten. Und wenn die gesuchte Datei schon länger da ist, spartst du das updatedb sogar komplett. Ist immer einen Versuch wert.
*) Zur Ausführung als root: Ich will nix falsches erzählen, auf meinem nicht-Suse-System ist das so. Guck lieber mal in /etc/cron*/updatedb, ob das bei Suse auch so gehandhabt wird.
Gruß, Ratti
P.S.: locate verwendet keine Pattern. Also /nicht/ eingeben:
locate "*gesucht*" sondern einfach locate gesucht
Wenn das zuviel findet, kannst du mit "|grep..." verfeinern.
-- ------------------------------------------------------------------------------------ Thilo Gramlich Thilo (a dot) Gramlich (an at symbol) aktivanet (a dot) de
*** Thilo Gramlich (Thilo.Gramlich@aktivanet.de) schrieb heute in suse-linux:
[... 7 Zeilen Quoting ...] [... 4 Zeilen eigener Text ...] [... 24 Zeile überflüssiges Quoting ...]
Please read
http://learn.to/quote/
Thanks!
G Henning Hucke
--
"24-Aug-95 10:55:52 1> too many flames, message base is melting."
Matthias Scheler in
Am Sonntag, 7. März 2004 21:47 schrieb Joerg Rossdeutscher:
Jede Nacht läuft auf deinem Rechner "updatedb" und erstellt eine Datenbank mit allen Dateien. Diese kannst du einfach durchsuchen mit
locate meinedatei
das dauert nur Bruchteile von Sekunden.
[Schnipp ... korrekte aber eigentlich nicht weiterführende Aussagen zu locate entfernt] Wenn mehrere find kurz hintereinander ausgeführt werden, dann ist auch nur das erste recht langsam, die weiteren können offenbar auf einen Cache o.ä. zugreifen, der beim ersten find angelegt wird. Ist bei mir unter SuSE 8.1 zumindest so. Thilo -- ------------------------------------------------------------------------------------ Thilo Gramlich Thilo (a dot) Gramlich (an at symbol) aktivanet (a dot) de
*** Thilo Gramlich (Thilo.Gramlich@aktivanet.de) schrieb heute in suse-linux:
[...] Wenn mehrere find kurz hintereinander ausgeführt werden, dann ist auch nur das erste recht langsam, die weiteren können offenbar auf einen Cache o.ä. zugreifen, der beim ersten find angelegt wird.
Schonmal was von einem "Platten-Cache" gehört oder gelesen? (sigh!). G Henning Hucke -- "Ich weiß nicht mit welchen Waffen sich die Menschen im 3. Weltkrieg bekaempfen, aber im 4. werden es Keulen sein." (Albert Einstein)
participants (6)
-
Henning Hucke -
Jan.Trippler＠t-online.de -
Joerg Rossdeutscher -
Karl Sinn -
Kilian Kluge -
Thilo Gramlich