buta patch?

Fejlesztés

Megint vissza kell térnem ehhez a topichoz.

Az "első" hibám az volt, hogy valahogy fordítva jelöltem ki a fájlokat. Mikor erre rájöttem kaptam megfelelő diff fájlt.
A patch --dry-run módban működik (minden kijelölt műveletet success végrehajtott). A --dry-run nélkül viszont hiba van.

Van több olyan fájl aminek az elejében és a végében is van változtatás (insert) viszont a másodikat nem hajtja végre :(
Olyan mintha az első "körben" már módosított fájlon nem tudná végrehajtani a második módosítást.

Mit szúrok el már megint?
A google valahogy nem a barátom.

------------------------------------------------------------------------------------

Módosítanom kellene több C forrás fájlt. Viszont a diff által generált fájlban az eredeti is ott van, nélküle nem működik a patch.

Tudtok olyan "patch" programot, ami megkapja melyik fájlt kell módosítani és hogyan, nem kéri a "forrást"?

Tulajdonképpen "bután" módosítsa a kijelölt fájlokat (ill. másoljon/készítsen olyanokat ami hiányzik).

Kiegészítés:
Adva van egy több mappában elosztott forrás szoftver csomag - release.
Az eredetit lemásolva (az egészet) módosítottam néhány fájlt és hozzáadok néhány kicsi fájlt.
Az eredetit és a módosítottat összehasonlítom a diff segítségével.
Az eredményben a forrás és a cél is szerepel.
Jön egy újabb csomag forrás (release) amit módosítanom kellene, de a diff által generált fájl kéri az eredeti  forrást.
Másként, nem működik az, hogy megjelölöm a cél mappát (ahol a módosítandó fájlok vannak) és módosítja az ott leírtaknak megfelelően.
Természetesen, előfordulhat, hogy a célfájlok változnak, de ez igen ritka.

Lehetséges megoldás: egy (akár bash) script ami fejbe csapja a cél fájlokat, vagy sed segítségével beleszerkeszt. De a diff/patch tool egyszerűbb lenne.

MEGOLDÁS: Nem úszom meg, írnom kell egy saját scriptet. Elkezdtem írni egy bash scriptet, az első fájlt már tudom módosítani sed, grep, cp rm, szóval csupa unalomig ismert cucc.

MEGJEGYZÉS: A releaseben nyoma nem maradhat a patchnek. Kizárólag teszt célokra lehet/kell beépíteni/módosítani.

  • 1709 megtekintés

( Czo v | 2023. 07. 28., p – 16:25 )

Ezt nem igazan ertem. A diff fileodban "semleges", "-" torlendo es "+" beillesztendo soraid vannak az egyeb kotelezo (pl. filenev, sorszam) sorokon kivul. Nem kellene benne lennie az egesz allomanynak. 

( gemnon v | 2023. 07. 28., p – 16:39 )

Szerkesztve: 2023. 07. 28., p – 16:39

Én sem értem, esetleg bsdiff/bspatch ? Az ész nélkül patchel. :D 

( NevemTeve | 2023. 07. 28., p – 16:49 )

Én sem értem hundredpercent, nézzük sorban:

A diff-nek kell a before meg az after.
A patch-nek kell a before meg a patch-file, kimenete az after.
A patch-file tartalmaz részeket a before-ból, hogy a patch ellenőrizhesse, jót változtat-e.
 

( Foltos | 2023. 07. 28., p – 23:07 )

Szerintem neked sed/awk/perl és társai kell, ha azonos minta alapján több fájlt szeretnél módosítani.

Súgtak nekem hátulról, meg újraolvastam az egészet, és kezdek veled egyetérteni. Talán tényleg az a jó értelmezése a felvetett problémának, hogy adott szerkesztő műveleteket akar végrehajtani különböző fájlokon - és igen, ekkor klasszikus text editing toolok - azaz e fenti 3 - a megoldás. Pl:

 

- minden olyan sorban, amelyben szerepel "X" cseréljük le a 3. "Y"-t "Z"-re - ez pl: sed -e "/X/s/Y/Z/3"

- minden "lo" tartalmú sor után szúrjuk be azt, hogy "izé" - sed -e '/lo/a\

izé\

'

- ha az van benne hogy "alma", akkor töröljük - sed -e "/alma/d"

- minden "Z" cserélendő "U"-ra mindentől függetlenül. - sed -e "s/Z/U/g"

Szóval ha valahogy így foghatóak meg az igények, akkor erre találták ki a sed-et (és haszálható a fent amlített awk, perl - meg persze egy csomó egyéb tool, de ezek a klasszikusok)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( apal v | 2023. 07. 29., szo – 00:20 )

Szerkesztve: 2023. 07. 29., szo – 00:21

A `diff -Nur` a barátod. Paraméterei ezen felül: egyik könyvtár (és benne a sok forrásfile) és a másik könyvtár (és benne a sok forrásfile). A paraméterek jelentése rendre: új fileok kezelése, +/- 3 sor hozzácsapása, rekurzív diff. Minden klasszik "peccs" imígy készül.  A kimenete ennek a diff-nek egy olyan *.patch lesz, ami az egyik könyvtár ismeretében és/vagy jelenlétében létrehozza belőle a másik könytárat.

( _Franko_ v | 2023. 07. 30., v – 15:12 )

Szerintem neked egyrészt egy verziókezelő hiányzik, például egy Git rebase megoldaná a problémádat, másrészt meg mégis honnan kellene kitalálnia a "buta patch" megoldásnak, hogy egy teljesen másik forrásban mi hol van, amit módosítani kellene? Egy rebase is rengeteg conflict kézzel feloldásával jár, humán intelligencia kell hozzá.

https://iotguru.cloud

Szerencsémre(?) nem. Az általam módosítandó fájlok nagyon ritkán változnak - inkább csak nem kizárható. Erre az lenne a megoldásom először lefuttatnék valami egyszerűbb scriptet, ami megvizsgálja, hogy a módosítandó fájlok változtak-e.

Természetesen van verzió követő rendszerünk. Viszont ez egy teszt eset amit valamilyen ciklikussággal kellene futtatni és köze nincs a release verziójához, tőle teljesen független, nem érdemes még branch-et sem csinálni. Viszont kézzel módosítgatni eléggé nyűgös feladat.

Úgy tűnik nem úszom meg, írnom kell egy saját scriptet, a diff/patch párost nem erre találták ki.

* Én egy indián vagyok. Minden indián hazudik.

Azért tudom hol van az a hely ahova be kell szúrnom a módosítást, ha a sorszám előtt nem azt találom amit várok, akkor jelezni kell valami változott. (Az én esetemben ez nem várható a közeljövőben - a fejlesztés nem ezeken az ágakon megy)

* Én egy indián vagyok. Minden indián hazudik.

( bucko | 2023. 07. 31., h – 12:19 )

Szerkesztve: 2023. 07. 31., h – 12:19

Nemide.

( locsemege v | 2023. 07. 31., h – 13:23 )

Ahogy a többiek is írták:

before + patch = after
patch = after - before
before + (after - before) = after

Nekem olyan gondom volt, hogy egy különböző hardware verziókat leíró hatalmas táblázatom van C forráskódban, s kommentben a sor végén ott van, ez hanyadik táblázati elem. Kell, hogy lássam, hány elemű a táblázatom. Ha a táblázatba beszúrok egy új elemet, vagy törlök egy régit, akkor onnantól lefelé át kellene számoznom a kommenteket. Halál fárasztó, csak elrontani lehet. Írtam rá egy awk scriptet, amelyik megkeresi ezeket a kommenteket, s az elejétől, 0-tól kezdve sorszámozza, kijavítja a helyes értékre. A kommentnek ott kell lennie, viszont mindegy, hogy hibás szám szerepel benne, a scriptem kijavítja helyesre.

Tehát a problémádra szerintem nem a diff és patch való, hanem a sed vagy az awk. Szerintem az awk kényelmesebb, de ha perl-ül beszélsz, akkor az is jó. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem rosszul hasznalod a toolt. A diff tenyleg csak annyit tartalmaz, amit az elejen irtam. A sor megtalalasahoz "toltelek" sorokat, a torlendo sorokat es a beszurando sorokat. A verziokezelok pedig kepesek 1-1 commit es pl az aktualis allapot kozotti diff keszitesere is, amiket siman tudsz a patch hasznalataval alkalmazni. 

Egy dologra nagyon figyelj - bár ezt nyilván tudod -, nehogy megnyitsd írásra a szerkesztendő file-t shellből, mert azonnal létrehozza nulla hosszúságúra, s így törli a file-t.

Rossz:

./modosit valami.c >valami.c

Jó:

./modosit valami.c >valami.c.tmp
mv -f valami.c.tmp valami.c

Persze bele lehet rakni az mv -f parancsot is a scriptbe, vagy lehet azt is csinálni, hogy az egész file-t egyetlen stringben, RAM-ban összegyűjti, majd a végén egyszerre kiírja, persze, ha a file-ok reális méretűek, s néhány megabyte-nál nem nagyobbak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nagyon köszönöm a tippet, és nem nem tudtam erről, még nem futottam bele.
(Azért is vagyok kicsit elveszve mert szokatlan nekem az egész)

SZERK: A Bükki is ezzel kezdi a sed leírását :)

* Én egy indián vagyok. Minden indián hazudik.

A sed egyébként tud közvetlenül a munkafile-on szerkeszteni a -i kapcsoló használatával, de ezt csak a végleges változatban érdemes, ami tesztelve van, vagy fejlesztés alatt az eredeti másolatával szabad csak játszadozni, mert egy apró elírás, és világvége van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( gazsiazasz | 2023. 07. 31., h – 14:18 )

Kiónozd le a git repo-t amiben a release van és ahhoz adj commit-ot. Ne szívasd magad kézzel patch-elgetéssel.

Erre viszont jo lehet az autoconf is, ha a kollega projekjeinek kereteibe valami ilyesmi is beleillik. 

De barhogyis, akar tenyleg egy sima sed-del is megoldhato hogy az autoconf/config.status-hoz teljesen hasonloan mondjuk egy *.c.in file-bol letrehozza a megfelelo sed-es peccselés után a *.c-t. Akarmeg makefile szabalyrendszerrel is leirhato modon kezelheto. 

És ilyenkor jön az, hogy ezekre a problémákra van mindent is tudó professzionális eszközkészlet, amelynek a megtanulása sokkal több idő, mint kitalálni valami egyszerű jelölésrendszert a template-ben, kitalálni hozzá inputnak valami config file formátumot, valamint gyorsan leprogramozni pl. awk-ban hozzá az interpretert.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Biztos? Local repóként sem?

Amúgy szerintem is sed vagy ed, az tud vaktában beszúrni részeket fájlokba, pl. sed 15a a 15. sor után szúrja be a megadott stringet. De azt én sem értem, hogy a hagyományos patch miért nem jó neked.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Van egy releasem (kismillió fájl és mappa), lemásolom (az egészet) és módosítok 5-6 fájlt, ill. bemásolok 2 fájlt, majd forgatok.
Tudok készíteni diff fájlt (eredeti vs. módosított).
Viszont a következő alkalommal mikor tesztelek egy új release-t kapok. Tény hogy a módosítandó fájlok, és a helyük nem változik de ha az előzőekben kapott diff fájlal próbálok patchelni nem működik "garbage".

Nem érdekel mi volt az eredeti csak az,hogy az új release mappában (ami egy szép nagy sok mappás struktúra) mindent módosítson a szabályaim szerint. Lehet, megtehetném, hogy a diff fájl felhasználásával készítek sed parncsokat, de akkor már lehet értelmesebb egy önálló script, hiszen pontosan tudom mit, hol és hogy kell módosítani. Ha még valami változik (nagyon kicsi az esély) akkor szóljon ha valami nem stimmel.

* Én egy indián vagyok. Minden indián hazudik.

Alakul.

Amikor elkeszited a diff allomanyt, akkor azt hogyan csinalod? Mik a diff parameterei? Ha jol csinalod a diffet, akkor valamennyi valtoztatast elvisel a fileon patcheleskor. Amikor megkapod az uj fileokat, hogyan alkalmazod a diff allomanyt? Mik a patch parameterei? Ha jol parameterezed, az alapertelmezesnel is tobb valtoztatast elvisel. Amikor hiba van, akkor milyen hibauzenetet kapsz? Nem eleg ilyenkor mondjuk a 100 valtozasbol, azt az 1-2-t javitani, aminek az alkalmazasa elszall? 

Ha van ráhatásod a projectre, megfűzheted a fejlesztőket, hogy tegyenek a forrásba az általad kívánt helyekre speciális commenteket, s azok triggerelhetik a scriptedet. Vagy commitold be magad ezeket a commenteket. Ha persze nincs erre ráhatásod, az szívás.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, motoszkál egy lehetőség a fejemben.

Eddig úgy csináltam a diff fájlt, hogy a módosított és az eredeti fájlok gyökeréből indultam. Lehet az eredeti gyökéren belül kell létrehozni (átmásolni) a módosított fájlokat és azt összehasonlítani. Így ha új releaset kapok,  csak be kell másolnom a módosított fájlokat (a könyvtárstruktúra megőrzésével) és az alapján patchelni.

Kipróbálom, meglátjuk.

* Én egy indián vagyok. Minden indián hazudik.

Eddig úgy csináltam a diff fájlt, hogy a módosított és az eredeti fájlok gyökeréből indultam. Lehet az eredeti gyökéren belül kell létrehozni (átmásolni) a módosított fájlokat és azt összehasonlítani. Így ha új releaset kapok,  csak be kell másolnom a módosított fájlokat (a könyvtárstruktúra megőrzésével) és az alapján patchelni.

Ezt hívják úgy a Git terminológiában, hogy rebase...

https://iotguru.cloud

Itt látszik, hogy mindig lokális verzió követést használtam. Most hogy állásban vagyok, több csoport dolgozik ugyanazon a kódon és persze Continues Integration, kell megismerkednem ezekkel az eszközökkel. Ráadásul itt ez eléggé egyedi bár szerintem a git lehet ennek is az alapja.

Egyet már tudok, hogy ezekkel az eszközökkel csúnyán ki lehet tolni a kollégákkal.

* Én egy indián vagyok. Minden indián hazudik.

Mar kerdeztem... de megkerdezem ujra. Hogyan keszited a diffet? Hogyan patchelsz? Mi a folyamat? Mik a kiadott commandok/parameterek?

 

Annak a folyamatnak siman mennie kellene, hogy van egy konyvtarszerkezeted (ez az eredeti), ezt lemasolod, majd a masolatban modositassz. Ezutan keszitessz egy diffet osszehasonlitva az eredetit es a masolatot. Majd ha megjott az ujabb verzio, arrol is csinalsz egy masolatot, majd a masolatra ezt a diffet kellene tudnod alkalmazni, akkor is, ha nehany allomany megvaltozott. Nehany hunkot elcsuszva fog megtalalni, ha pedig olyan szintu a valtozas, akkor irni fogja, hogy melyiket nem talalta meg. Szerencses esetben, ezt az 1-2 filet kell kezzel processzalni. Majd ha megvagy, keszitessz egy uj diffet az uj "eredeti"-hez kepest (amit kaptal release) az uj modositott valtozattal, es meg is vagy, ezentul ezt hasznalod kiindulaskent.

Nagyjából ahogy írod.

diff -uNr src/ zzz/ > diff.out

Az src/ az eredeti a zzz/ a módosított (most épp csak a módosított fájlok, azonos pathon).
Készít egy diff fájl, benne a src/ és a zzz/ fájl, dátum egyéb kriksz-kraksz.

Előveszek egy új release -t. Ha csak simán bemásolom a diff fájlt és ráeresztem a patch -et --dry-run mindent ignorál, azzal hogy nem találja.
Bemásolom a zzz/ mappát is a helyére akkor sem találja.

A csavar történetben, hogy az egész cywin környezetben fut, így pl. a diff fájl crlf végű sorokat tartalmaz. Megpróbáltam csak lf de az eredmény nem változik :(

* Én egy indián vagyok. Minden indián hazudik.

Ha a patch futtatasakor, benne vagy a folderben amiben a patchelendo fileok vannak, akkor meg kene mondani a patchnak, hogy ignoralja a path komponens elso elemet. Tehat kellene neki egy "-p1", nem? A diffet ne ugy keszitsd el, hogy csak a modositott fielok vannak a zzz-ben! Masold le az egesz src-t zzz-be, modositsd a fileokat a zzz-ben, majd igy keszitsd el a diffet. Az igy keszitett diffed csak a valtozasokat fogja tartalmazni. Tehat az elkeszult diff fogja megmondani, hogy az eredeti (src) allapotbol, hogyan kell eljutni a cel (zzz) allapotba. Azaz csak a valtoztatasaid lesznek a diff allomanyban. Ha viszont a zzz-ben csak a modositott fileok vannak, akkor egy gigantikusan nagy meretu diffet fogsz kapni, hiszen benne lesz, hogy ki kell torolni vegtelen sok sort es filet, hogy eljussunk a kivant vegeredmenyhez, ami csak a modositott fileokat tartalmazza.

Nem vagyok benne a patchelendő fájlok folderében.
Igazad van, a zzz/ be mindent bemásoltam a módosított fájlokkal együtt (később csináltam egy csak a módosított fájlokat tartalmazó verziót kisérleti céllal).

Teljesen jó diff -et kaptam --- src/ és +++zzz/ formákban, pont az van benne ami nekem kéne. De mikor ráeresztem az új release -ra akkor nem találja a módosítandó fájlokat :(
Lövésem nincs miért.

* Én egy indián vagyok. Minden indián hazudik.

Jó lenne, de az src mögött még mindig van egy kupac könyvtár.

Most hogy így belegondoltam lehet egyesével is diff/patchelni csak a hosszú passzokat egy cwd(?) vle elintézni, azaz lépjen be a célkönytárba és onnan dolgozzon.

* Én egy indián vagyok. Minden indián hazudik.

Nem erdekli a diffet, hogy mi milyen melyen van. Nem kell egyesevel patchelni. Egyszeruen lepj be oda, ahol a patchelendo fileok vannak, majd patch -p1 < ../patchfile vagy cat ../patchfile | patch -p1. A -p1 celja az, hogy a patchfileban megadott pathbol levagja az ELSO kompoennst. Ha kettot kell levagni, akkor ertelemszeruen -p2, etc. 

Mennyivel egyszerubb lenne, ha hajlando lennel megmutatni, hogy mit csinalsz, mit adsz, ki, hol vagy, mit latsz, mi van a diff fileban... Szet fog torni az uveggombom, annyira erosen simogatom. 

Még mindig úgy tűnik nekem, hogy ez az egész egy szimpla Git rebase/merge. Van egy "feature" branch-ed, ami soha nem kerül át a release ágra viszont a release ágról rendszeresen át kell hozni a változásokat.

Így: https://www.simplilearn.com/ice9/free_resources_article_thumb/Git_Rebas…

https://iotguru.cloud

Namostan a WinDos-ra nem tudok mit mondani, de Unixban ez valahogy így megy (ez eppen egy Makefile-bol van):

test2:
        mkdir -p before after testdir
        :
        printf 'Roka\nRudi\navasz\nragadozo\n' >before/file1
        printf 'Maris\nSzomszed\nAjtajara\nKriszta irta\n"Huje Maris"\n' >before/file2
        :
        printf 'Roka\nRudolf\navasz\nragadozo\n' >after/file1
        printf 'Maris\nSzomszed\nAjtajara\nKriszta irta\n"Hulye Maris"\n' >after/file2
        :
        diff -Nur before/ after/ >patchfile || true
        :
        printf 'Kicsit mas\nRoka\nRudi\navasz\nragadozo\n' >testdir/file1
        printf 'Valtozott\nAz eleje\nMaris\nSzomszed\nAjtajara\nKriszta irta\n"Huje Maris"\n' >testdir/file2
        cd testdir; patch -p1 <../patchfile
        :
        diff -u after/file1 testdir/file1 || true
        diff -u after/file2 testdir/file2 || true

Itt azt kellene latni, hogy a 'testdir' tartalma nem egeszen azonos a 'before'-ral, de azért a patch megbirkózik vele, ilyeneket ír:


patching file file1
Hunk #1 succeeded at 2 with fuzz 1 (offset 1 line).
patching file file2
Hunk #1 succeeded at 4 (offset 2 lines).

( _Franko_ v | 2023. 07. 31., h – 17:50 )

Szerkesztve: 2023. 07. 31., h – 17:52

Bennem egyre inkább az fogalmazódik meg, hogy rossz irányba indultál egy probléma megoldásánál és most több lépést hátra kellene lépned, ehelyett az utolsó lépést próbálod csak megoldani valahogy. Amikor a földkerekségen nincs tool arra, ami problémád van, akkor az esetek igen-igen nagy részében rosszul közelíted meg a problémát.

Vissza tudnál lépni és a gyökérokot elmagyarázni, hogy miért kell ez? https://en.wikipedia.org/wiki/Five_whys

https://iotguru.cloud

Itt a nehézséget az okozza, hogy nem saját hanem egy céges feladatról van szó. Nehéz úgy megfogalmazni ha folyton azon kell gondolkodnod mit mondhatsz el és mit nem. Amit eddig leírtam az is lehet valakinek csípné a szemét.

* Én egy indián vagyok. Minden indián hazudik.

( AszaltSzilva | 2023. 08. 01., k – 10:28 )

Lehet, hogy problémám van az értő olvasással - és nem értem a problémát -, de itt szerintem a diff3-t kellene alkalmazni. (https://en.wikipedia.org/wiki/Diff3) Ez teszi lehetővé, hogy ha az eredeti fájlt két különböző módon is megváltoztatták, akkor a változtatásokat összefésülje.

Szerencsére lehet könyvtárakra is alkalmazni ezt a programot, nem csak külön fájlokra. Ekkor viszont rendelkezni kell az eredeti forrással, a saját módosításokkal kiegészítettel, illetve az újabb verzió forrásával is. Ha rá akarunk nézni, hogy pontosan mi is fog történni, akkor a Kdiff3 programot kell használni (nem csak KDE alatt érhető el, van Windows-os variáns is).

 

Egyébként valószínűleg érdemes verziókezelőt használni - ahogy a többiek ajánlották is -, mert saját branch-ben tartva a helyi kiegészítéseket, a master/main branch-ből a sajátot akár a rebase, akár a merge segítségével lehet frissíteni, s ennek semmi hatása nem lesz a master branch-re, sőt elosztott verziókezelő esetén másnál nem is lesznek meg a helyi módosítások.

AL

A diff3 jó lenne, de mégsem. Feltételezi, hogy van egy harmadik release.
Nem nekem készül, hanem más teszterek számára, akik letöltik az aktuális tesztelendő releaset és patchelik.

Ebbe a mi verziókövetőnkbe csak akkor nyúlnék bele, ha a kenyerem/életem múlik rajta.

A patchelt teszt releaset semmilyen formában nem juthat ki.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2023. 08. 01., k – 16:59 )

Jobb híján ide.

Kimásoltam egy fájlt az eredetiből és a módosítottat egy "proba" könyvtárba, csináltam egy diff fájlt, majd töröltem a módosítottat és ráeresztetten a patchet - működik :O

Úgy tűnik, valami a path körül nem stimmel neki.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2023. 08. 25., p – 12:52 )

Kimetszettem egy, duplán patch-elni való fájlt a diff fájlban.

Lefuttattam a ptch-at --dry-run -t és ilyen hibát kaptam:

Hmm...missing header for unified diff at line 14 of patch

MEGJEGYZÉS: a kimenetben elmegy a 32651 diff sorig - az egész diff ck. 20 sor!?

Ezek után a '@' sor elé bemásoltam még egyszer a cél fájl doglait (3 sor). Kitört a béke, mind dry-run mind élesben megcsinálta amit kell.

Most akkor ezt kézzel kell szerkesztgetni?

* Én egy indián vagyok. Minden indián hazudik.

Félreérted.

Nem működött, ugyanabban a fájlban két helyen is kellett módosítani, az elsőt megcsinálta a másikra kijelentette, hogy vlmi. "header missing" hiba van.

Kimásoltam az első javítandóhoz tartozó "headert" és beszúrtam a második elő és működött.

Nem hiszem hogy ezt kézileg kellene "belepiszkálni".

* Én egy indián vagyok. Minden indián hazudik.