# FORTRAN in linux..read file problems

by jelanier
 P: 40 I wrote a simple FORTRAN program to show my read problem. This works fine in windows. On the Linux machine I always get this eof error when I open a file and read. This means that every program I have written doesn't work :) The error is line 12 EOF. What is the problem? (I am using GFORTRAN in linux) program read_write implicit none !reads data from a file called input.dat integer :: i real a(10) !single dimension array real b(10) open(10,file='input.dat') do i = 1,10 read(10,*) a(i) !this is line 12 b(i) = a(i)**1.3 end do close(10) open(12,file='output.dat') do i = 1,10 write (12,*) a(i),b(i) end do close(12) end program read_write oh, the input file is simply: 1 2 3 4 5 6 7 8 9 10 Thanks, Jim
 Mentor P: 11,628 The program may be looking for input.dat in a different directory (folder) from where it actually is. Try specifying the complete path to the file.
P: 40
 Quote by jtbell The program may be looking for input.dat in a different directory (folder) from where it actually is. Try specifying the complete path to the file.
Nice try, but did not fix it. Same error. BTW I have everything in the same directory.

Jim

 Emeritus Sci Advisor HW Helper Thanks PF Gold P: 6,334 FORTRAN in linux..read file problems Is output.dat a new file or one which already exists? If it is new, I would add STATUS = 'NEW' to the open command.
P: 40
 Quote by SteamKing Is output.dat a new file or one which already exists? If it is new, I would add STATUS = 'NEW' to the open command.
The output file is fine. If I internally specify the input data it will always create a new output file.

IOW..I can always write files, I just can't read files.
 Engineering Sci Advisor HW Helper Thanks P: 6,959 When you do open(10,file='input.dat') if the file input.dat doesn't exist in the directory where Fortran expected to find it, it will create a new empty file. Reading from that will (obviosuly) give you an EOF error. Do a search of your file system for "input.dat" files and delete any empty (zero length) ones that should't be there. Then change the statement to open(10,file='input.dat',status='old') That will fail if Fortran it can't find the "real" input.dat file. Usually you don't need the "status" option for an output file, because you want to overwrite an existing file if it already exists, or create a new one if it doesn't exist, and that's what happens by default.
 P: 40 I found a solution. This Linux GFORTRAN compiler handles files differently than the g77 or g95 for windows. I added a $D,$A (CR,LF) at the end of the file. It works now. FWIW..I am using a Raspberry Pi with Debian. Thanks everyone. Jim
 P: 873 I seem to recall a problem like this. I don't remember if dos2unix/unix2dos kind of thing had something to do with it...but it certainly had something to do with the end-of-file character being right after the last entry...so, if you went to the very end and press and re-saved the file, the problem goes away. For example, if the original file looked like this: 12.3EOL 23.4EOL 34.5EOF If wouldn't work, but if it looked like this: 12.3EOL 23.4EOL 34.5EOL EOF Then, if would work. I noticed that such condition could happen depending depending on the editor that you are using to enter the data; for example, if I use Nedit and type the data in and leave the EOF right after the last entry, Nedit automatically increases the number of line in the file and moves the EOF by itself to the next line; but, if I use something like Notepad++, it leaves the data the way I typed it. my 2 cents.
 Engineering Sci Advisor HW Helper Thanks P: 6,959 It's so long since I've seen a text editor that let you create a file with an "unterminated" last line, I forgot about that problem! But hey, one of the design goals of Unix was NOT to protect people from their own stupidity - not "what you see is what you get" but "what you got was all you deserved"
P: 40
Thanks for the reply. I have seen this before with different compilers. They all seem to handle CR LF differently. A few test programs were run and the solution was found.

Thanks again,

Jim

 Quote by gsal I seem to recall a problem like this. I don't remember if dos2unix/unix2dos kind of thing had something to do with it...but it certainly had something to do with the end-of-file character being right after the last entry...so, if you went to the very end and press and re-saved the file, the problem goes away. For example, if the original file looked like this: 12.3EOL 23.4EOL 34.5EOF If wouldn't work, but if it looked like this: 12.3EOL 23.4EOL 34.5EOL EOF Then, if would work. I noticed that such condition could happen depending depending on the editor that you are using to enter the data; for example, if I use Nedit and type the data in and leave the EOF right after the last entry, Nedit automatically increases the number of line in the file and moves the EOF by itself to the next line; but, if I use something like Notepad++, it leaves the data the way I typed it. my 2 cents.
P: 40
 Quote by AlephZero It's so long since I've seen a text editor that let you create a file with an "unterminated" last line, I forgot about that problem! But hey, one of the design goals of Unix was NOT to protect people from their own stupidity - not "what you see is what you get" but "what you got was all you deserved"
No problem! I am writing a compiler that compiles "what you meant to do" hehe

Thanks,

Jim
Mentor
P: 21,214
 Quote by jelanier Thanks for the reply. I have seen this before with different compilers. They all seem to handle CR LF differently. A few test programs were run and the solution was found.
Operating systems handle ends of lines differently. IIRC, Windows adds a <CR> <LF> pair at the end of a line, while Unix and Linux add only a <CR> character.
P: 40
 Quote by Mark44 Operating systems handle ends of lines differently. IIRC, Windows adds a pair at the end of a line, while Unix and Linux add only a character.
That has not been my experience. The linux text editor I use only places a LF ($0A). I saved the file with no "enter" at the end of the last line, and again with enter at the end. The one with no enter, has nothing after the last character. The one with "enter" has only a LF ($0A) after the last character.

see attachment. (I used Leafpad in Debian Linux for this test)

Thanks,

Jim
Attached Thumbnails

 P: 873 As people develop their own editors, they can do whatever they want regardless of operating system and/or cater to both; in particular, if they are developing a multi-platform text editor....all you have to do is go to the settings and pick how you want your lines terminated: Windows or Unix style.

 Related Discussions Programming & Computer Science 20 Programming & Computer Science 4 Programming & Computer Science 4 Programming & Computer Science 5 Programming & Computer Science 5