Nagy mennyiségű fájl törlése

Linux-haladó

Az a gondom, hogy ha elég sok fájl van egy könyvtárban, akkor az "rm *" parancs számára túl sok lesz a paraméter és leáll. Automatizálni szeretném ezt shell scriptből. Ha a teljes könyvtárat törlöm, akkor nincs gond, de én csak a fájlokat akarom.

  • 9709 megtekintés

( _folti_ | 2006. 11. 30., cs – 13:02 )

fapad megoldas: echo * | xargs rm [-f]

finomitaskent az echo helyett lehet pl find -ot hasznalni megfelelo parameterezessel.

Ha a file nevekben van pl space vagy egyeb spec karakter akkor az alabbi megoldassal probalkozz:
find -type f -maxdepth 1 -print0 | xargs -0 rm -f
Ez linuxon megy, 6.1 freebsd-n szinten, masrol nincs informaciom.

<nitpicking>

Tévedés. Az echo ugyanis shell builtin, így az ő esetében nincs ilyen korlát.

legtobb "user-friendly" shellben igen, van ahol viszont nem.

Nemi man olvasgatas utan:
builtin: bash, tcsh, zsh, dash, pdksh (NetBSD 3.0.1), csh (NetBSD 3.0.1)
kulso parancs: busybox sh(Debian Sarge 0.60), jsh(Solaris 9), /bin/sh (NetBSD 3.0.1)
Nem ismert(valoszinuleg nem builtin): ksh (AIX 5.2)

Ahol nem jeloltem os-t ott debian sarge alatt neztem.
</nitpicking>

> Nem ismert(valoszinuleg nem builtin): ksh (AIX 5.2)
Ezt pontositanad? Tudtommal mar a 3.x-es AIX verzioban levo ksh-ban is beepitett volt az echo, igaz 'alias echo=print' formaban, ha jol remlik.
Es hogy tisztazzuk: az eredeti /bin/sh az, amiben az echo kulso parancs (helye /bin/echo) - ennek reinkarnacioja ha jol tudom pl. Linux alatt az ash, meg HP-UX-on a /usr/old/bin/sh, meg az AIX-es, NetBSD-s /bin/sh, stb.

Ezt pontositanad? Tudtommal mar a 3.x-es AIX verzioban levo ksh-ban is beepitett volt az echo, igaz 'alias echo=print' formaban, ha jol remlik.

Ilyen melysegben nem neztem, csak - mint irtam - a man oldalak alapjan gyujtottem ki, hogy melyik shell mit tud. Az az AIX 5.2 -s gep amin neztem a ksh man oldala meglehetosen szukszavu volt ebben a kerdesben(jogi szoveget leszamitva nagyjabol az "en vagyok a ksh man oldala" szinten allt). Ettol meg lehet hogy igaz, ha jovo heten lesz idom ujra megnezem AIX -en(meg HP-UX -on is :).

NetBSD -n a man oldal szerint a /bin/sh az egy pdksh, de ezt szinten csak ilyen szinten neztem. A man oldal a buitin -ek kozott nem emlitette az echo-t.

A legjobb tudomasom szerit az ash az SVR4 unixokon hasznalt Bourne shell(/bin/sh) klonja/ujrairasa. A AIX -en es a NetBSD-n a /bin/sh az egy-egy ksh implementacio.

( uid_1062 | 2006. 11. 30., cs – 13:13 )

find /directory/ -type f -exec rm -f {} \;

A pontosvesszot a vegen escape-elni kell mert kulonben megeszi a shell.
Ennek azert megvan az a hatranya, hogy fajlonkent meghivja az rm parancsot :)

Amennyire én tudom, olyan shell nincs, amiben a szimpla balcici-jobbcici - gy.k.: {} önmagában spéci lenne - ezért nem kell takarni. *Elsősorban* a csh-szintaxisú shelleknél van az a{b,c}d jellegű konstrukciónak értelme. (Jó, itt kilóg manapság elég sok sh-szintaxisú is.)

( gsimon | 2006. 11. 30., cs – 13:28 )


OLDCWD=`pwd`
cd /
rm -rf $OLDCWD
mkdir -p $OLDCWD
cd $OLDCWD

Te meg öregszel, hogy erre a pimfli kis izére panaszkodsz, mikor van nagyobb baja is az ötletnek :) !
(Két shell, mindkettő az adott könyvtárban áll, az egyikben elindítod a fenti scriptet, a másik meg hanyattesik, mert megszűnik alatta a könyvtár, és az sem vígasztalja, hogy ugyanolyan néven keletkezett egy másik.)

No de ha már itt tartunk, mit csináljak, ha a könyvtárnév hossza egyezik a parancssor max. hosszával, azaz az 'mkdir x' még érvényes volt, de az 'rm -rf x' esetén a '-rf '-zel már túlnyúlik :) ?

> (Két shell, mindkettő az adott könyvtárban áll, az egyikben elindítod a fenti scriptet, a másik meg hanyattesik, mert megszűnik alatta a könyvtár, és az sem vígasztalja, hogy ugyanolyan néven keletkezett egy másik.)

Régen rossz, ha a shell ettől hanyattesik:


$ pwd
/tmp
$ mkdir lo
$ cd lo
$ rm -rf /tmp/lo
$ pwd
/tmp/lo
$ ls
$ ls -la
total 0
$ echo *
*
$

A max amit eddig láttam az az volt, hogy morgott, hogy nincs "." - de ilyenkor egy cd / általában magához téríti.

Jó, segfaultot ugyan nem dob, meg a macskám sem változik ügyvéddé tőle, de a 'régi' lo-ban állva természetszerűleg nem látszanak az 'új' lo-ban létrehozott file-ok: 


fules@rasta:/tmp/lo$ ls -l
total 0
fules@rasta:/tmp/lo$ ls -ld /tmp/lo
drwxr-xr-x  2 fules fules 4096 Dec  4 07:11 /tmp/lo
fules@rasta:/tmp/lo$ rm -rf /tmp/lo
fules@rasta:/tmp/lo$ ls -l 
total 0
fules@rasta:/tmp/lo$ ls -ld /tmp/lo
ls: /tmp/lo: No such file or directory
fules@rasta:/tmp/lo$ mkdir /tmp/lo 
fules@rasta:/tmp/lo$ ls -ld /tmp/lo
drwxr-xr-x  2 fules fules 4096 Dec  4 07:12 /tmp/lo
fules@rasta:/tmp/lo$ touch /tmp/lo/ujfile
fules@rasta:/tmp/lo$ ls -l
total 0
fules@rasta:/tmp/lo$ ls -l /tmp/lo/
total 0
-rw-r--r--  1 fules fules 0 Dec  4 07:12 ujfile
fules@rasta:/tmp/lo$

Egyszer már szívtam emiatt, amikor beágyazott rendszeren tmpfs-sel akartam felülmountolni az alap /dev-et, de addigra a syslog már rányitott a régi /dev-en lévő /dev/log-ra, úgyhogy az újban lévőn már senki sem figyelt. Szóval minden, a régi könyvtárat használó szutykot értesíteni kellene.

igy is kell mukodnie 


linux:/# uname -a
Linux linux 2.6.16.29-xen #2 SMP Sun Nov 12 00:49:40 CET 2006 i686 GNU/Linux
linux:/tmp/sar# rm -R /tmp/sar
linux:/tmp/sar# pwd
/tmp/sar
linux:/tmp/sar# cd /
linux:/# ls -la /tmp/sar
ls: /tmp/sar: No such file or directory
linux:/#

Ez pedig igy mukodik ;) Hanyatt nem dobja magat, bar nem csinal semmit. 


unix:/# uname -a
HP-UX unix B.11.23 U ia64 2699999999 unlimited-user license
unix:/tmp/sar# rm -R /tmp/sar
rm: directory /tmp/sar not removed.  Cannot remove current directory
unix:/tmp/sar# cd /
unix:/# rm -R /tmp/sar ; echo $?
0
unix:/#

Ahogy Zahy tanította: INABIAF!
Mondjuk célszerű lett volna jelezned, hogy milyen shell-ekkel próbálkozol, de így is el tudom képzelni, hogy a HP-UX-os shell-ben van egy ilyen "védelem", hogy a gyökér - bocs, root ;-) - felhasználó ne takarítson ki maga alatt.
Próbáld ki két terminálon, két shell-lel. Az egyikkel benne állsz a könyvtárban és a másikkal törlöd azt.

Ave, Saabi.

INABIAF :-D
Mindket shell csomagbol telepitett bash - tudom ez mar hiba ;-P

Latatlanul azt mondom, ha masik terminal fogja, akkor torolni fogja.
"igy is kell mukodnie",
Ezert zavaro a megkulonboztetes, ha magam fogom, vagy mas fogja - elvegre multi{user,task}
Ha akkor sem torlni, akkor en kerek elnezest.
Gondolatkiserletben fokozom a vedelmet:
[joke]
# shutdown -h -y 0
shutdown: Rejected. Cannot shutdown running system
[/joke]
Bar,
# init S
mar okozott meglepetest ;) egyszer

Ellenproba nem csak a bash a default shell se torli a . -t,
de masik konzolrol torolheto - szoval mi ellen ved ez a tulajdonsag ;) 


unix:/tmp/sar# uname -a
HP-UX unix B.11.23 U ia64 2699999999 unlimited-user license
unix:/tmp/sar# echo $SHELL
/sbin/sh
unix:/tmp/sar# rm -R /tmp/sar
rm: directory /tmp/sar not removed.  Cannot remove current directory
unix:/tmp/sar# pwd
/tmp/sar

itt torlom masik pts-en ezt a $PWD-t 


unix:/tmp/sar# cd ..
sh: ..:  not found.
unix:/tmp/sar# cd /
unix:/#

( nc | 2006. 11. 30., cs – 14:07 )

Az xargs azért jó megoldás, mert képes szétdarabolni megfelelő méretű részekre a paraméterlistát.

( egmont | 2006. 11. 30., cs – 14:27 )

find könyvtárnév -mindepth 1 -maxdepth 1 -print0 | xargs -0 -r rm -rf --

Érdekes..
.. nem az előbb irtad ezt:
> Namármost ha eleve olyan sok fájl van, hogy nem fér be a parancssorba, akkor asszem
> nem túl praktikus minden egyes fájl érdekében külön rm-et indítani.

Ajánlom figyelmedbe:

This manual page documents the GNU version of xargs. xargs reads arguments from the standard input,
delimited by blanks (which can be protected with double or single quotes or a backslash) or newlines,
and executes the command (default is /bin/echo) one or more times with any initial-arguments followed
by arguments read from standard input. Blank lines on the standard input are ignored.

Nem minden esetben. Amennyiben nincs --replace|-i vagy a --max-line|-l opcio akkor a megadott parancssor vegere csap max 1024 vagy a --max-args|-n szamu beolvasott argumentumot es ezt addig ismetli amig a bemenetrol el nem fogynak a leendo parameterek. Ellenkezo esetben tenyleg csak egyesevel dolgozik.

(Az 1024 -t a findutils 4.1.20 forrasbol neztem ki.) 


$ seq 20 | xargs -i% echo %". elem vagyok"
1. elem vagyok
2. elem vagyok
3. elem vagyok
4. elem vagyok
5. elem vagyok
6. elem vagyok
7. elem vagyok
8. elem vagyok
9. elem vagyok
10. elem vagyok
11. elem vagyok
12. elem vagyok
13. elem vagyok
14. elem vagyok
15. elem vagyok
16. elem vagyok
17. elem vagyok
18. elem vagyok
19. elem vagyok
20. elem vagyok
$ seq 20 | xargs -l6
1 2 3 4 5 6
7 8 9 10 11 12
13 14 15 16 17 18
19 20

A helyzet, hogy még nem igazán használtam ezt az xargs-ot.. nekem az jött le a man-ból,
hogy egyesével inditgat.. de kicsit elég kusza a man-ja.. meg kell hagyni, szóval lehet Neked
van igazad.

Bevallom nekem egyik megoldás sem tetszik.. nem "szépek", nem elegánsak..

Én ezt használnám a helyében:

tar -c --remove-files --file /dev/null ${DIRECTORY}

Ne haragudj, hogy megkérdem, a tesztet hány darab és milyen méretű fájllal végezted. Igenis nagyon sokkal rosszabb, irgalmatlanul sok fölösleges I/O terhelést ad a redszernek. Induljunk ki abból, hogy ahol az "Arg list too long" előfordul mindennapi életben, ott akár az is előfordulhat, hogy ez a pár száz :-) fájl több giga/tera darabonként.

És egy eddig még nem említett megoldás, noha ugyanaz a hiba előállhat, mint az eredetinél:

$ rm a* ; rm b* ; rm c* ; stb

(Megjegyzem, szerintem is a nagyon sokszor elhangzó find -print0|xargs -0 a nyerő, de főleg kereskedelmi Jujnikszok nem szeretik ezt a két spéci opciót.)

Szerintem egyrészt produktív rendszerre az ember nem kezd el mindenféle GNU-s cuccokat fordítgatni, másrészt amikor a millió file problémát okoz, akkor egy GNU tool letöltése, fordítása - pláne ha nincs fordító a gépen, tehát gcc-t is fordítani kell rá - sokkal tovább tarthat mint egy find -exec rm. Szerintem.

Ave, Saabi.

> egy GNU tool letöltése, fordítása - pláne ha nincs fordító a gépen, tehát gcc-t is fordítani kell rá

Ezt nagyon trukkosen mondtad, de eszrevettem: ha nincs rajta fordito, akkor a GCC-t se tudod forditani :-)
De koszonom, hogy nem nekem kellett megemliteni, hogy nem feltetlenul rakunk a gepre mindenfele nem feltetlenul tamogatott utilitast csak azert, mert lustak vagyunk vegigvarni hibas tervezesunk (esetleg) elore lathato kovetkezmenyeit.

Hajjaj, hogy pont te sétáltál bele ebbe az apró csapdába!
Hogy más oprendszerek alatt hogy megy, nem tudom, de a HP-UX-nak a kernelét olykor-olykor újra kell fordítani (legalábbis 11i v1 és annál korábbi változatoknál), ezért minden HP-UX-on van egy végletekig lebutított fordító program, ami a kernelfordításon kívül nem sok mindenre jó. Namármost a gcc telepítése HP-UX-on forrásból több lépésből áll, az első lépésben a HP-UX saját, buta fordítójával csinálsz valamit a gcc forrásból, ami már képes önmagát újra lefordítani. Aztán ezt még néhányszor megismétled, ha jól emlékszem. Mondjuk az tény, hogy ez nem naprakész információ, kb 7-8 éve töltöttem el ezzel egy napot. Manapság már letöltheted a HP-UX csomagkezelőjének megfelelő formában a HP-tól a gcc-t. Mondjuk ennek produktív rendszeren szerintem semmi keresnivalója nincsen.

Ave, Saabi.

Ja ha ugy nincs fordito, hogy van, az mas. Ezt egyebkent ismerem, en is csinaltam, csak nem HP-UX-on. Elso menet sajat forditoval gcc-t, masodik menet: eloallt primitiv gcc-vel gcc-t, es vegul harmadik menetben a mar jonak minositett gcc-bol csinalod a hivatalosat - ha jol emlekszem; de anno a telepitesi utmutatojaban is benne volt.

> Mondjuk ennek produktív rendszeren szerintem semmi keresnivalója nincsen.

Sajnos itt sokan ezt a mondatot nem hajlandok elfogadni.

Szerintem egyrészt produktív rendszerre az ember nem kezd el mindenféle GNU-s cuccokat fordítgatni,

Khmmm.... Bar a sunfreeware.com -on fentvan az adott csomag forrasa is, magat a leforditott csomagot is letoltheted. Lehet hogy nem fogalmaztam egyertelmuen, de en arra szerettem celozni hogy az adott rendszerre a kerdeses GNU utilok mar elore lefoditott(es a platform altal tamogatott) csomagkent rendelkezesre allnak.

Az termeszetesen egy masik kerdes, hogy production rendszerre nem biztos hogy celszeru 3rd party alkalmazas 4th party altal keszitett csomagjat feltenni. YMMV...

Ja igen, AIX -ra a GNU findutils IBM altal forditott keszitett RPM -je itt toltheto le.

Nézd én nem akarok senkit sem meggyőzni.. ha ugy
gondolod hát legyen "nagyon sokkal rosszabb".. puff neki..
aki nem hiszi járjon utána.

De hogy megnyugodj:
a "tesztet" két darab egyenként -253 nanobájtos fájlon
végeztem, hogy "ne legyen sokkal rosszabb" mint a többi megoldás.:)
Persze előtte hegesztőpisztollyal előmelegitettem a winchiket.. ezt Te
se hagyd ki ha tesztre vetemednél.:)

Fri

> ha ugy gondolod hát legyen "nagyon sokkal rosszabb".. puff neki

En nem "ugy gondolom", ez igy van. Es csak nagyon remenykedni tudok, hogy nem talalkozom olyan rendszerrel, amit te ezzel a hozzaallassal terveztel/alkottal. Az eroforras a mai napig nagyon fontos szempont kene legyen, de sajnos egyre tobben pont igy allnak hozza: "vegyel meg memoriat" ; "a diszkek filleres aruak, vegyel hozza meg 200G-t" . Csak sokszor nem ezek a nagysagrendek jatszanak, es ezert az arak se filleres tetelek.
De hidd csak el nyugodtan amit mondtal. Meggyozni nem akarlak, csak ravilagitani arra, hogy amit mondtal, abban technikai ertelemben hasonloan kellemetlen problemak vannak, mint a temaindito kierdesben.

Nézd öcsisajt, talán előbb probáld ki utána verd a melled!

Ami a hozzáállásom illeti, szerencsére nem Te vagy aki megitéli,
aki igen nem osztja a véleményed. Sajnos a hup forumai elég gázok
mostanság föleg az olyan emberek miatt mint Te is vagy, aki "egy sor"
alapján véleményez, itél meg mást, föleg ugy hogy nem ismeri a másikat.

Sajnos véletlenül hozzászoltam ehhez a forumhoz.. nem teszem többet,
mert nagyjából az ilyen okostojásoktól hányingerem van.

Utólag csak annyit, hogy bocs.. bepöccenek ha valaki "egy sor alapján itél
meg egy könyvet" effektust tapasztalok.

Stílusod az van, öcsibogyó, de nyugodtan visszafoghatod magad. Senki nem sértegetett, ha nem vetted volna észre.
Csak úgy megemlítem: ezt megelőző hozzászólásaid alapján nem tesztelted korrekt adatokkal. Nem nézted meg a forrást. Nem hivatkoztál olyasmire, ami legalább elfogadhatóan jelezte volna, hogy a GNU-féle tar implementációban a hasznos funkciók mellett ekkora ocsmányságok is vannak. Én meg ezek után a könnyebb utat jártam: a helyett, hogy megnéztem volna a forrást, inkább azt feltételeztem, hogy nem ekkora barmok a gtar bizonyos fejlesztői.

Mea culpa, mea maxima culpa.

Megjegyzem, a GNU-programoknak az "eredeti" UNIX-ősökhöz képest új, értelmes bővítései ellen kevésbé tiltakozom, mint az értelmetlenek ellen. De remélem ez a kis szál legalább arra jó lesz, hogy mindenki megjegyezze: van egy isteni módszer nagyon sok fájl nagyon gyors törlésére, de a világon sehol nem működik, kizárólag csak a GNU tar-t használó rendszerekben.

Na ide figyelj okostojás, ha ez nem sértegetés akkor mi?
"Es csak nagyon remenykedni tudok, hogy nem talalkozom olyan
rendszerrel, amit te ezzel a hozzaallassal terveztel/alkottal."
Vadas idegenül negativan megitélsz valakit, annélkül, hogy ismernéd..
igy ebben a formában az önteltség netovábbja, én erre kaptam fel a vizet.
Lehuztam már pár évet én is rendszergazdaként, erre jön egy
nekem valaki aki egy sor alapján véleményt alkot szakmailag.
Hidd el nem mindenki hülye akit nem Zahy-nak hivnak.
Stilus.. tényleg van, mert elszaporodtak a hup.on az olyanok mint Te.

A tények pedig:
1. nem mondtam, hogy nem teszteltem, azt ajánlottam probáld ki.
2. a feltételezés != tény, ha kiprobáltad volna, mondjuk egy pár GB-s
fájlon, talán továbbláttál volna egy üres feltételezésen.
3. elismerem, hogy nem tudtam, hogy különböző rendszeren mások a tar megvalósítások

=== Idezek toled: ===
gondolod hát legyen "nagyon sokkal rosszabb".. puff neki..

De hogy megnyugodj:
a "tesztet" két darab egyenként -253 nanobájtos fájlon
végeztem, hogy "ne legyen sokkal rosszabb" mint a többi megoldás.:)
=== idezet vege ===

Hat ez a hozzaallasod.

0) engem a "puff neki" zavart, es ennek hangot is adtam, miszerint az eroforras nem "puff neki" - teny, nem jeleztem eleg erthetoen, hogy ez a resze zavar a megjegyzesnek
1) ha te ezt tesztnek nevezed, az mas
2) igazad van, ezt meg en ismerem el. Pontositasert lasd alanti a) pontomat arrol, hogy ki is kell am probalni - de neked is
3) most mar elismered, ez jo

Es akkor lassuk, hogy nez ki ez az en szemszogembol. Van egy problema, amire valaki ad egy valaszt.

a) A valasz az adott problemara abszolut rossz, ugyanis "Arg list too long" *tudtommal* vagy a parancssori argumentumok szama, vagy az argumentumok ossz-hossza alapjan johet elo. A tealtalad felvazolt megoldasban tobb argumentum van, es hosszabb is az eredeti parancsnal, tehat ugyanugy "Arg list too long" lenne az eredmeny - azaz nem jo megoldas.

b) raadasul a valasz a (gnu)tar egy olyan mechanizmusat hasznalja ki, amely *szerintem* (mert pl. rka szerint igy logikus) a jozan esznek teljesen ellentmondo modon mukodik.

c) velemenyt alkotni pedig szabad. Neked is. Teszed is. Es ha *zavar*, hogy valaki rolad neked nem tetszo szakmai velemenyt alkotott, akkor ne bunkosaggal reagalj, hanem szakmai ervekkel - amely erveket egyebkent nem toled, de megtalaltam a tobbszor hivatkozott blog-ban.

d) es mivel ezt irod: "Lehuztam már pár évet én is rendszergazdaként", akkor elarulnad nekem, hogy mi modon kell "két darab egyenként -253 nanobájtos fájlon" - ezeket a fajlokat letrehozni Linuxon? En ugyanis erre nem ismerek modszert, viszont szivesen tanulok szakmai dolgokat. Arra tudok modszert, hogy hogyan lehet eleg nagy fajlokat letrehozni, de nekem a -253 inkabb kelloen kicsinek tunik, es ezt szivesen vennem. (Ha esetleg a megoldasod nem csak Linuxon mukodik, hanem egyeb rendszereken - *BSD, HP-UX, AIX, Solaris, Tru64, sorolhatjuk - az meg kulon jo.)

No szoval, egy kicsit higgadj le, es ha mar a szimvonalat emlegeted, akkor te is igyekezzel azt a bizonyos szinvonalat emelni, es nem sullyeszteni.

Szia Frimen! Én nem ismerlek téged, nem tudom, hogy tudod-e, én ki vagyok, azt viszont bizonyosan látom, hogy nem tudod, ki Zahy. Zahy Magyarország egyik legrégebbi, leghozzáértőbb Unix szakértője, már akkor is Unix rendszereket tanított, mikor én (és valószínűleg te) még nem is hallottam róluk. Nem akarok beleszólni, hogy a GNU tar jól teszi-e azt, hogy ír a /dev/null-ba vagy nem, de szeretném ha sokkal szerényebben adnád elő. Nekem úgy tűnt, hogy Zahy kifogásolta a GNU tar fejlesztőinek teljesen illogikus hozzáállását, de nem személyeskedett. Szeretném, ha te is visszafogottabban érvelnél. Egyszerűen az a helyzet, hogy ebben az országban szinte mindenki valahanyadik mélységben tanult Zahytól, és nem tetszik, hogy ilyen tiszteletlenül beszélsz vele. (Mellesleg személyesen is régen ismerem és remek ember.)

Szia Atya.

Mivel lentebb megkértek minket (jogosan), hogy ne szaporitsuk a
szot nem válaszoltam már senkinek.. de hogy próbáljuk elásni a csatabárdot..

- nem tudom ki Zahy és ki vagy Te.. de a Fiúról és a Szentfazékról már hallottam.:)
- olvastam Zahy válaszát (föletted:) már értem miért lett véres a sztori..
nevezetesen küldök majd neki postán egy kis humorérzéket.. légipostán, hogy gyorsabban
odaérjen:) mert a puff neki-t tréfásan irtam.. amit probáltam nyomatékosítani a fájl mérettel és a többivel.
Ezen Ő kapta fel a vizet, én meg arra amit ugy irt le, hogy "valaki rolad neked nem tetszo szakmai
velemenyt alkotott".. tyja.. mindenkinek vannak gyenge pontjai a végbelén kivül.:)
- ami a "szerénységet", "visszafogottságot" illeti, arra inkább nem is reagálok
- ami a "tiszteletet", ne haragudj de az egy olyan dolog amit el kell "nyerni"..
Ki tudja? Zahy "válaszai" alapján elképzelhető (vicc jön), hogy szabadidejében macskákat csikiz halálra és
(most már) (gnu)tar-ral küldi a /dev/null-ba öket.:-)

Szóval no.. én a témát végképp lezártam.. legközelebb, ha lesz HUP sörözés,
akkor gyertek el és vagy csináljunk tömegverekedést, vagy igyuk le magunkat, de akár abban is benne
vagyok, hogy face-to-face egy független és pártatlan pszichologus segitségével kielemezzük a "pengevágáltást"..:)

Fri

En hajlando vagyok elhinni, nem ez lenne valoszinuleg az elso ocsmanysag a GNU cuccokban. De azert jar az agyam, vajon hogyan csinaltak ezt a rondasagot. Mert ha siman a /dev/null sztringre ellenoriznek, akkor azt egy linkkel konnyu atvagni. A korrekt megoldas az lenne, ha lekerdezne a /dev/null parametereit (tipus/major/minor) es erre a triplet-re ellenorizne. De ez akkor is baromsag.

Amikor hasznalom nem celom, hogy atvagjam. Ha /dev/null -t olvasom, _minel_gyorsabban_ akarok (null ido alatt, vegtelen mennyisegu) sok null-t,
ha irom _minel_gyorsabban_ akarom beletolteni a tartalmat(szemetet) es nem erdekel mi lesz vele.
Matematikailag egyszerusit a tartalommal, nem olvassa, mert tudja ugysem erdekel mi van benne ;)
Nem baromsag, inkabb segitseg, hogy elerje a celom - mar, ha az valoban a gyorsasag.
Egyetlen eset jut eszembe, ahol ez nem celszeru, amikor tesztelnem az iras-olvasast. Olyankor meg ugyis egy dd-t csovezek a tarba(bol), mivel a meretet
azzal szabalyzom, ezaltal a tar mar stdin(out) -ot kap filenek.
Szoval nekem tetszik ;)

> Egyetlen eset jut eszembe, ahol ez nem celszeru, amikor tesztelnem az iras-olvasast. Olyankor meg ugyis egy dd-t csovezek a tarba(bol), mivel a meretet
azzal szabalyzom, ezaltal a tar mar stdin(out) -ot kap filenek.
Szoval nekem tetszik ;)

Pardon me?

Ha nem tudjuk, hogy a gnu tar így viselkedik, akkor miért is kell dd-zni? Mi a francot értesz ez alatt, hogy "mivel a meretet azzal szabalyozom". Minek a méretét? Csak mert:

a) van ugye a tar "-b" opciója - ami talán arra jó, amit te talán akarhatsz
b) és van az oprendszer szintű FIFO buffer size, ami azért némileg bonyolítja azt, hogy te itt valamiféle méretet szabályozz.

Szóval magyarázd meg, itt mit értesz ez (méretszabályozás) alatt!

Ja, örülök, hogy neked tetszik, de ez többször kiderült már, hogy sok dologban nem egyezik a véleményünk ;-)

dd-zni azert celszeru, mert bs, count allithato a belolvasott mennyiseg. Nem kifejezetten a (szalag) blokkmeretet ertettem alatta, hanem, hogy ne olvassa vegig az eszkozt, csak amennyi tetszik.
(Mivel a peldakban is tobbnyire - blokkos ;-) - eszkozok szerepeltek)
Ha meg nem meres celbol olvasom, akkor legalabb egy hash-t szamolok belole, tehat nem ontom a null-ba.
Nem kell egyezni, eleg tiszteletben tartani.

Tiszteletem,
rka

"ocsmanysag"

Ahah, pedig pont úgy csinálták, ahogy szerinted is korrekt 'lett volna':) Ebből is látszik, hogy nagypofájú programozó vagy (mint ahogy én is) :) 


  /* Detect if outputting to "/dev/null".  */
  {
    static char const dev_null[] = "/dev/null";
    struct stat dev_null_stat;

    dev_null_output =
      (strcmp (archive_name_array[0], dev_null) == 0
       || (! _isrmt (archive)
           && stat (dev_null, &dev_null_stat) == 0
           && S_ISCHR (archive_stat.st_mode)
           && archive_stat.st_rdev == dev_null_stat.st_rdev));
  }

Az "ocsmányság" fenti megjegyzésemben arra utalt, hogy eléggé nem szokványos módon oldották meg ezt a senkivel nem kompatibilis dolgot. (Hivatkoznak itt egy blog-ra, ahol részletesen szerepel ennek a kivesézése, ott is elhangzik: nem kellett volna ezt a kimenti fájl ellenőrzéséhez kötni, inkább egy újabb kapcsoló kellett volna a meglevő millió mellé.) Ugyanis a fent emlitettek mellé természetesen azt is be kell rakni tesztelni, amikor én 


tar c --remove-files a b c > /dev/null

formában hívom - ez még megoldható; de nyilván akkor már azt is kéne, ha 


tar c --remove-files a b c | cat > /dev/null

és í. t.

Tök egyetértek, hogy ez ocsmányság. Én sem ismertem. És tényleg nem így kellett volna csinálni.

Viszont ennyi vita és flame után csodálkozom, hogy senki nem vetette még fel (visszatérve az eredeti kérdésre), hogy az rm-nek igazán lehetne olyan kapcsolója, hogy rekurzívan mindenkit töröl alatta, de őt magát nem. Persze ez sem lenne kompatibilis semmivel, de GNU rendszereken igencsak hasznos, és roppant kényelmes lenne.

Asszem mindjárt megfogalmazom nekik a feature requestet...

Szerintem elég nagy baromság volna "átugrani" a file-okat ha a cél a /dev/null. Hiszen ilyen esetben minek is használunk tar-t? Megőrizni nem akarjuk a kimenetet, hiszen azt a kukába küldtük. Akkor mi a másik jellegzetessége a tar-nak? Hogy végigolvassa az input file-okat. Tehát egy /dev/null-ba tarolás elvileg jó módszer az input file-ok végigolvastatására és ellenőrzésére. Elvileg, de ezek szerint ez nem történik meg. Ezzel az erővel a GNU tar ki is léphetne azonnal, ha a cél a /dev/null.

Ave, Saabi.

Igy van, valóban ellenőrzi.
Hogy ez "csunya hack"-e vagy sem megitélés kérdése.. és igazán a
forrásból derülne ki ez egyértelműen.. vagy nem egyértelműen hiszen a
/dev/null elég kitüntetett szerepet játszik a legtöbb unix alapú rendszeren.

Mindensetre én a hozzászólásom a témához "profik" miatt befejeztem.

OFF
Nem kell annyira mellre szivni. Van meg sok tapasztalatlan forumozo, akik konnyen elkezdenek szemelyeskedni. Nekem kifejezetten tetszik a tar-os otlet, nem jutott volna eszembe. Abban persze igazad van, hogy egyre jobban higul a hasznos info erdektelen hozzaszolasok miatt...
ON

Hát.. ha titeket ő tanít akkor gond van!
Ennek a Zahy-nak először szerénységet kellene Nektek tanitani..
.. ugyanis amit én megértettem eddig az "informatikából" az az, hogy profik
nincsennek, max. olyanok akik egy adott területben profik, azaz jobban ismerik,
de még ők sem tévedhetetlenek az adott területen sem..
Azonkívűl mindenki szokott mondani baromságot, olyan hülyeséget, ami nem állja meg a helyét
amit lehet csak utólag lát meg.. a probléma nem ez.. hanem az, hogy ennek a Zahy-nak először
tiszteletet kellene mutania, hogy tiszteljék, azzal, hogy nem a minősít senkit egy "szakmai"
vitában.
Amugy ez a hozzászólásotok elég korlátoltságot mutat.. remélem ez csak a látszat.
Fri

Kipróbáltam, tényleg nem olvassa végig! 


fules@rasta:/usr/local/store/Films$ time tar cvf /tmp/ize.tar B.avi 
B.avi

real    0m21.116s
user    0m0.050s
sys     0m2.120s
fules@rasta:/usr/local/store/Films$ time tar cvf /dev/null B.avi 
B.avi

real    0m0.007s
user    0m0.000s
sys     0m0.000s

szerk: a hosszú példa-filenév széttolta vízszintesen a megjelenítést

( phaul | 2006. 11. 30., cs – 15:28 )

en ugy csinalnam -legalabbis ugy szoktam interaktiv shellben-, hogy ne kelljen megvarni:

$ mv konyvtar XxXxX
$ rm -rf XxXxX & # fork to bg
$ mkdir konyvtar

====================
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.

( Yorirou | 2006. 11. 30., cs – 16:54 )

cd konyvtar
for i in `pwd`; do rm -rf $i ; done

---------
WARNING: Linux requires you to type! After rebooted to Windows, you can safely unplug your keyboard.

"...a for miatt más..."
Szerintem nem más. Ugyanolyan szopás, mint az rm *, csak itt az ls fog megfeküdni.
Nemrég volt a kezem alatt egy suse 10.1, amin még a "for fajl in $(find . -type f); do valamit; done" is kiakadt, ha kb. 3000 fájlnál többel kellett volna dolgoznia. Igaz ezt még csak azon az egy gépen tapasztaltam; suse 9.3-on ugyanazal a könyvtárral nem volt semmi gubanc.

Mindenesetre nálam a find -exec rm "{}" a nyerő, esetleg, ha újsor is lehet a fájlnévben, a -print0 -al/xargs-al kombinálva.

---
Mondjon le!

( BaT | 2006. 11. 30., cs – 20:00 )

Nem tudom, de nem lenne egyszerűbb egy rm -r -d /a/konyvtar és utána egy mkdir /a/konyvtar ? Gondolom azért nem jó így, mert el kéne tárolni az argumentumokat. De ha már bash, akkor vannak változók...

Erre fentebb szuletett mar ket rm -rf && mkdir megoldas.

Persze minden megoldas problemafuggo, valahova jobb a find/echo | xargs, pl ha vannak subdirek es azokat szeretned meghagyni, vagy csak bizonyos fileokat torolni(persze ennek elso latasra kicsi az eselye igaz a kommentek alapjan mar futottak bele masok ilyen problemaba;).
Valahova meg a te javaslatod a jobb.

( gsimon | 2006. 12. 01., p – 12:17 )

Perl-lel próbálta már valaki? 

perl -e 'use File::Find;finddepth(sub{unlink($_)||rmdir($_);},".");'

( meditor | 2006. 12. 02., szo – 21:06 )

Én egy scriptben átadnám az ls kimenetét az rm-nek.
Lehet, hogy nem profi megoldás.

> Sol omnibus lucet.

Hát én valami ilyesmire gondoltam:

#!/bin/sh

WORK_DIR=/meditor/work
CLEAR_DIR=/meditor/sokfile

ls -1 -d $CLEAR_DIR/* > $WORK_DIR/files.lst
cat < $WORK_DIR/files.lst | while read MY_FILE
do
rm -f -R $MY_FILE
#echo $MY_FILE
done

#
# end of script
#

Elképzelhető, hogy az ls kimenetét közvetlenül át lehet adni
a 'while'-nak és akkor nem kell a munka_file-t létrehozni.
A megoldás teoretikus, gyakorlatilag nem tudom, hogy mennyire
használható. Az alapprobléma az volt ugye, hogy nem lehet
bizonyos körülmények között akárhány fájlt törölni. Szerintem
ezzel a kis skripttel az alapprobléma megoldott. A sebességéről
fogalmam sincs.

A megoldás szinte ugyanaz, mint amit Te közöltél (az enyém
szerintem didaktikusabb).
> Sol omnibus lucet.

Igen at lehet adni az ls kimenetet

ls -1 -d $CLEAR_DIR/* > $WORK_DIR/files.lst
cat < $WORK_DIR/files.lst | while read MY_FILE
[...]

egyszerubben :
ls -1 -d $CLEAR_DIR/* | while [...]

amugy ha mar munka fajl akkor inkabb (cat helyett)
while [...] done < $WORKDIR/files.lst

====================
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.

ls -1 -d $CLEAR_DIR/*  > $WORK_DIR/files.lst

Ezzel csak az a problemam, hogyha az rm -nel nem mukodott a *, akkor nagyon jo eselyed van ra, hogy az ls -nel sem fog menni (linuxon 100%). Ilyen esetekben az 

ls -1 -d [<path>/]<regexp>

nem hasznalhato, csak az 

ls -1

(mivel a -d eseten meg kell adni parameterkent a listazando bejegyzeseket is).

A sebesseg mindkettonk megoldasanal hasonloan rossz lesz a fileonkenti rm process hivasanak koszonhetoen. Ezen imp megoldasaval lehetne javitani, ami nemi string kezelest is belevisz jatekba.

A Te megoldasod (foleg a phaul altal adott kiegeszitessel) annyiban jobb mint az enyem, hogy olyan helyen is mukodik ahol a /bin/sh nem tamogatja a for ciklust (pl solaris 8 ;).
Egyebkent az en "megoldasom" a 60 masodperces quick hack szinten mozog(kb ennyi volt kigondolni es begepelni). Szemely szerint inkabb a find | xargs megoldast preferalom. Persze problemak es korulmenyek valtozoak ;)

Mondom, én akadimukusan közelítettem meg a kérdést, ha valóban
szembetalálkoznék a problémával, lehet, hogy mást ötlenék ki.

Az ls -d -re tett megjegyzések helytállóak. az ls -1 használatakor
célszerű beváltani a /meditor/sokfile könyvtárba, hogy valóban
semmiféle fálnévre vonatkozó paraméter ne legyen a parancsban!
(ez egy érdekes dolog: vajon a "*"-gal van generálisan gond, vagy
magával az rm programmal?)

A for ciklus és a solaris antagonizmusáról nem tudtam, köszi az
adalékot. Az az igazság, hogy mindenhol while-t használok,
scripteléskor és C-ben is. Egyébként gcc alatt egy for és egy
while ciklus UGYANAZT a gépi kódot eredményezi, ami nem meglepő,
de mindenképp intelligens dolog.

Nos, akkor írjuk át a scriptet, hogy egyben legyenek a
javaslatok. Az ls-t kiegészítettem egy -U kapcsolóval. Így
nem kell megvárni, a rendezést, ami két szempontból érdekes.
1. gyorsabb
2. lehet, hogy ebben az esetben a program NEM tárolja el
ideiglenesen a teljes listát (tehát memóriaprobléma nem lép
fel), hanem egyenesen átadja a fájlnevet a kimenetnek.
Tud erről valaki valamit?

Az tök_mindegy, hogy a fájlokat milyen sorrenben töröljük!

(A sebességprobléma az egyenkénti törlés miatt
továbbra is fönnáll, viszont komaptibilitási probléma, úgy
tűnik nincs.)

#!/bin/sh

CLEAR_DIR=/meditor/sokfile/

#
# A 'CLEAR_DIR' lehetne input_paraméter is
#

cd $CLEAR_DIR
ls -1 -U | while read MY_FILE
do
rm -f -R $MY_FILE
#echo $MY_FILE
done

#
# end of script
#

> Sol omnibus lucet.

Nem unjatok mar a temat??? Amugy ez a script is broken, fentebb voltak korrekt megoldasok is. Pl. a filenevekben levo szokozokre ez kifekszik annak rendje es modja szerint, ha javitani akarod lasd IFS beallitasa, "-ek hasznalata, extrem esetek miatt rm -f -- "$filenev" hasznalata, stb.

Nem unjuk a témát, ezért beszélgetünk róla. Ha Te unod, nem kell
hozzászólni. Szerintem. Na, mindegy. A megoldással kapcsoladban
pedig jeleztem, hogy a megközelítés elvi. Hogy az egyes
parancsokat egy adott esetben milyen konkrét paraméterekkel kell
ellátni - ebben is megegyeztünk - további vizsgálatot igényel.

> Sol omnibus lucet.

Az ls -d -re tett megjegyzések helytállóak. az ls -1 használatakor
célszerű beváltani a /meditor/sokfile könyvtárba, hogy valóban
semmiféle fálnévre vonatkozó paraméter ne legyen a parancsban!

Nem szukseges bevaltani. Ha az ls -nek megadod a $CLEAR_DIR -t mint listazando konyvtarat(

ls -1 -U $CLEAR_DIR

), de ilyenkor viszont az rm parameterekent az adott file teljes eleresi uttal kell megadni: 


rm -f -R $CLEAR_DIR/$MY_FILE

Persze ezt mondhattam volna eloszorre is csak kiment a fejembol :)

(ez egy érdekes dolog: vajon a "*"-gal van generálisan gond, vagy magával az rm programmal?)

Nemi kodbanyaszas utan ugy nez ki egyikkel sem, legalabbis linuxon. A kernel execve hivasa(fs/exec.c:do_execve()), az argv es az envp tombok elemeinek a szamat erre korlatozza: (PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *))/sizeof(void *)

Ha valamelyik tomb ennel tobbet tartalmaz, akkor az execve E2BIG hibakodot ad vissza.

A for ciklus és a solaris antagonizmusáról nem tudtam, köszi az adalékot.

Ense, amig az elso ugyfel nem panaszkodott ra...;) (Hivatalosan csak sol9-et tamogattunk, de valaki kiprobalta a termeket sol8 -on is. :)

Tapasztalat szerint meglehotosen erdekes kihivas/sport/perverzio linux/bash scripteket portolni mas os -ek shelljeire, vagy csak siman mas shell Bourne shell-re. :)

Az az igazság, hogy mindenhol while-t használok, scripteléskor és C-ben is. egyébként gcc alatt egy for és egy while ciklus UGYANAZT a gépi kódot eredményezi, ami nem meglepő,de mindenképp intelligens dolog.

Tekintve hogy a for az egy "elorecsomagolt" while ciklus, ami programozoi oldalrol egy kenyelmi szolgaltatas azzal hogy nem neked kell megirni feltetelkiertekelest (illetve a szamlalovaltozo lepteteset ha kell), ez nem meglepo ;). (Bocsi a hulye megfogalmazasert)

A script-ben a -U jo otlet, hogy mit gyorsit, azt szvsz az ls forrasabol tudod kideriteni.

( pts | 2006. 12. 14., cs – 09:53 )

Sziasztok!

A legkevesebb gondolkodásos módszer a Midnight Commander-ben F8-ot nyomni.

Parancssori megoldásként az alábbit javaslom:

mkdir ures
rsync -a --delete ures/ torlendo/
rmdir ures torlendo

Ennek előnyei:

-- csak keveset forkol (tehát pl. nem forkol fájlonként vagy 4000 fájlonként), tehát gyors
-- nem függ attól, hogy az echo belső vagy külső parancs-e
-- rsyncből csak egyféle létezik, biztosan megvan minden szükséges kapcsoló

Üdv:

pts

"A legkevesebb gondolkodásos módszer a Midnight Commander-ben F8-ot nyomni."

Nem megoldhatatlan, nem kivárhatatlan (8 évig biztosan nem tart), de abba a könyvtárba, ahol TÉNYLEG sok a fájl, nem kis türelmet igényel belépni az mc-vel.
Engem ez a tapasztalat vezetett hajdan a find és xargs közelebbi megismerésére.

A find addig jó, amig időadatot nem szősz bele a keresésbe - akkor ugyanis jóval több stat/fstat hívást csinál - az ilyet én Perl-ben raktam össze: egy stat hívással az összes adat ott van a fájlról, éehet nevet mintailleszteni és időadatokat összehasonlítani, aztán ha kell, akkor jöhet az unlink.

( bAndie9100 | 2014. 06. 22., v – 23:07 )

1. a fájlrendszer összes többi fájlnának - amiket nem akarsz törölni - kimásolása
2. fájlrendszer formázása
3. kimentett fájlok visszamásolása

:D

legtöbb esetben tényleg a vicc kategóriájába tartozik, de egyszer így intéztem el egy túlnépesedett /tmp könyvtárat (nem tmpfs-en volt). a fájlrendszeren csak alaptelepítés volt, ami kevesebb helyet foglalt, mint a /tmp inode-jai.

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy yazzy repack

( uid_6201 v | 2014. 06. 23., h – 21:59 )

Kíváncsi lennék 1.000.000 darab 100 kB-os fájl törlésére, melyik módszer a gyorsabb (formázás nem ér! :) )

Egy további versenyzőt mellékelek: 


#!/usr/bin/python

import os

for dirname, dirnames, filenames in os.walk('.'):
    for filename in filenames:
	os.remove(filename)

Modern fájlrendszeren már nem tudom, ez hogy működne.
Egy régin irtózatos nagy szívás lenne.
Ugyanis régebbi fájlrendszereken a directory többé-kevésbé ABC sorrendben tartalmazta a fájlokat. Minden egyes fájltörlésnél újra kellett rendeznie a könyvtárbejegyzéseket, emiatt iszonyat lassú volt egy ilyen törlés.
Ennél gyorsabb módszer volt ABC szerint csökkenő sorrendbe rendezni a listát és abban a sorrendben törölni a fájlokat.

De még1x: ez ősrégi dolog. Például OpenVMS ODS-2/5-n, talán FAT különböző verzióin működött így, a többiről nincs infóm.
(valami rémlik, hogy ext2/3 is képes volt ilyen galádságra, de ebben már nem vagyok biztos)