tekstitiedosto pc -> linux
Jyrki Saario
peräisin win -käyttöjärjestelmästä?
Eli jos olen tehnyt lähdekoodin tiedostoon hello.cpp ja siirän sen linuxiin
ja koitan kääntää sen g++:lla tuleepi herjaa. Mitä hittoa se wintötsä tunkee
sen rivin lopuun mitä ei edes näe vaikka lukisi tiedostoa get() -funktion
avulla? Miten sen saa win-ohjelmalla pois?
Jyrki Saario
KajBre
tekstitiedoston rivin loppuun sekä CR:n (hex 0d) että LF:n (hex 0a) eli
Carriage Return + Line Feed ohjausmerkit, kun Unix:eissa käytetään vain
LF:ää.
Saahan Windowsiin tekstieditoreita, jotka osaavat tallentaa tekstitiedoston
rivit ilman CR:ää, esim. meikäläisen käyttämä GWD Text Editor (shareware:a,
mutta ihan suositeltava).
Kaj Bredenberg
"Jyrki Saario" <jyr...@NOSPAMsaunalahti.fi> kirjoitti viestissä
news:9lrst0$11t$1...@news.cc.tut.fi...
Juhapekka Tolvanen
"Jyrki Saario" <jyr...@NOSPAMsaunalahti.fi> writes:
Linuxin puolella: man dos2unix
Mutta saattaahan tuo dos2unix-softa löytyä jostain myös DOS:sille tai
jopa Windowsille portattuna.
--
Juhapekka "naula" Tolvanen * * University of Jyväskylä * * juh...@st.jyu.fi
http://www.st.jyu.fi/~juhtolv/spam.html * * * * * * "STRAIGHT BUT NOT NARROW"
-----------------------------------------------------------------------------
"Olen saanut palautetta, että olisin saanut silloin ja silloin jos olisin
tehnyt aloitteen. Ko. naiset eivät voineet tehdä aloitetta, koska se "kuuluu"
miehelle. Tok tok. Sitten kun aloitteita tekee, niin naiset loukkaantuvat ja
katkaisevat välit. Hullujenhuoneelle koko porukka." Hiski Haapoja
Jyrki Saario
oikein löytänyt narunpäätä mistä alkaa vetämään.
Jyrki Saario
Paul Keinanen
<jyr...@NOSPAMsaunalahti.fi> wrote:
>Miten poistan kääntäjän herjan joka tulee mikäli lähdekooditiedosto on
>peräisin win -käyttöjärjestelmästä?
Siirrä tiedosto koneiden välillä FTP:llä ASCII muodossa, niin se
hoitaa automaattisesti rivinvaihdot kunkin kohdekoneen mukaiseksi.
Tämä toimii kaikkien sellaisten käyttöjärjestelmien välissä, joihin
ylipäätänsä on saatavissa FTP.
>Mitä hittoa se wintötsä tunkee sen rivin lopuun
CR LF
Unix/Linux ilmeisesti ainoana käyttää pelkkää LF:ää.
Joku järjestelmä käyttää pelkkää CR:ää.
Muutamat muut eivät talleta rivinvaihtoja tiedostoon ollenkaan, vaan
tallettavat sinne pelkän pituuden ja on terminal-driverin asia
generoida kirjoitinpään ohjauskomennot (tai sen simuloinnit
näyttöpäätteellä).
Fortran carriage controllissa rivin ensimmäisen merkki määrää
kirjoitusasun. Blankko aiheuttaa tavallisen rivivälin. '0' aiheutaa
tuplarivivälit ja '1' aiheuttaa sivunvaihdon ja muistaakseni '+'
aiheuttaa rivin päällekirjoittumisen edellisen rivin päälle (varsin
kätevää oikeilla kirjoittimilla).
Tässä on muutamia rivien erottelutapoja joihin olen törmännyt, mutta
niitä on varmasti paljon enemmän. Mutta kuten sanottu, kussakin
konetyypissä on sille muokattu FTP-ohjelma, joka osaa tämän huomioida.
Paul
Jukka K. Korpela
>>Mitä hittoa se wintötsä tunkee sen rivin lopuun
>
> CR LF
>
> Unix/Linux ilmeisesti ainoana käyttää pelkkää LF:ää.
No ei ihan "ainoana", mutta tuontapaisesta rivinvaihtojen esitysten
eroista on kyllä kyse noiden systeemien välillä, ja se voi aiheuttaa
monenlaisia ongelmia. Yleinen "tutkielmani" aiheesta:
http://www.cs.tut.fi/~jkorpela/rv/
Mutta se tässä jää avoimeksi, miksi erosta aiheutuu ongelmia
lähdekielisten ohjelmien osalta. Kieleksihän voimme aihetodisteiden
perusteella päätellä C++:n, eikä kai siinä pitäisi haitata, vaikka
jokaisen LF:n edellä onkin CR - voisi luulla, että kääntäjä ignoroi CR:t.
Tosin jos on käytetty jatkorivikonventiota eli rivin lopussa ennen
rivinvaihtoa on kenoviiva \, niin silloin voi hyvinkin olla, että
kääntäjä ei tunnista sitä rivinloppuiseksi, ellei sitä seuraa nimenomaan
LF (niissä systeemeissä, joissa pelkkä LF on rivinvaihdon merkki).
--
Yucca, http://www.malibutelecom.com/yucca/
alias http://www.cs.tut.fi/~jkorpela/
Tuomo A Turunen
> Mutta se tässä jää avoimeksi, miksi erosta aiheutuu ongelmia
> lähdekielisten ohjelmien osalta. Kieleksihän voimme aihetodisteiden
> perusteella päätellä C++:n, eikä kai siinä pitäisi haitata, vaikka
> jokaisen LF:n edellä onkin CR - voisi luulla, että kääntäjä ignoroi CR:t.
Olisi todella suotavaa, että esim. gcc nielisi myös CR:t mukisematta,
mutta eipä niele. Tätä olen itsekin jaksanut ihmetellä pitkään.
Toisinpäin taas asia toimii homattavasti useammin: Windows kääntäjiä ei
haittaa puuttuvat CR:t mitenkään.
> Tosin jos on käytetty jatkorivikonventiota eli rivin lopussa ennen
> rivinvaihtoa on kenoviiva \, niin silloin voi hyvinkin olla, että
> kääntäjä ei tunnista sitä rivinloppuiseksi, ellei sitä seuraa nimenomaan
> LF (niissä systeemeissä, joissa pelkkä LF on rivinvaihdon merkki).
Tämänkin luulisi olevan helppo muuttaa. Esim. mikä tahansa CR+LF
yhdistelmä (tai jompikumpi yksinään) käsitellään rivinvaihtona.
--
Tuomo Turunen
http://www.cs.helsinki.fi/u/tuturune/
Tero Ripattila
says...
> Tämänkin luulisi olevan helppo muuttaa. Esim. mikä tahansa CR+LF
> yhdistelmä (tai jompikumpi yksinään) käsitellään rivinvaihtona.
Joku noheva koodaaja voisi tosiaan toteuttaa ominaisuuden gcc:hen. Onhan se
kuitenkin open sourcea :)
//Tero
Heikki Orsila
> Unix/Linux ilmeisesti ainoana käyttää pelkkää LF:ää.
Väärin. (vastaesimerkkinä AmigaOS)
Minusta win-puoli voisi siirtyä "CR LF" käytöstä pelkkään LF:ään, koska se on
enemmän käytännönläheinen nykyään (ohjelmointisyyt).
--
Heikki Orsila 32 bittiä - entä sitten?
heikki...@ee.tut.fi http://www.pjoy.fi/lehdet/9212pj.htm
http://www.ee.tut.fi/~orsila - Petteri Järvinen (1992)
Paul Keinanen
<jkor...@cs.tut.fi> wrote:
>No ei ihan "ainoana", mutta tuontapaisesta rivinvaihtojen esitysten
>eroista on kyllä kyse noiden systeemien välillä, ja se voi aiheuttaa
>monenlaisia ongelmia. Yleinen "tutkielmani" aiheesta:
>http://www.cs.tut.fi/~jkorpela/rv/
Tuo on varsin kattava esitys aiheesta !
Tuosta VMS osuudesta saa kuitenkin hieman vinoutuneen käsityksen.
Vaikka on totta, että varsinkin joissain VFC (Variable with Fixed
Header) formaateissa saattoi esiintyä joitain CR, LF tai CR LF
käytäntöjä ja lisäksi VMS-ympäristössä saatettiin käyttää
compatibiliteettimoodissa ajettuja, joitain huonosti RSX-11
ympäristöön portattuja RT-11 ohjelmia, jotka generoivat edelleen
RT-11 mukaista CR LF formaattia, niin pääasiallinen tiedostomuoto
ainakin tekstieditoreiden osalta oli Files-11, joka oli RSX-11:n
(PDP-11) varsinainen tiedostoformaatti.
Files-11 tiedostojärjestelmässä tiedostolla saattoi olla kolme eri
carriage control muotoa.
Tekstitiedostostoissa yleisin carriage controllin muoto oli "list",
jossa mitään rivinvaihtomerkkejä ei käytetty, vaan kunkin tietueen
edessä oli 15 bittinen pituustieto, joten tietueen maksimipituus oli
32 Ktavua, eli puolet RSX-11 taskin osoiteavaruudesta. Koska PDP-11 ei
suostunut käsittelemään parittomia sanaviittauksia, tuo pituustieto
oli aina parillisessa offsetissa, joten joidenkin tietueiden perässä
oli käyttämätön tavu. Terminal driveri hoiti kontrollimerkkien
lisäyksen ja ainakin raskaasti kuormitetuissa RSX-järjestelmissä oli
helposti havaittavissa, että se lähetti ensin LF merkin, sitten itse
tekstin ja lopuksi CR merkin. En koskaan ole nähnyt näin raskaasti
kuormitettua VMS järjestelmää, joten en osaa sanoa miten se on siinä
tehty.
Files-11 tiedosto saattoi myös olla Fortran tulostiedostoformaatissa,
jossa " ", "0", "1" ja "+" rivin alussa määräsi, miten rivinvaihdot
hoidetaan. Aloittelevan Fortran-ohjelmoijan tyypillisin virhe oli se,
että hän unohti jättää tulostusrivin alkuun blankon, joten kun
tulostettava luku alkoi ykkösellä, printteripaperia alkoi kulua suuria
määriä :-).
Kolmannessa Files-11 formaatissa ei ollut riviohjausta ollenkaan, jota
käytettiin esim. objektitiedostoissa tai alunperin RT-11 ympäristöstä
peräisin olevien ohjelmien tulostuksissa, jossa ohjelma itse lisäsi CR
ja LF merkit itse tietueeseen.
Mainittakoon vielä, että ilman muistinhallintaa olevissa PDP-11
prosessoreissä ajettiin yleensä RT-11 käyttöjärjestelmää (jossa siis
tiedostoon talletettiin CR ja LF merkit), jonka on täytynyt toimia
ISIS:in (Intellec, Intelin kehitystukilaitteisto), CP/M:n ja MS/PC-DOS
käyttöjärjestelmien esikuvana, yhteneväisyys on sen verran
silmäänpistävä. Tällä perusteella ei ole mikään ihme, että MS-DOS ja
Windows käyttävät tuota CR LF käytäntöä.
Paul
Kalle Olavi Niemitalo
> Olisi todella suotavaa, että esim. gcc nielisi myös CR:t mukisematta,
> mutta eipä niele.
Kyllä ainakin Debianin gcc-2.95 (1:2.95.4-0.010506) ja gcc-3.0
(1:3.0-1) nielevät. Kikka lienee cpplex.c:n funktiossa
handle_newline.
/* Handle CR-LF and LF-CR combinations, get the next character. */
Aaro Koskinen
> Tuomo A Turunen <tutu...@cc.helsinki.fi> writes:
> > Olisi todella suotavaa, että esim. gcc nielisi myös CR:t mukisematta,
> > mutta eipä niele.
>
> Kyllä ainakin Debianin gcc-2.95 (1:2.95.4-0.010506) ja gcc-3.0
> (1:3.0-1) nielevät. Kikka lienee cpplex.c:n funktiossa
> handle_newline.
Enpä nyt pääse kokeilmaan uusimpia versioita, mutta joskus on ainakin
CR-merkeistä on tullut pelkkä varoitus; koodi on kyllä kääntynyt aina
OK.
BTW, VIM-editori toimii Windowsissa aika fiksusti, eli tallettaa
tiedoston siinä formaatissa kun se on luettukin; ei tarvitse välittää
formaattiongelmista jos samat tiedostot on sharetettu Windows- ja
UNIX-koneisiin ja niitä editoi milloin missäkin.
--
Aaro Koskinen, aa...@iki.fi, http://www.iki.fi/aaro