Hogy jön ide a word?
Egyáltalán, milyen formátumba sikerült kinyerned a szöveget?

DRM is theft

jah ját Doc-ra konvertáltam

Wordbe van az a keresés és csere azért gondoltam első körben erre

Bár most hogy mondod leszedtem txt be így legalább nincs a felesleges formázás, 1 oszlopban van minden szó

Viszont így nem tudom mire kéne rákeresnem, mert a szavak elött nincs 1 szóköz se

Xbox One: bandymnc

Saját tapasztalat és vélemény:

Ha csak a sulit csináltad, akkor veszteséget fogsz termelni a cégnek, aki felvesz téged, mert nem lesz elég a tudásod. Simán lesz pár hónap, mire talán a saját béred ki fogod tudni termelni. Emellett lekötöd az ottani kollégák figyelmét is, ami miatt ők lassabban haladnak majd.
Ezáltal a kezdeti fizetésed simán lehet 150-200 közötti. Főleg vidéken. (Ha penge vagy angolból, akkor ez lehet 200-250 közötti PESTEN. Amennyiben nem vagy jó angolból, akkor pedig...hát igazából akkor nem sok értelme van programozást tanulni. Az angol tudás komoly projekteknél elengedhetetlen.)
2-3 év után lehet normális fizetést realizálni.
Tehát a félelmed valós, de ez ilyen. A 8 általánossal rendelkező futár nem termel veszteséget (vagy kirúgják gyorsan) a cégnek. Miután te is kikupálódtál, akkor jöhet a rendes fizetés.

Az utolsó bekezdésed viszont aggasztó, na nem nekem, hanem magadnak. Átlagosan a cégnél a projekteken dolgozol. Magyarisztánban leginkább régi projekteket kell karbantartani. Amiktől fejlődik a tudásod, de nem leszel naprakész, ha te magadnak nem teszel egy szívességet. Vannak cégek, akik támogatják, hogy a munkaidő X részében képezd magad, de ezeket a helyeket meg kell találni.
Szóval ha nem tartod magad up-to-date, akkor erős hátrányban leszel a piacon.
Területtől függ, hogy ez mennyi energiabefektetéssel jár. Mindenhol kell, de vannak területek, amik lassabban fejlődnek és változnak. Például mobilos vonalon ~2 évente változik meg minden és muszáj lépést tartanod, különben a friss kódod is legacy lesz, amit más bottal se igazán szeretne piszkálni.

Találtam egy nem régi hozzászólást, amiben a kotlinról kérdezősködsz. Egy friss/juinor droid fejlesztőnek nem szabadna (SZERINTEM) kérdésnek lennie, hogy megakarja-e tanulni a kotlint. Sőt...nem csak a kotlint, hanem már ott a flutter is...mert oké, hogy te leszel az istencsászár natív droid fejlesztő. Kezd a felé tolódni az elvárás, hogy crossplatform appok legyenek...

A piacnak igénye van jó fejlesztőkre, de igénye van 'gyári betanított munkásokra is'. Amennyiben nem képzed magad, akkor a betanított munkásokkal fogsz versenyezni. Vagy pedig beragadsz és 10-15 éves kódokat kell majd tákolnod, ami gyorsan megöli az ember lelkesedését.
Természetesen minél többet programoztál és minél több fajta dolgot láttál, annál kevesebb energiabefektetés kell abba, hogy az új dolgokat elsajátítsd. Tehát az elején sokat kell otthon is nézegetned (ha jó akarsz lenni), aztán egyre kevesebbet, de olyan nem lesz, hogy hátradőlhetsz és 'na én már jó programozó vagyok, mindent tudok a területemen'.

köszi

Igen, gondoltam hogy félre lesz értve a második rész, nem arról van szó, hogy havonta pár napot nem tudn3k vagy akarnék rá szánni, hanem azt nem tudom elképzelni, hogy minden nap hazaesve a melóból még pár órát szütyögök programozással, mert ha napi 12 órát ezzel töltök, akkor már 3-400k nem is hangzik olyan soknak pár év után

Szeretem ezt csinálni, meg jó is lenne ezzel fogalkozni, de nem akarom a nap 24 óráját ezzel tölteni, persze nyilván megértem a céget is, de gyanús, hogy ennyi tanulást/magán képzést nem fizetik meg sose

Xbox One: bandymnc

Az még fontos, hogy az első céges tapasztalat ne vegye el rögtön a kedved majd. Illetve az első pár év se.
~3 év után kezd igazán kinyílni ez az egész programozós világ átlagosan.
Ennyi időt el kell tölteni napi 8 órás munkaként a programozással, hogy...hmm, hogy fogalmazzak. A programozás tanulós időszaka a tutorial. Az első 2-3 év pedig a grindelős karakterfejlesztés. Utána pedig jön a megérdemelt end-game content, ahol az elején még zöldfülű vagy ugyan, de egy-egy boss legyőzése után radikálisan fog fejlődni a geared.
Kisebb cégnél ez hamarabb is megtörténhet, de az nem feltétlenül öröm, ha az ember nincs kész rá.

Tehát kitartást és sok sikert. A pénz is jönni fog majd. Ne félj majd munkahelyet váltani 1-1.5 év után. Nagyot fog ugrani a kezdő fizuhoz képest. Aztán 3 év után megint egy nagyot lépsz felfelé. Aztán majd szépen belassul ez is, aztán ha igazán jó vagy, akkor ... de ez messze van még

Sziasztok!

Korábban írtam/kérdeztem a mérleggel kapcsolatban.

Azóta sikerült pythonban összehozni a programot.

Most a kérdésem az lenne, hogy hogyan tudnám átadni egy helyi szerveren futó php feldolgozó oldalnak az adatot belőle?

Igazából a problémám az, hogy a xampp egy másik gépen fut, mint amelyikre a mérleg van kötve, a mérleges gépről elérem a helyi szervert, meg fordítva is, de amikor megnyitom az oldalt, a script nem fut le, nem éri el.

Az elképzelés az, hogy egy böngészőben futna a feldolgozó oldal a mérleg gépén, ami az egész dolgot vezérli, ez indítaná el a python scriptet is.

Keresek B-Sensual | BK Style | Disco*s Hit kiadatlan dalokat... pü!

snmp?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

A Windows ReplaceFile API függvényével kapcsolatban érdekelne, hogy az mennyiben tekinthető atomi műveletnek. Atomi művelet elvileg az, amit nem lehet megszakítani. Vagy teljesen végrehajtódik, vagy egyáltalán nem. A kérdésem az, hogy a Windows preemptív ütemezője átadhatja-e a vezérlést másik thread-nek/processznek a ReplaceFile végrehajtása közben. Mert az, hogy a ReplaceFile teljesen vagy egyáltalán nem hajtódik végre, rendben van, de előfordulhat-e, hogy a ReplaceFile véhrehajtása közben egy másik thread megpróbálja megnyitni a helyettesítendő file-t? Ekkor ugyanis lehet, hogy a másik thread nem fogja tudni megnyitni a file-t. Ha a ReplaceFile olyan értelemben lenne atomi, hogy az ütemező közben nem adhatná át a vezérlést másik thread-nek, akkor ez a probléma nem léphetne fel. Mi a véleményetek/tapasztalatotok ezzel kapcsolatban?

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Számíts a legrosszabbra, az sosem árthat

Én kérek elnézést!

OK, rendben, de azért ennél pontosabban szeretném látni a dolgot.

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

A Windows ReplaceFile API függvényével kapcsolatban érdekelne, hogy az mennyiben tekinthető atomi műveletnek.
Ha átadsz backup fájlnevet, akkor a hívó szempontjából közel atominak tekinthető. A közel szó arra vonatkozik, hogy az eredeti fájl tartalma megmarad, csak az attribútumai nem (részletek itt).

A kérdésem az, hogy a Windows preemptív ütemezője átadhatja-e a vezérlést másik thread-nek/processznek a ReplaceFile végrehajtása közben.
Természetesen. És mivel jellemzően egyetlen szálnál több létezik manapság egy processzorban, így még a preemptív végrehajtásfelfüggesztés sem kell ahhoz, hogy párhuzamosan más is fusson.

Mert az, hogy a ReplaceFile teljesen vagy egyáltalán nem hajtódik végre, rendben van, de előfordulhat-e, hogy a ReplaceFile véhrehajtása közben egy másik thread megpróbálja megnyitni a helyettesítendő file-t?
Előfordulhat.

Ekkor ugyanis lehet, hogy a másik thread nem fogja tudni megnyitni a file-t.
Ha olyan sharing flagekkel nyitja meg, amit a ReplaceFile nem enged, akkor nem fog sikerülni, ha olyannal, hogy engedi, akkor igen.

Ha a ReplaceFile olyan értelemben lenne atomi, hogy az ütemező közben nem adhatná át a vezérlést másik thread-nek, akkor ez a probléma nem léphetne fel.
Vagyis egy ReplaceFile hívás blokkolná a teljes operációs rendszert arra az időre, ami nyilvánvalóan nagyon nem jó.

TxF kell neked, és ott a MoveFileTransacted hívást, aminél minden fél számára atomi művelet a mozgatás. Vagy gondold át a választott megoldást, mert a legtöbb esetben más működést választva eliminálhatóak azok az esetek, amelyekre most választ keresel.

[ Szerkesztve ]

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

Köszönöm a választ. Én is tartok tőle, hogy olyan értelemben nem atomi a művelet, hogy blokkolná az OS-t, és valóban gondot okozhat, hogy több magon hardveresen (context switching nélkül) több szál is futhat.
A másik thread file megnyitásával kapcsolatban nem a sharing flagekre gondoltam, hanem hogy előfurdulhat-e a ReplaceFile végrehajtása közben, hogy a helyettesítendő file név pillanatnyilag nem létezik (mert temporálisra lett átnevezve), miközben egy másik thread próbálja megnyitni.
A posix rename különbözik ilyen szempontból?
TxF-et nem akarok használni, az MS sem javasolja: [link]

[ Szerkesztve ]

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

ha az a problémád, hogy lesz olyan pillanat, amikor a fájl nem létezik, ezért nem nyitható meg, akkor ne rename-mel meg mozgatással dolgozz, hanem csonkold.
linuxon ez úgy működne, hogy kimásolod a tartalmát, majd belemásolsz egy fájl vége karaktert az elejébe, ettől levágja az egészet. windowst nem ismerem. truncate-nek szokták hívni angolul.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

előfurdulhat-e a ReplaceFile végrehajtása közben, hogy a helyettesítendő file név pillanatnyilag nem létezik (mert temporálisra lett átnevezve), miközben egy másik thread próbálja megnyitni
Igen, előfordulhat. És az is, hogy a fő szálon azért száll el a ReplaceFile hívás, mert egy másik szál FILE_SHARE_DELETE flag nélkül nyitotta meg a fájlt és még nyitva tartja.

De mindkét eset könnyen érzékelhető és kezelhető a fő és/vagy a többi szál kódjának módosításával.

Ha IPC-re használsz ilyen módon fájlokat, akkor továbbra is azt tartom, hogy a megoldást kellene átdolgozni olyanra, ami nem igényel atomi műveleteket. Vagy ha nem szükséges az üzenetek perzisztens tárolása arra az esetre, ha a többi szál nem futna, akkor a fájlok használatától is teljesen el lehet tekinteni.

bambano: windowst nem ismerem. truncate-nek szokták hívni angolul.
Vagy TRUNCATE_EXISTING paraméterrel kell meghívni a CreateFile-t (ez csak akkor működik, ha már létezik a fájl), vagy CREATE_ALWAYS paraméterrel, és ez vagy létrehozza az új fájlt, vagy truncate-eli a már létező fájlt.

[ Szerkesztve ]

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

Ez nem jó megoldás, mert megnyitni ugyan meg tudja, de akkor már olvasni is szeretne belőle. A cél az, hogy ha meg tudta nyitni, akkor vagy az eredeti (még ReplaceFile előtti) állapotot lássa, vagy az újat, de sem megnyithatóság, sem olvasás szempontjából ne lásson köztes állapotot.

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

A file sharing flagek nem okoznak problémát, azokat tudom kezelni.
Nem IPC re használom a file-t, hanem közönséges konfig file-ként (amibe időnként visszaír a program).
A ReplaceFile-nál számomra "zavaró" köztes állapot csak az lehet, hogy a másik thread nem tudja olvasásra megnyitni a file-t, mert annak a neve (nem a file maga) abban a pillanatban már nem létezik (temporálisra lett átnevezve). Ha sikerül megnyitni, akkor biztosan konzisztens tartalmat tudok olvasni (vagy a régit, vagy a már módosítottat), sőt a ReplaceFile előtt megkezdett, de még be nem fejezett olvasási művelet is a régi konzisztens tartalmat olvassa (akkor is, ha a ReplaceFile közben már befejeződik). Tehát csak az OpenFile-ban lehet hiba. Arra gondoltam, hogy ez esetben rövid Sleep után újra megpróbálom (időt hagyva a ReplaceFile befejeződésére), és ha akkor sem sikerül, akkor a file valóban nem létezik, és feladom a próbálkozást. Mutexet és egyéb szinkronizációt azért nem akarok használni, mert éppen a szóban forgó konfig fájlból olvasnám ki a további szinkronizációhoz szükséges mutex nevét.

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Erre a célra szerencsésebb lenne a FindFirstChangeNotification használata FILE_NOTIFY_CHANGE_LAST_WRITE filterrel, és a többi folyamat érzékelné a fájl változását a változást követően, nem kellene aktívan monitorozni a fájl tartalmát, töredékére esne az elérési ütközések száma. Ezután a többi folyamat FILE_SHARE_READ sharing flaggel nyitná meg a fájlt (azaz amíg nyitva tartja, addig a fő folyamat nem tudná módosítani azt. nem lesz dirty read), ha nem sikerül, akkor pár tizedmásodperccel később újra próbálkozik. Ha a fő folyamatnál nem sikerül a ReplaceFile hívás, akkor az is pár tizedmásodperccel később újra próbálkozik.

Szerintem érdemes lenne a mostani konfigurációs fájlnak nevezett dolgot kettéválasztása szigorúan konfigurációs fájlra, ami nem módosulna és állapotfájlra, amit a fő folyamat módosítana. Vagy bármi más megoldás (pipe, socket, zeromq, MSMQ, stb.), ahol a fő folyamat értesítené a többi folyamatot, hogy itt van új állapotadat, tessék azt használni.

[ Szerkesztve ]

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

de akkor rossz helyen keresgélsz, mert a rename lehet atomi művelet, de a rename + create biztosan nem lesz egyetlen oprendszeren sem az.

ha neked az a feladatod, hogy létrehoztad egy temporális fájlban az új tartalmat, amit a helyettesítendő fájl helyére kell tenni, azt linuxon lehet atomi műveletként csinálni, a temporális fájlt átnevezed az eredetire. tehát nem azzal kell foglalkozni, hogy eltakarítsd a régit, hanem azzal, hogy az újat oda tedd a helyére. a régit majd eltakarítja a kernel.

rossz megoldás pszeudokódban:
move file file.backup
move file.new file vagy rename file.new file

jó megoldás pszeudokódban:
move file.new file

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

ha neked az a feladatod, hogy létrehoztad egy temporális fájlban az új tartalmat, amit a helyettesítendő fájl helyére kell tenni, azt linuxon lehet atomi műveletként csinálni, a temporális fájlt átnevezed az eredetire.

Pontosan ezt akarom. A kérdés az, hogy Windowsban lehet-e ezt atomi módon megtenni. Mert abban a műveletben, hogy "a temporális fájlt átnevezed az eredetire" lehet kívülről megfigyelhető köztes állapot (az eredeti file név nem létezik). Linuxban biztos, hoy nem lehet ilyen?

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

"Linuxban biztos": "mint a halál" (C) Macskafogó

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Windowsban lehet-e ezt atomi módon megtenni
TxF segítségével: igen.
TxF nélkül: nem.

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

Ugyanakkor az MS nem javasolja a TxF használatát, helyette pl. a ReplaceFile-t. Most akkor mégsem váltható ki a TxF ReplaceFile-lal? [Alternatives to using Transactional NTFS]
Linuxban a rename valóban atomi, míg a Windowsban a ReplaceFile nem? Ugyanazt a problémát kell megoldani. A Linuxban ez hogy történik? A file rendszerben van erre egy belső szinkronizálás? Windowsban miért nincs, vagy miért nem lehet? Honnan tudjuk, hogy a Windowsban nem atomi a ReplaceFile abban az értelemben amit írtam (nincs kívülről megfigyelhető köztes állapot)? Hogy lehetne tesztelni?
Kísérleteztem a ReplaceFile-lal, és szerintem a következőképpen működik:
Legyen A a helyettesítendő file, B pedig amivel helyettesítjük. Mindkettő ugyanazon a volume-on van.
1. Átnevezi A-t A.tmp-re (vagy valami hasonló temporálisra). Az A file-t nem mozgatja, csak a neve változik (Linuxban az i-node marad ugyanaz), ezért az A-ra már nyitott handlékkal zavartalanul folytatható az olvasási művelet. Ez az a pont, ahol az A nevű file-t nem lehet megnyitni, mert ilyen név már nem létezik. Ez lenne a kívülről megfigyelhető köztes állapot, amikor másik thread nem tudja megnyitni A-t. Az A.tmp-t nem lehet megnyitni.
2. B-t átnevezi A-ra. Szintén nem mozognak file tartalmak, csak a név változik (i-node marad).
3. Az A-ra megnyitott handlék bezárásakor az A.tmp törlődni fog.

Tehát a két átnevezés között van a köztes állapot, amikor A-t nem lehet megnyitni. Linuxon feltehetőleg logikailag ugyanígy működik a rename.

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

linuxon ott az inode. mivel van inode-od, egy fájlt akkor is el tudsz olvasni, ha azután, hogy megnyitottad, letörölték. a linux azt csinálja, hogy számolja a referenciákat az inode-ra, és amikor az lemegy nullára, törli a fájl tartalmát. a könyvtárbejegyzés és a megnyitott file handlere is referencia.

az átnevezés meg annyi, hogy az egyik könyvtárbejegyzésből kinézi, hogy melyik inode-ra mutat, és beleírja a másikba. egyszerűen felülírja a másikban az inode azonosítót. ezért atomi, mert vagy az előző tartalmat tudja egy másik processz beolvasni, vagy az újat, köztes állapot nincs.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Ez szerintem pontosan így működik Windowson is. Nem i-node van, hanem valami más struktúra, de Windows-on is csak annyi az átnevezés (ugyanazon a volume-on), hogy az új név bejegyzés a régi file-t leíró struktúrára hivatkozik. Ezt kipróbáltam, a régi file-ra megnyitott handléval zavartalanul lehetett folytatni az olvasást, természetesen a régi file-ból (ami A.tmp-re lett átnevezve). Az is igaz, hogy egy másik thread vagy az előző tartalmat, vagy az újat tudja olvasni, inkonzisztens file tartalom nincs. Az olvasásra történő file megnyitással lehet baj, amikor az első átnevezés már megtörtént, a második még nem. De ez logikailag ugyanúgy fellép a Linux esetében, hiába maradnak meg az i-node-ok. A Linux is két átnevezést kell hogy végrehajtson, ezek között pedig ugyanúgy köztes állapot van, amikor az A-t már nem lehet megnyitni, mivel már a neve nem létezik.

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Vagy lehet, hogy a Linux-on csak egy átnevezés van a Windows-on meg kettő? Itt lehet a kutya elásva? Ahogy írtad a Linux-on i-node hivatkozásnak számít a nyitott handle, ezért akkor is folytatódhat az ezzel megkezdett olvasási művelet, ha egyáltalán nincs file név bejegyzés erre az i-node-ra? Windows-ban biztos, hogy keletkezik egy A.tmp név bejegyzés valószínűleg azért, hogy a már nyitott handlékkal folytatni lehessen a megkezdett olvasásokat.

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Van értelme ezen ennyit vergődni? Tényleg van olyan file-od, ami setting és folyamatosan változni is fognak a beállítások? És ha tényleg van ilyen, akkor nem egyszerűbb adatbázisban tartani?

Illetve a .Net világában a settings file-ok változásának lekövetését file watcherekkel szokták megoldani, azaz amikor a file watcher bejelez, hogy megváltozott a file, akkor ismét kiolvasod, amit ki akarsz olvasni, és kész.

Én kérek elnézést!

Nem vergődök, csak egyszerűen érdekel ez a kérdés. Ha vergődésnek ítéled, egyszerűbb, ha nem válaszolsz. Nem egyszerűbb adatbázist használni, mert ez egy önmagában kompakt program, egyszerű konfiggal, és nem szeretnék még külön adatbázist is telepíteni/konfigurálni hozzá.
.Net-et nem használok, és nem is akarok.
Az OS/file-rendszer belső működése érdekel, mi a különbség Windows és Linux között (ebből a szempontból), Az MS miért írja, hogy a ReplaceFile atomi ha valójában nem egészen az, illetve miért javasolja a TxF helyett ezt használni (ha az meg valóban atomi). Igazából még most sem vagyok teljesen biztos benne, hogy a ReplaceFile nem atomi abban az értelemben ahogy írtam, szemben a Linux rename-mel. Az OK, hogy a Linuxban mindössze az i-node hivatkozást kell átírni (és ezért lehet valóban atomi a rename), azt nem tudom, hogy az NTFS-ben erre miért nincs lehetőség (nem ismerem az NTFS-t), mikor abban is van hard link. Márpedig ha van hard link, akkor a ReplaceFile lehet valóban atomi.

Ui.: kérem, hogy ne alternatív megoldásokra tegyetek javaslatot, azt magam is meg tudom oldani (pl. mutex szinkronizálással), hanem ezt a kérdést próbáljátok megválaszolni. Már persze csak az, aki nem érzi vergődésnek. Ha annak érzed, akkor ne fáraszd magad (meg mást sem) a válasszal.
Köszönöm!

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Válaszokat kaptál, a problémádat meg tudod oldani. A windows, linux gondolom nem kell részletezni, de nem ugyanazok, ergo eltérhetnek egymástól működésben. Azaz ez már csak vergődés, flamelés, trollkodás amit még itt csinálsz információ gyűjtés címszó alatt.

Én kérek elnézést!

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Tudna valaki ajanlani egy konyvet, vagy leirast - akar angolul is - arrol, hogy python eseteben hogyan kell gondolkozni, felepiteni a programokat, mitol fugg, hogy mi keruljon kulon fajlba, stb?

Sziasztok!

Van egy problémám, ami megfogott. (powershell, de a probléma nyelvfüggetlen)

Lényeg, hogy van 2 listám txt-ben. És van 1 mappám tele fájlokkal (~200). Ezeket kellene egyesével másolni különböző helyekre (kb 50 eltérő útvonal).

TXT1: nevek (személy, tárgy, kitalált, stb. Pontos egyezés a fájlnév közepével)
TXT2: Útvonalak. (mindegyik névhez 1 útvonal, ahova a fájlokat be kellene másolni)

A probléma az, hogy hogyan párosítom a neveket az útvonalukkal? Nincs sorban. Az útvonalakban lévő név rész sajnos nem minden esetben ad pontos egyezést.

Addig jutottam, hogy:
For fájlok a mappában
For név a nevekben
Ha fájl tartalmazza név akkor...
itt jönne valahogy a másolás művelet az útvonalra

Vagy esetleg a txtben a nevet és az útvonalat egymás mellé írni?
Bár akkor sem tudom, hogy lehet párosítani.

If you chase two rabbits you will lose them both.

Mit jelent, hogy a név nem egyezik? Víz Elek, az mindig Víz Elek lesz, még ha a szóközt, kötőjelet, ékezeteket, kis-nagybetűket érdemes is normalizálni, azaz "Víz Elek"-ből csinálj egy "vizelek" nevet, és a file-ok neveivel is ugyanígy kellene eljárni. Ami még így se talál össze, az valószínűleg tényleg problémás.

Egy ilyen txt párt igazán idetehetnél.

Én kérek elnézést!

Pár példa:

Nevek.txt

Alma
Ablak
Körte-Kálmán
József
Béla
Ablak Zsiráf

Útvonal.txt

C:\Valami\alma
C:\Valami\Ab-Lak
C:\Valami\Bela
C:\Valami\KorteKalman
C:\Valami\Jo_zef

A fájlnevekben pontos egyezés található a nevekre.
Gyümölcs_Alma.docx
Tárgy_Ablak.docx
Név_Körte-Kálmán.docx

[ Szerkesztve ]

If you chase two rabbits you will lose them both.

Akkor némileg ki kell egészíteni martonx javaslatát: normalizálod a mappák nevét, normalizálod a fájlok nevét, megkeresed az egyezéseket és feldolgozod. A maradékot pedig hibalistára teszed, és ezen listát végignézve kézzel létrehozod az összerendeléseket.

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

Olyant lehet, hogy TXT-ben egymás mellé rakom a nevet és az elérési utat valamivel elválasztva, majd valahogy megnézni, hogy az első rész egyezése esetén a második részben lévő útra másoljon?

If you chase two rabbits you will lose them both.

Lehet, de minek. Ha megcsinálod a javasolt normalizálásokat, akkor ennek simán mennie kell. Amit mégse sikerül párosítani, azt meg hibalistára teszed, ahogy a kolléga javasolta.

Én kérek elnézést!

Sziasztok!

XML-ben van egy String típusú attribútumom ami kitölthető mező a grafikus felületen. Hogyan lehet azt megoldani, hogy amint elkezdenek a mezőbe írni, akkor az link-ké váljon? Van erre lehetőség?

Sajna normalizálás nem megoldható. A Fáljneveknek vissza kell adniuk a rendes neveket, míg ezt útvonalba anno nem így találták ki.

If you chase two rabbits you will lose them both.

A kollegak arrol beszelnek, hogy a parositashoz normalizalsz.
Ertsd: Valamilyen strukturaban eltarolod mindket fajta adat (nev, utvonal) mindket fajta erteket, tehat a normalizaltat es az eredeti erteket is. Ezutan a ket normalizalt erteknek egyeznie kell, akkor talaltal egy part, amit aztan mar tudsz kezelni az eredeti ertekeknek megfeleloen.
Ami marad, az meg biodroid.

"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin

nagyjából 200 fájllal mostanra végeztél volna, ha kézzel megcsinálod.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

A baj, hogy nem 1x kell megcsinálnom.
minden héten le kel szedni... dolgozni bennük és átmásolni ha kész.

If you chase two rabbits you will lose them both.

Sziasztok.
Free Pascal ban fogok érettségizni, és az utóbbi években rengetegszer adnak/adtak olyan forrást (adatállományt) amiben az adatok soronként és oszloponként vannak jelen. Pl.: szóközzel elválasztva.
Kérdés: Hogy lehetne ezt a legegyszerübben beolvasni, eltárolni.
Eddig úgy csináltam, hogy az adatokat soronként betöltöttem egy array(tömb) be majd pos() -al elmentettem az elválasztó karakterek helyét, és így át másoltam copy() val a rekordokat a megfelelő helyükre. (Nem tudom mettől meddig tart egy adat a soron bellül, nem mind azonos hosszúságú).

Ez így megy csak nagyon hosszú. Van erre valami egyszerű(bb) megoldás ?

Példa a forrásra:
Név Magasság szül.id. lány
XY 165 1997.12.05 1
ZZ 182 1980.02.12 0
...

[ Szerkesztve ]

Szia,

Amikor megvannak a stringek (adat sorok egy array-ben), akkor azt splitelned kellene delimiterrel. [link]

Így arrayben array-ed lesz, nagyon egyszerűen.

Én kérek elnézést!

a readln utasítással mi a baj?

szerk: "Free Pascal ban fogok érettségizni": mi még öltönyben tettük anno...

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis