Hallo,
irgendwas stimmt bei mir mit dem Alsa-System nicht; beim Booten
bekomme ich haufenweise Fehlermeldungen No soundcards found, die von
/etc/init.d/alsa-utils ausgelöst werden:
Astor:~# alsactl restore 0
alsactl: load_state:1341: Cannot find soundcard '0'...
# alsactl names
alsactl
Am Mittwoch, den 25.10.2006, 09:38 +0100 schrieb Amir Tabatabaei:
Vielen Dank, es läuft jetzt. Die Frage bleibt jedoch, warum es vorher
nicht ging. Die Kiste läuft jetzt seit Jahren und /dev/hda5 war schon
immer eine Swap-Partition, die auch immer funktioniert hat. Wieso ist
plötzlich die
Einen wunderschönen,
seit einiger Zeit bekomme ich beim hochfahren meines Rechners die
folgende Meldung:
Activating swap: swapon on /dev/hda5
Unable to find swap-space signature
swapon: /dev/hda5: Invalid Argument
Woran liegt das? Wenn es manuell versuche, bekomme ich folgendes:
rechner
On Tue, Oct 24, 2006 at 08:45:36PM +0100, Amir Tabatabaei wrote:
Einen wunderschönen,
seit einiger Zeit bekomme ich beim hochfahren meines Rechners die
folgende Meldung:
Activating swap: swapon on /dev/hda5
Unable to find swap-space signature
swapon: /dev/hda5: Invalid Argument
Woran
Am Dienstag, den 24.10.2006, 20:45 +0100 schrieb Amir Tabatabaei:
Einen wunderschönen,
seit einiger Zeit bekomme ich beim hochfahren meines Rechners die
folgende Meldung:
Activating swap: swapon on /dev/hda5
Unable to find swap-space signature
swapon: /dev/hda5: Invalid Argument
Bitte
On Wednesday 23 August 2006 20:22, Gebhard Dettmar wrote:
On Wednesday 23 August 2006 14:51, Juergen Christoffel wrote:
On Wed, Aug 23, 2006 at 11:38:58AM +0200, Gebhard Dettmar wrote:
On Tuesday 22 August 2006 16:39, Juergen Christoffel wrote:
[...]
[...]
... bei mir find -regex
On Tuesday 22 August 2006 16:39, Juergen Christoffel wrote:
On Tue, Aug 22, 2006 at 10:06:36AM +0200, Gebhard Dettmar wrote:
Aber ich kapiere find -regex eh nicht so ganz. Ich habe Dateien wie
geb.jpg, gebI.jpg, gebII.jpg usw. find -regex geb.* matcht die
nicht, da muss noch ein .* davor
a im Namen enthalten, sondern nur die, die
exakt a heissen (incl. Directories im Path).
Äh, Moment, das findet gar nichts.
Doch:
touch a
find * -regex a
a
Ich schrieb ja zuvor, Du musst find * -op nehmen anstatt find . -op
oder find -op damit nicht der ./ davor erscheint.
Um also
On Wednesday 23 August 2006 14:51, Juergen Christoffel wrote:
On Wed, Aug 23, 2006 at 11:38:58AM +0200, Gebhard Dettmar wrote:
On Tuesday 22 August 2006 16:39, Juergen Christoffel wrote:
[...]
Äh, Moment, das findet gar nichts.
Doch:
touch a
find * -regex a
a
Stimmt
Ich
On Monday 21 August 2006 19:14, Andreas Vögele wrote:
Gebhard Dettmar schreibt:
Daher bleibt die Frage:
Wie rufst du das auf mit find?
Am besten, so wie ich das vorgeschlagen habe, ganz ohne die Option
-regex :-) Die Option -regex ist nämlich nicht portabel und wird nur
von GNU find
On Tue, Aug 22, 2006 at 10:06:36AM +0200, Gebhard Dettmar wrote:
Aber ich kapiere find -regex eh nicht so ganz. Ich habe Dateien wie
geb.jpg, gebI.jpg, gebII.jpg usw. find -regex geb.* matcht die nicht, da
muss noch ein .* davor, also .*geb.* Nehme an, das liegt daran, dass
find bei der
Hallo Liste
nochmal ne Frage zu Dateiendungen.
Wie muss ein Ausdruck ausschauen der sowohl .jpg als auch .jpeg einbindet
(jp[eg]) sieht alle jpg-Dateien aber keine jpeg-Dateien
(jp[eg][g]) sieht nur jpeg-Dateien
(jp[eg]*) sieht .jpg und .jpeg aber auch jpeg.converted.png die ich aber
nicht
, die du bei find
escapen musst (unescaped geht das z.B. mit egrep (grep -E)).
In der Bash funktioniert:
find -regex .*\.jp\(eg\|g\)
In anderen Shells musst du evtl. anders escapen.
--
MfG Jan
Open WebMail Project (http://openwebmail.org)
--
Haeufig gestellte Fragen und Antworten (FAQ):
http
Thorsten Hamester schreibt:
Hallo Liste
nochmal ne Frage zu Dateiendungen.
Wie muss ein Ausdruck ausschauen der sowohl .jpg als auch .jpeg einbindet
find . \( -name \*.jpg -o -name \*.jpeg \) -print
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user
, danach evtl. aber nicht notwendig ein e,
danach ein g. Alle, außer dem e, müssen auftauchen -- du musst beim e
einen Quantifizierer hinzufügen, der genau das sagt, nämlich dass e
auftauchen kann, aber nicht muss.
Das ist ganz einfach jpe?g, Klammern brauchst du dafür nicht:
find -regex .*jpe?g
liefert
greedy!!!). e und g gibts nicht nur in jpe?g, sondern auch in
converted.png, ergo matcht er die, gierig wie er ist.
Sorry, da hab ich Quatsch erzählt - mit aller Gierigkeit kann (jp[eg]*)
z.B. converted nicht matchen, da keine jp davor. Mit find matcht dieser
Ausdruck eigentlich gar nichts, da es
On Monday 21 August 2006 16:06, Gebhard Dettmar wrote:
On Monday 21 August 2006 15:21, Gebhard Dettmar wrote:
[...]
z.B. converted nicht matchen, da keine jp davor. Mit find matcht dieser
Ausdruck eigentlich gar nichts, da es IMHO keine runden Klammern kennt.
Nochmal sorry, da muss ich
Gebhard Dettmar schreibt:
Daher bleibt die Frage:
Wie rufst du das auf mit find?
Am besten, so wie ich das vorgeschlagen habe, ganz ohne die Option
-regex :-) Die Option -regex ist nämlich nicht portabel und wird nur
von GNU find unterstützt.
--
Haeufig gestellte Fragen und Antworten (FAQ
Hallo Gebhard Dettmar und alle anderen
erstmal danke fuer Deine ausfuehrlichen Erklaerungen.
Ich habe es in der bash so aufgerufen wie jan Kohnert es beschrieben hat
und das lief wunderbar, war leider etwas unter Zeitdruck gestern, daher
die schnelle Umsetzung und die spaete Antwort heute.
ja hallo erstmal,..
ich stehe hier derzeit vor einem eigenartigen find-Problem. Ich wollte im
firefox-Verzeichnis die Datei all.js suchen - diese ist auch da:
gyro-gearloose:/usr/lib/firefox# ls -lh greprefs/all.js
-rw-r--r-- 1 root root 61K 2006-06-25 21:31 greprefs/all.js
Da mir der genau Ort
Hallo,
gyro-gearloose:/usr/lib/firefox# ls -lh greprefs/all.js
-rw-r--r-- 1 root root 61K 2006-06-25 21:31 greprefs/all.js
$ file /usr/lib/firefox/greprefs
/usr/lib/firefox/greprefs: symbolic link to
`../../share/firefox/greprefs'
man find:
-P Never follow symbolic links
to
`../../share/firefox/greprefs'
man find:
-P Never follow symbolic links. This is the default behaviour...
Also:
greprefs ist ein symbolischer Link. Dem folgt 'find' nicht von alleine.
Wenn Du das willst, brauchst Du die '-L' Option.
Eh? bei symbolischen Links sieht ls -lh aber anders aus.
Z.B
/greprefs
/usr/lib/firefox/greprefs: symbolic link to
`../../share/firefox/greprefs'
man find:
-P Never follow symbolic links. This is the default behaviour...
Also:
greprefs ist ein symbolischer Link. Dem folgt 'find' nicht von alleine.
Wenn Du das willst, brauchst Du die '-L
Am Donnerstag 27 Juli 2006 11:26 schrieb Jan Luehr:
Am Donnerstag, 27. Juli 2006 09:52 schrieb Thomas Weber:
greprefs ist ein symbolischer Link. Dem folgt 'find' nicht von
alleine. Wenn Du das willst, brauchst Du die '-L' Option.
Eh? bei symbolischen Links sieht ls -lh aber anders aus
Hallo,
da der Apache2 Proxy seinen Cache nicht selbst aufräumt, möchte ich per
Script und Anacron für Platz sorgen.
Deshalb habe ich folgendes in ein Script geschrieben:
find /var/cache/apache2/proxy/ -atime +10 -exec /bin/rm \{\} ;
So wie ich man find verstanden habe, müsste es so richtg
Hi,
Juergen Kosel wrote:
Hallo,
da der Apache2 Proxy seinen Cache nicht selbst aufräumt, möchte ich per
Script und Anacron für Platz sorgen.
Deshalb habe ich folgendes in ein Script geschrieben:
find /var/cache/apache2/proxy/ -atime +10 -exec /bin/rm \{\} ;
versuchs mal so:
find /var
Juergen Kosel [EMAIL PROTECTED]:
find /var/cache/apache2/proxy/ -atime +10 -exec /bin/rm \{\} ;
find /var/cache/apache2/proxy/ -atime +10 -exec /bin/rm \{\} \;
rm `find /var/cache/apache2/proxy/ -atime +10`
funktioniert leider nicht, wenn man erst nach n Monaten merkt, das
Apache2 fleißg
* Juergen Kosel (2006-04-11):
[...]
find /var/cache/apache2/proxy/ -atime +10 -exec /bin/rm \{\} ;
-exec rm {} \;
-Andre
pgp0d26V0BRpb.pgp
Description: PGP signature
Reinhold Plew schrieb:
versuchs mal so:
find /var/cache/apache2/proxy/ -atime +10 -exec /bin/rm {} \;
Danke, das war's.
Gruß
Jürgen
--
Homepage: http://people.freenet.de/Juergen-Kosel/
PGP-Key : http://people.freenet.de/Juergen-Kosel/passwd.pgp
signature.asc
Description: OpenPGP
192.168.1.101 ns2
Server: ns2
Address:192.168.1.100#53
*** Can't find 101.1.168.192.in-addr.arpa.: No answer
host -v -t soa client1 ns2
Trying client1.local.pinguin.uni.cc
Using domain server:
Name: ns2
Address: 192.168.1.100#53
Aliases:
;; -HEADER- opcode: QUERY, status: NOERROR, id
Am Donnerstag, 19. Januar 2006 23:01 schrieb Ulrich Zehl:
er der folgenden beiden Zeilen. Reverse-Daten müssen
entweder als FQDN (also eben ver.keh.rte.ip.in-addr.arpa.) oder relativ
zur Zone) angegben werden.
99 IN PTR client1.local.pinguin.unu.cc.
On 27.Aug 2005 - 00:16:01, Holger Leskien wrote:
Hallo,
On Tue, Aug 23, 2005 at 06:09:51PM +0200, Andreas Pakulat wrote:
zum Paket das bootclean.sh enthaelt. Wer unstable nutzt sollte sich
ueber sowas nicht aufregen ;-)
Ich verwende testing und bin mir über die Risiken bewusst.
Ist
Hallo,
On Tue, Aug 23, 2005 at 02:32:42PM +0200, Daniel Leidert wrote:
Updating mozilla-thunderbird chrome registry...find: warning: you have
specified the -maxdepth option after a non-option argument -name, but
options are not positional (-maxdepth affects tests specified before
Hallo,
On Tue, Aug 23, 2005 at 06:09:51PM +0200, Andreas Pakulat wrote:
zum Paket das bootclean.sh enthaelt. Wer unstable nutzt sollte sich
ueber sowas nicht aufregen ;-)
Ich verwende testing und bin mir über die Risiken bewusst. Ich hatte
beim - zugegebenermassen oberflächlichen - Suchen
Hallo,
folgende Fehlermeldung habe ich gerade beim De-/Installieren bekommen:
Removing mozilla-thunderbird-enigmail ...
Updating mozilla-thunderbird chrome registry...find: warning: you have
specified the -maxdepth option after a non-option argument -name, but
options are not positional
Am Dienstag, den 23.08.2005, 14:20 +0200 schrieb Holger Leskien:
folgende Fehlermeldung habe ich gerade beim De-/Installieren bekommen:
Removing mozilla-thunderbird-enigmail ...
Updating mozilla-thunderbird chrome registry...find: warning: you have
specified the -maxdepth option after a non
Hallo Holger!
On Tue, 23 Aug 2005 14:20:21 +0200 Holger Leskien [EMAIL PROTECTED] wrote:
habe aber bisher noch keine entsprechenden Bugreports in
den betroffenen Paketen gesehen. Bin ich der einzige, bei dem so etwas
auftaucht?
Bug-Report existiert:
On [Tue, Aug 23 14:20], Holger Leskien wrote:
Hallo,
Aloha,
options are not positional (-maxdepth affects tests specified before it
as well as those specified after it). Please specify options before
other arguments.
Das hatte ich die Tage auch mal. Ist nur eine Warnung:
$ find . -name
On 23.Aug 2005 - 14:20:21, Holger Leskien wrote:
Hallo,
folgende Fehlermeldung habe ich gerade beim De-/Installieren bekommen:
Removing mozilla-thunderbird-enigmail ...
Updating mozilla-thunderbird chrome registry...find: warning: you have
specified the -maxdepth option after a non-option
On Thu, Aug 04, 2005 at 06:17:03PM +0200, Werner Zacherl wrote:
Welchen Befehl habe ich vergessen?
man xargs.
Macht die Ausfuehrung um einiges schneller. Und dann schreibt
man's so: find ... -print0 | xargs -0 cp --target=/tmp/
Peter
--
Haeufig gestellte Fragen und Antworten (FAQ):
http
Am Friday, 5. August 2005 21:08 schrieb Peter Wiersig:
On Thu, Aug 04, 2005 at 06:17:03PM +0200, Werner Zacherl wrote:
Welchen Befehl habe ich vergessen?
man xargs.
Macht die Ausfuehrung um einiges schneller. Und dann schreibt
man's so: find ... -print0 | xargs -0 cp --target=/tmp/
Peter
Hallo Leute,
ich möchte gerne einige über die Platte verteilte Dateien in einem
Verzeichnis sammeln.
Dabei dachte ich es gehe wie folgt.
find ~/home/verzeichnis/ -name *.wav -exec \ cp {} /tmp/ \;
Geht aber nicht. Der find Aufruf allein geht, also liegt es an meinem
exec Aufruf.
Welchen
am 04.08.2005, um 18:17:03 +0200 mailte Werner Zacherl folgendes:
Hallo Leute,
ich möchte gerne einige über die Platte verteilte Dateien in einem
Verzeichnis sammeln.
Dabei dachte ich es gehe wie folgt.
find ~/home/verzeichnis/ -name *.wav -exec \ cp {} /tmp/ \;
Geht aber nicht. Der
Am Thursday, 4. August 2005 18:52 schrieb Andreas Kretschmer:
am 04.08.2005, um 18:17:03 +0200 mailte Werner Zacherl folgendes:
Hallo Leute,
ich möchte gerne einige über die Platte verteilte Dateien in einem
Verzeichnis sammeln.
Dabei dachte ich es gehe wie folgt.
find ~/home
Am 2005-08-04 18:17:03, schrieb Werner Zacherl:
Hallo Leute,
Geht aber nicht. Der find Aufruf allein geht, also liegt es an meinem
exec Aufruf.
Welchen Befehl habe ich vergessen?
schon mal:
find ~/home/verzeichnis/ -name *.wav -exec cp {} /tmp/ ';'
probiert?
cu
Werner
Greetings
Am 2005-07-26 02:15:19, schrieb Christian Selmer:
Hallo NG,
Mailingliste
Mir kam die Idee, vorher zu überprüfen, ob in diesem Verzeichnis ps-Dateien
liegen, die jünger als eine Minute sind, aber auch hier bräuchte ich ja den
'Erfolg' des find-Kommandos.
Hat jemand eine Idee?
So:
#!/bin
Hallo,
vergiß die vorherige E-Mail... :-)
Am 2005-07-26 02:15:19, schrieb Christian Selmer:
Hallo NG,
#!/bin/sh
while true
do
find /home/yy/lyx/ -maxdepth 1 -name '*.lyx' -cmin -1 -exec lyx -e ps {} \;
sleep 5
done
exit 0
Warum nicht:
8
Christian Selmer schrieb am Dienstag, 26. Juli 2005 um 02:15:19 +0200:
Hintergrund ist folgendes:
Auf meinem WindowsRechner arbeite ich mit lyx, wo leider die
Postscripterzeugung nicht funktioniert. Also kopiere ich die lyx-Dateien
auf einen Linuxrechner, erzeuge dort automatisiert
Joerg Friedrich schrieb:
Das ist doch krank.
nein, das ist nicht krank
Hat jemand eine Idee?
Ja, anstatt an den Symptomen herumzudoktern, versuche doch die
Postscripterzeugung auf dem Win-Rechner hinzubekommen.
Schlaumeier. Auch wenn du im Prinzip recht hast: Warum das so ist, must du
Hallo NG,
folgende Frage zu find:
Wie kann ich in einem Skript feststellen, ob find gemäß den formulierten
Bedingungen Datei(en) gefunden hat, dh 'erfolgreich' war. Der exit-Status
von find hilft hier wohl nicht weiter.
Hintergrund ist folgendes:
Auf meinem WindowsRechner arbeite ich mit lyx
* Christian Selmer [EMAIL PROTECTED] [26.07.2005 02:15:19 +0200]:
An folgendem Skript stört mich, dass die Postscripterzeugung ggf mehrfach
stattfindet, dh bis die lyx-Dateien älter als eine Minute sind.
Wie wär's denn einfach mit 'sleep 60'?
mfg, Thorsten
--
Haeufig gestellte Fragen und
Thorsten Zantis schrieb:
An folgendem Skript stört mich, dass die Postscripterzeugung ggf mehrfach
stattfindet, dh bis die lyx-Dateien älter als eine Minute sind.
Wie wär's denn einfach mit 'sleep 60'?
guter vorschlag, aber ich möchte die Postscript-Dateien so schnell wie
möglich haben und
Christian Selmer wrote:
Mir kam die Idee, vorher zu überprüfen, ob in diesem Verzeichnis ps-Dateien
liegen, die jünger als eine Minute sind, aber auch hier bräuchte ich ja den
'Erfolg' des find-Kommandos.
Hat jemand eine Idee?
_found=$($FIND $_dir -type f -name '*.ps' -cmin... 2 /dev/null
On Day 61 of Confusion 3171, Christian Selmer wrote:
Hallo NG,
folgende Frage zu find:
Wie kann ich in einem Skript feststellen, ob find gemäß den
formulierten Bedingungen Datei(en) gefunden hat, dh 'erfolgreich'
war. Der exit-Status von find hilft hier wohl nicht weiter.
Direkt geht das
Most people either dont have time or simply have no desire for a relationship.
Thats when we come in. Browse our list of profiles for just the type of sex
friend your searching for. Listings all over the US. Nail a chick tonight.
http://sss.pcmagsjell.com/wmld/fbs/
:~/bristuff-0.2.0-RC8h/zaphfc# make loadNT-debug
sync
modprobe zaptel
/lib/modules/2.4.27-powerpc/misc/zaptel.o: couldn't find the kernel
version the module was compiled for
/lib/modules/2.4.27-powerpc/misc/zaptel.o: insmod /lib/modules/2.4.27-
powerpc/misc/zaptel.o failed
/lib/modules/2.4.27-powerpc
Gerätetreibers
in den Kernen kam der folgende Fehler:
debian:~/bristuff-0.2.0-RC8h/zaphfc# make loadNT-debug
sync
modprobe zaptel
/lib/modules/2.4.27-powerpc/misc/zaptel.o: couldn't find the kernel version
the module was compiled for
/lib/modules/2.4.27-powerpc/misc/zaptel.o: insmod /lib/modules
Hi!
Ich will mit find in alle subdirs wechseln und einen Befehl ausfuehren...
also sowas wie: find -type d -exec 'cd \'{}'\ ; yydecode *' \;
also subdir finden, mit cd da rein wechseln und yydecode * ausfuehren...
leider funktioniert es so nicht...
die subdirs haben merkwuerdige namen mit
On Saturday 21 May 2005 14.00, Christoph Kaminski wrote:
Hi!
Ich will mit find in alle subdirs wechseln und einen Befehl ausfuehren...
also sowas wie: find -type d -exec 'cd \'{}'\ ; yydecode *' \;
find -type d -exec bash -c 'cd {} ; yydecode *' \;
Bei dir wir das ganze als ein befehl
Hallo zusammen
Ich moechte in einem Verzeichnis alle Dateien finden die neuer als
einen Tag alt sind und diese dann in ein neues Verzeichnis umkopieren.
Dabei sollte die Verz. Struktur erhalten bleiben.
Dabei habe ich folgende zwei Varianten probiert:
find . -ctime -1 -exec cp --preserve
folgende zwei Varianten probiert:
find . -ctime -1 -exec cp --preserve {} ../new/ \
(Funktioniert nicht, da dann der Inhalt des ganzen Verzeichnises
mitkopiert wird, in dem die neue Datei sich befindet)
find . -ctime -1 | xargs cp -R --preserve * ../trash/
(Funktioniert nicht
zwei Varianten probiert:
find . -ctime -1 -exec cp --preserve {} ../new/ \
(Funktioniert nicht, da dann der Inhalt des ganzen Verzeichnises
mitkopiert wird, in dem die neue Datei sich befindet)
find . -ctime -1 -type f -exec cp --preserve --parents {} ../new \;
--
Jörg Friedrich
folgende zwei Varianten probiert:
find . -ctime -1 -exec cp --preserve {} ../new/ \
(Funktioniert nicht, da dann der Inhalt des ganzen Verzeichnises
mitkopiert wird, in dem die neue Datei sich befindet)
Dem Find noch sagen, dass Du -type f suchst.
find . -ctime -1 | xargs cp -R --preserve
Hallo Joerg Matze
Vielen Dank fuer die rasche Hilfe die Loesung von Joerg funktioniert
einwandfrei
find . -ctime -1 | xargs tar -c | tar -xC ../new
Wieder alle Dateien mit (auch die alten .-), waere noch interessant zu verstehen warum das so ist??
Gruss einen schoenen Nachmittag;
Marc
El Wed, Feb 02, 2005 at 02:11:15PM +0100 Marc Demierre ha dit:
Hallo Joerg Matze
Vielen Dank fuer die rasche Hilfe die Loesung von Joerg funktioniert
einwandfrei
find . -ctime -1 | xargs tar -c | tar -xC ../new
Wieder alle Dateien mit (auch die alten .-), waere noch
Marc Demierre schrieb am Mittwoch, 02. Februar 2005 um 14:11:15 +0100:
Hallo Joerg Matze
Vielen Dank fuer die rasche Hilfe die Loesung von Joerg funktioniert
einwandfrei
find . -ctime -1 | xargs tar -c | tar -xC ../new
Wieder alle Dateien mit (auch die alten .-), waere noch
Am 2005-02-02 14:21:21, schrieb Joerg Friedrich:
Wenn eine Datei in einem Verzeichnis verändert wird, ändert sich auch
die ctime des Verzeichnisses. damit findet Dein find auch das
Öhm, - ctime ist die Create-Time,
was du meinst ist die mtime, also die Modified-Time
Verzeichnis und tar
Michelle Konzack schrieb am Mittwoch, 02. Februar 2005 um 14:39:25 +0100:
Am 2005-02-02 14:21:21, schrieb Joerg Friedrich:
Wenn eine Datei in einem Verzeichnis verändert wird, ändert sich auch
die ctime des Verzeichnisses. damit findet Dein find auch das
Öhm, - ctime ist die Create-Time
Verzeichnisses. damit findet Dein find auch das
Öhm, - ctime ist die Create-Time,
was du meinst ist die mtime, also die Modified-Time
Nein ich meine ctime.
ctime steht _nicht_ für Create-Time
aus 'info find':
===SNIP=
File: find.info, Node: Time, Next: Size, Prev: Links, Up
n'Abend,
ich versuche, eine Feather-Linux (= Mini-Knoppix) zu remastern und befolge
dabei die Feather Linux Remastering Mini-HOWTO unter
http://featherlinux.berlios.de/remastering.html.
Wenn ich meine Iso-Datei dann mit qemu teste, bekomme ich die Meldung:
can't find Feather Linux Filesystem
Befehl zu löschen:
bash-2.05b$ find /home/klaus/tatsachen -name * | xargs grep facts | rm -rf
{} \;
bekomme aber: xargs: grep: terminated by signal 13.
Was ist da falsch?
tschüs
Klaus
-deutschland.de
In der engl. Version kommt auf jeder Seite das Wort facts vor. Ich habe
daher versucht, die engl. Seiten mit folgendem Befehl zu löschen:
bash-2.05b$ find /home/klaus/tatsachen -name * | xargs grep facts | rm
-rf {} \;
bekomme aber: xargs: grep: terminated by signal 13
* Klaus Becker ([EMAIL PROTECTED]) wrote:
On Thursday 07 October 2004 21:25, Klaus Becker wrote:
Hallo,
ich habe die tatsachen-ueber-deutschland angesaugt und
unter /home/klaus/tatsachen abgelegt. Von den Sprachvarianten möchte ich
nur die deutsche + frz. behalten.
[lalalala]
du
. Was genau?
müsste ja dann ungefähr so aussehen:
find /dir -type d -name xxx -exec tar ??? wie nun weiter ?
Aha. Das sieht schon besser aus. find findet so also z.B. die
Verzeichnisse /dir/ein/Unterverzeichnis/Namens/xxx und
/dir/ein/Unterverzeichnis/Namens/xxx/xxx
(vorausgesetzt, es gibt sie).
Doch
Hallo,
folgendes möchte ich erreichen.
finde in /dir alle Verzeichnisse /xxx und mache dann ein .tar file
von jedem xxx Verzeichniss.
müsste ja dann ungefähr so aussehen:
find /dir -type d -name xxx -exec tar ??? wie nun weiter ?
--
Mario
--
Haeufig gestellte Fragen und Antworten (FAQ
Am Dienstag, 28. September 2004 21:14 schrieb Mario Duve:
folgendes möchte ich erreichen.
finde in /dir alle Verzeichnisse /xxx und mache dann ein .tar
file von jedem xxx Verzeichniss.
müsste ja dann ungefähr so aussehen:
find /dir -type d -name xxx -exec tar ??? wie nun weiter ?
Für jedes
: could not find path for libhpojip.so.0
dpkg-shlibdeps: warning: could not find path for libptal.so.0
--- snip --
Schau einmal nach, was das in unstable fuer pakete sind, die das
bereitstellen.
Jedes Paket erklaert, welche libs es in sich traegt, und
-shlibdeps: warning: could not find path for libhpojip.so.0
dpkg-shlibdeps: warning: could not find path for libptal.so.0
--- snip --
Ich versuche mal für mich (doof) zu übersetzen:
Während des Kompilierens ist dies nun ein freundlicher Hinweis. Wichtig
ist
und streng nach
Vorschrift (dpkg-buildpackage) daraus einen Backport für woody gebaut.
Die debs entstehen auch, allerdings sehe ich im output mehrere warnings
wie diese:
--- snip --
dpkg-shlibdeps: warning: could not find path for libhpojip.so.0
dpkg
Rüdiger Noack [EMAIL PROTECTED] writes:
find $3 ! \( [EMAIL PROTECTED] \) -a -newer archiv
Hier ^ ^ fehlen die Anführungszeichen. Mit
dem argv-Skript hättest du das eventuell gesehen.
Gruß,
Heike
--
Haeufig gestellte Fragen und Antworten (FAQ):
http
[EMAIL PROTECTED] (Heike C. Zimmerer) writes:
Rüdiger Noack [EMAIL PROTECTED] writes:
find $3 ! \( [EMAIL PROTECTED] \) -a -newer archiv
Hier ^ ^ fehlen die Anführungszeichen. Mit
dem argv-Skript hättest du das eventuell gesehen.
Das zweite ^ ist mir zu weit nach
Heike C. Zimmerer wrote:
Das zweite ^ ist mir zu weit nach rechts gerutscht. Das hast du
aber sicher schon gesehen. Die korrigierte Zeile nochmal:
find $3 ! \( [EMAIL PROTECTED] \) -a -newer archiv
Ganz so unbrauchbar ist meine Brille nun doch noch nicht. ;-)
Besten Dank noch einmal
Rüdiger Noack [EMAIL PROTECTED] writes:
Die saubere Lösung ist ein Array:
Besten Dank. Funktioniert prächtig. :-)
Merkwürdigerweise meckert aber der
-- snip --
find testdir ! \( -path 'testdir/Music' -prune -path \
'testdir/dir mit space' -prune \) -a -newer
Heike C. Zimmerer wrote:
Rüdiger Noack [EMAIL PROTECTED] writes:
Merkwürdigerweise meckert aber der
-- snip --
find testdir ! \( -path 'testdir/Music' -prune -path \
'testdir/dir mit space' -prune \) -a -newer letztes_backup
-- snip --
wenn ich
, das aus -path, einem Space, $3
usw. besteht. find erwartet sie aber getrennt, also so:
EXCL=([EMAIL PROTECTED] -path $3/$1 -prune)
Die Anführungszeichen bei path und prune sind nicht nötig, machen
meinen Punkt aber deutlicher.
Ich füge mal ein kurzes Skript an, das mir manchmal hilft
Heike C. Zimmerer wrote:
Hier fügst du *1* Argument hinzu, das aus -path, einem Space, $3
usw. besteht. find erwartet sie aber getrennt, also so:
EXCL=([EMAIL PROTECTED] -path $3/$1 -prune)
Das klingt ja alles ganz logisch, aber:
snip ---
[EMAIL PROTECTED]:/home
Heike C. Zimmerer wrote:
Das ist klar; die Anführungszeichen haben im String keine
Sonderbedeutung.
Die saubere Lösung ist ein Array:
Besten Dank. Funktioniert prächtig. :-)
Merkwürdigerweise meckert aber der
-- snip --
find testdir ! \( -path 'testdir/Music' -prune
Martin Schmitz wrote:
Wie jetzt? Differentiell oder incrementell? Oder doch voll? Egal.
Voll! Aber nur, wenn es irgendeine Änderung seit dem letzten Backup gab. ;-)
--
Gruß
Rüdiger
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN
Ruediger Noack [EMAIL PROTECTED] writes:
[EMAIL PROTECTED]:/home$ cat tar.sh
EXCL= $EXCL --exclude=\$1\
EXCL= $EXCL --exclude=\$2\
echo $EXCL
tar $EXCL -cvf /dev/null $3
[EMAIL PROTECTED]:/home$ ./tar.sh dir mit space Music testdir
--exclude=dir mit space --exclude=Music
tar: mit: Kann
Moin
Ruediger Noack wrote:
Nun schließe ich allerdings aus dem Sicherungsverzeichnis teilweise
Unterverzeichnisse (z.B. Browser-cache) aus: tar --exclude=dir -cf ...
Jetzt habe ich in diesem Zusammenhang noch ein Problem beim
Zusammenbasteln der exclude-Klausel. :-(
-- snip
Am 2004-04-03 11:07:38, schrieb Ruediger Noack:
Moin
Ebenfals...
Ratlos. :-( Ihr auch?
dir\ mit\ spaces sollte abhelfen
Danke und Gruß
Rüdiger
Greetings
Michelle
--
Registered Linux-User #280138 with the Linux Counter, http://counter.li.org/
--
Haeufig gestellte Fragen und Antworten
Ruediger Noack [EMAIL PROTECTED] writes:
Nun schließe ich allerdings aus dem Sicherungsverzeichnis teilweise
Unterverzeichnisse (z.B. Browser-cache) aus: tar --exclude=dir -cf ...
Und hier ist mein Problem: Ich habe noch keine elegante Möglichkeit
gefunden, meinem find -newer ebenfalls zu
Rüdiger Noack [EMAIL PROTECTED] writes:
Martin Schmitz wrote:
Spricht irgendwas dagegen, direkt tar entscheiden zu lassen, was
gesichert werden muß und was nicht. tar --newer= und tar --newer-mtime=
existieren.
Ich möchte gern Komplettsicherungen gewisser Verzeichnisse machen - aber
nur,
dieser Archive vor.
Einige dieser Sicherungsverzeichnisse sind relativ statisch. Deshalb
sichere ich nur bei Änderungen seit der letzten Sicherung (find dir
-newer letztes_archiv ...), um das Generationenkonzept nicht zu
unterlaufen. So weit so gut.
Nun schließe ich allerdings aus dem
(Notebook eben ;-) ), halte ich einige
Generationen dieser Archive vor.
Einige dieser Sicherungsverzeichnisse sind relativ statisch. Deshalb
sichere ich nur bei Änderungen seit der letzten Sicherung (find dir
-newer letztes_archiv ...), um das Generationenkonzept nicht zu
unterlaufen. So weit so gut
Michelle Konzack wrote:
Am 2004-04-02 12:07:30, schrieb Ruediger Noack:
Und hier ist mein Problem: Ich habe noch keine elegante Möglichkeit
gefunden, meinem find -newer ebenfalls zu verbieten, in diesen
Unterverzeichnissen zu suchen.
find -type f | grep -v Cache
Danke, aber das ist eben nicht die
Rüdiger Noack wrote:
Michelle Konzack wrote:
Am 2004-04-02 12:07:30, schrieb Ruediger Noack:
Und hier ist mein Problem: Ich habe noch keine elegante Möglichkeit
gefunden, meinem find -newer ebenfalls zu verbieten, in diesen
Unterverzeichnissen zu suchen.
find -type f | grep -v Cache
Danke
Philipp Meier wrote:
find /path -newer archive.tar.gz \! -path '/path/dir/to/exclude/*' ...
Wie kann man nur so blind sein! :-((
Danke und schönes Wochenende
Rüdiger
--
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie
Ruediger Noack [EMAIL PROTECTED] writes:
[...]
Nun schließe ich allerdings aus dem Sicherungsverzeichnis teilweise
Unterverzeichnisse (z.B. Browser-cache) aus: tar --exclude=dir -cf ...
Und hier ist mein Problem: Ich habe noch keine elegante Möglichkeit
gefunden, meinem find -newer
Hallo!
On Andreas Schmidt wrote:
On 2004.02.29 15:02, Matthias Kluwe wrote:
Hierfür könnte (ohne das Problem genau zu kennen) evtl.
for f in $(find . -maxdepth 1 -type f)
do
cat $f | formail -s procmail
mv mist $f.new
done
eine Lösung sein.
Nicht wirklich. Damit
1 - 100 von 190 matches
Mail list logo
