unix string vs dos string

 ( tsb | 2008. március 5., szerda - 9:22 )

Sziasztok

Következő probléma okozott eredménytelen fejtörést meg guglizást:
Alaphelyzet:
-Van egy programom, amit linuxban írtam. Van benne szövegfeldolgozás, fájlból olvas soronként getline-nal, a sorokat eltárolja vektorban, majd feldolgozza. Szövegfájlt írtam hozzá text editorral ugyanitt. Gcc-vel lefordul, teszi a dolgát, (string.size()-1 ) ig olvasva mindent szépen feldolgoz.

Bonyodalom:
A forrást átmásolva win-es gépre, exét csinálok belőle Dev-cpp -vel, ami elvileg szintén a gcc valamelyik portját használja. Ugyanazt a szövegfájlt beadva neki, az utolsó karakter elveszik. Csak úgy működik rendesen, ha egy char-ral tovább olvastatok vele. Ha wines text editorral gyártok bemeneti fájlt, detto. MS Visual Studioval forgatva ugyanez.
Sejtésem szerint abból adódik a probléma, hogy a sorvége karakter nem ugyanaz a két rendszeren, de ez csak találgatás.
Elég zavaró a dolog, mert ha túlcsordul, megáll a program, ha kevesebbet olvasok be, adatvesztés van.

Mi okozza ezt a hibát? A getline, vagy a szövegtárolás különbsége, vagy más? Hogyan tudnám ezt kivédeni?

Köszi, üdv
tsb

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Remélem nem kérdeztem túl nagy hülyeséget...
Valaki találkozott már ilyesmivel?

"aki kerdez az butanak erzi magat par percig, aki nem kerdez az buta marad orokre" :)

unixon a sorvege '\n', dos/windows-on '\r\n' (ha jol emlekszem a sorrendre), macintoshon '\r'.

http://en.wikipedia.org/wiki/Newline#Representations

olyat tudsz csinalni, hogy forditas kozben definialod, vagy a meretet, vagy a karakter, attol fugg hogyan keresed

--
Unix, Perfectly "natural" after five or ten years.

Ha mondjuk 'len' a sor hossza, és a 'line' változóban van a sor tartalma, akkor valahogy így lehetne:

   if (len>0 && line[len-1]=='\n') line[--len]= '\0';
   if (len>0 && line[len-1]=='\r') line[--len]= '\0';

Vagy, még egyszerűbben, megteheted, hogy a file-t eleve az úgynevezett textmódban nyitod meg, akkor a kocsivissza jeleket a rendszer automatikusan kiszűri/beszúrja:

fin = fopen (name, "rt");
fout = fopen (name, "wt");

windows -ban a text módű olvasás sosem jött be nekem.
1. próbáld meg a getline helyett a régi és veszélyes gets -et - jó nagy puffert adj neki(!).
2. Írjál saját sor beolvasó rutint ami karakterenként olvas és adig megy amíg kell.

Sziasztok

Köszönöm mindenkinek a hozzászólásokat!
Első körben az jutott eszembe, hogy felveszem a \r -t is a figyelmen kívül hagyott karaterek listájára. Ha ez nem működik, akkor megpróbálom a \0 -ás helyettesítést.

thx ögen
tsb

Még egy ötlet.
Nem akarok bekavarni, de mintha a DOS-nál lett volna ú.n. fájl-vég karakter is. Ez a hexa 0x1A és a DOS-os text-feldolgozás a fájlban való első előfordulásakor befejeződött.

Szia!

Szerintem a legegyszerűbb, ha a szöveges fájlt átkonvertálod unix-os formátumba (unix2dos nevű progival), és megnézed, hogy így is jelentkezik-e a probléma. Unix/Linux-ban ugye a fájl vége karakter csak a soremelés (line break), windows/dos-ban pedig carriage return (kocsi vissza) + line break(sortörés), tehát eggyel több karakter.