html worm eltávolítása több .html fileból

Web, mail, IRC, IM, hálózatok

hi,

bocs, a kategória több, mint valószínű nem korrekt. Hogy lehetne a legegyszerűbben megvalósítani, hogy több 1000 html fileból kitöröljem ugyanazt azt ismétlődő html worm-ot?

Egy adott user homejában felülírtak minden html-t, a következő stringgel:

http://pastebin.com/bK2Kww1n

Mentés van, de csak holnap tudom visszapakolni, viszont, ha létezik vmi egyszerű módszer, helyretenném itthonról.

köszi!

  • 4196 megtekintés

( szz v | 2013. 08. 20., k – 11:59 )

Néhány ötlet (nem teljes megoldás, nem végig átgondolva):
- Van lehetőség Perlben többsoros keresésre: http://pastebin.com/gc7QYVje
Így kideríthető, hogy mely fájlok érintettek. (Vagy más út: itt a feltételt kicserélheted az ellentétére (azaz, hogy csak olyankor nyomtasson, amikor épp nem látja a többsoros mintát).)
- grep -v minta fájl > újkönyvtár/fájl segítségével az adott minta kivételével a többi sor átkerül az új fájlba. (Feltételezem, hogy nem kell a teljes wormot megadni mintaként, hanem elég csak néhány szám a kódból; de ezt előzőleg érdemes ellenőrizni).
Ha minden rendben levőnek tűnik, akkor az újkönyvtár/fájl-okkal felülvághatod az eredeti fájlokat. (Gondolom, nem kell hangsúlyoznom, hogy grep ... fájl > fájl nem megpróbálandó.)

( maszili | 2013. 08. 20., k – 12:16 )

Például sed segítségével. A -i kapcsoló helyben hajtja végre a műveletet a fájlon.

(1) Ha egy sorban van a kártékony kód akkor egy egyszerű cserével: s/KÁRTÉKONY_KÓD//g
(2) Ha több sorban van akkor a sorok törlésével: /KÁRTÉKONY_KÓD/,/KÁRTÉKONY_KÓD/d

Ahol a KÁRTÉKONY_KÓD egy értelem szerűen megválasztott reguláris kifejezés.
Rekurzívan a szükséges fájlokra:

find /ahol/a/fajlok/vannak -iname "*.html" -print0 | xargs -0 sed -i "(1) vagy (2)"

--
maszili

Jó, a -0 kimaradt.
Ettől függetlenül én jobban szeretem sok fájlnál a -exec-t használni.

upd: főleg azért, mert az xargs hozzáfűzi a parancssor végéhez a paraméter(eke)t, míg a find -exec segítségével oda teszem, ahol nekem kell. Most nem tudnék konkrét példát hozni, de jártam már úgy, hogy bizonyos kapcsolókat, paramétereket csak a beillesztendő fájlnév mögé lehetett írni.

Minél több a file, annál pazarlóbb az -exec. Még mielőtt valaki azt hiszi hogy sok fájl esetén jobb ezt választani.

Esetleg egy --follow-symlinks amit be lehetne még tenni a sed-nek, bár nem hiszem hogy olyan marha sok symlink lenne. Illetve a hardlinkek, az ellen nem véd.

> Ezt a routerem produkálta

Routereken tipikusan millio eves busybox van, ami szar. (Lehet finomitani, de attol ez meg teny marad.) En futottam bele abba, hogy dobaltam el *.zip-eket, mert az unzip CRC-hibakat mondott ra, Aztan kiderult, h busybox beepitett unzip-je es ha rakok ra "valodi" unzip-et, akkor mar nem lesz CRC-hibas. (De az elmult evekben talaltam ezen kivul meg jopar elbaltazott busybox hibat.)

Ha pl. 255 a paraméterek megengedet maximásis száma akkor 100000 file feldolgozása esetén a következőkkel lehet számolni:

(1) "-print0 | xargs -0" esetén 100000/255 ~ 392 számú program indítás történik
(2) "-exec ... {} \;" esetén minden fájlra meghívja a feldolgozó programot tehát 100000 program indítás történik

Költői kérdés: Melyik módszer költségkímélőbb? ~392 program indítás vagy 100000 program indítás?

--
maszili

Költségkímélést nem említettem.
Parancssor max. hosszt és az átadott fájlnév pozicionálását emlegettem.
Apropo, közben man ugyan nincs kéznél, csak egy xargs --help kimenetét tudtam megnézni, de nálam ezt írja:
-0, --null Items are separated by a null, not whitespace.
Disables quote and backslash processing

Összekevertem a "-1" kapcsolóval, ami talán linuxon, talán hpux-on volt és egyesével adogatta a beérkező paramétereket a futtatandó parancsnak.

Közben kipróbáltam, wheezy-n nem okoz gondot a parancssor hossza, feldarabolja. Velem még csinált hülye vicceket, igaz, nem mostanában. (már nem emlékszem, hogy csak hibaüzenet volt az eredmény vagy simán elhagyta a kilógó elemeket)

Igy mar ertem miert ezt javaslom, de igy se jo, mert az xargs -I opciojaval meg lehet mondani, hogy mit hova szurjon be a parancssorba, azaz | xargs -0 -I '{}' ize '{}' mize '{}' ecet '{}' formaban pont ugy mukodik, mint a find (ahol viszont szabvanyosan biztos nem lehet a {} -t megvaltoztatni masra - raadasul nem zereti, ha valami hozza van raasztva, mert akkor nem cserel "mv {} {}.old" pl).

A tied pont a rossz megoldas, leven minden fajlra futtatja a programot, mig az xargs annyi fajlonkent, amennyi meg epp belefer az altalad felvetett parancssori limitbe.

find ... -exec sed
- 1 fajl eseten 2 processz (find, sed)
- 2 fajl eseten 3 processz (find, sed, sed)
- 3 fajl eseten 4 processz (find, sed, sed, sed)
- n fajl eseten n+1 processz (find, sed, sed, sed, ..., sed)

find ... -print0 | xargs sed
- 1 fajl eseten 3 processz (find, xargs, sed) es 1 pipe
- 2 fajl eseten 3 processz (find, xargs, sed tobb parameterrel) es 1 pipe
- 3 fajl eseten 3 processz -"- es 1 pipe
- n file eseten meg mindig nagy esellyel sokkal kevesebb processz es 1 db pipe

Azaz realisan 3 fajl folott mar olcsobb (kerdes, milyen draga a fork, exec es pipe). Persze elofordulhat, hogy olyan brutal hosszu fajlnevek lesznek, hogy szerencsetlen xargs kenytelen mindegyikhez uj sed-et forkolni. De altalaban az a ritkasag.

Ühümmm... és egyet is értek vele, csak - lehet, hogy épp ezért - néha ilyesmik maradnak meg bennem. Bár pont az xargs és a max. parancssor hossz az régebbi. Vagy hpux, vagy régi linux, vagy talán még solaris-os maradvány.
Csak arra emlékszem, hogy nagy szopás volt belőle, ezért nagy ívben kerülöm azóta is, ahol csak lehet. :)