Fortran reading and writing files

Fortran reading and writing files

Below is some code i made to read data from a text file and then write it to another the line of code that trips it is " read (10,*)i,j " I tried hard to find why it doesnt work but i cant do it. Someone please help!

 program xproduct
    implicit none
        integer :: i,j
        open (unit=10,file='C:\\Fort\pete.txt')
        read (10,*)i,j

       open (unit=20,file='C:\\Fort\pete.out',action="write",
     1  status="replace")
    write (20,*) "The product of",i," and",j
    write (20,*) "is",i*j
    close (unit=20)
        close (unit=10)
   end program xproduct

19 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I suppose we would need to see the contents of pete.txt as well as the full text of the error message.

Retired 12/31/2016

The following adaptation of xprodict should identify the problem:

program xproduct
    implicit none
       integer :: i,j, iostat
       open (unit=10,file='C:\Fortpete.txt', iostat=iostat)
         call report_error (iostat, 'Opening C:\Fortpete.txt')
       read (10,*,iostat=iostat)i,j
         call report_error (iostat, 'Reading i,j')
       open (unit=20,file='C:\Fortpete.out',action="write",status="replace", iostat=iostat)
         call report_error (iostat, 'Opening C:\Fortpete.out')
       write (20,*, iostat=iostat) "The product of",i," and",j
         call report_error (iostat, 'Writing i,j to 20')
       write (20,*, iostat=iostat) "is",i*j
         call report_error (iostat, 'Writing i*j to 20')
       close (unit=20, iostat=iostat)
         call report_error (iostat, 'Closing C:\Fortpete.out')
       close (unit=10, iostat=iostat)
         call report_error (iostat, 'Closing C:\Fortpete.txt')
   end program xproduct
   subroutine report_error (iostat, comment)
   integer :: iostat
   character comment*(*)
!   if (iostat==0) return
   write (*,*) '    iostat =',iostat,' :',comment

Perhaps 'C:\\Fort\pete.txt' should be 'C:\Fort\pete.txt' is all that is wrong ?


You might find the following changes helpful, as I included IOSTAT= reports.

(I could not find a IOSTAT message routine in ifort help, so wrote my own ? Is there one available ?)


Downloadapplication/octet-stream peter.f9031.49 KB

Fortran does not use the C/C++ escape character prefix "\" thus no requirement to use "\\" to pass one "\". Your file specification therefore contains a double \. Windows would likely treat this as C:, goto root (\), goto root again (\), ...

Try changing "\\" to "\" and see what happens.

Jim Dempsey


John Campbell wrote:
(I could not find a IOSTAT message routine in ifort help, so wrote my own ? Is there one available ?)

The IOMSG specifier does something similar, i.e. CHARACTER(100) :: msg ; OPEN(xxx, IOSTAT=stat, IOMSG=msg)

I tried the IOSTAT=reports and IOMSG=reports but both of them came up with errors for unpaired right brackets on lines 9 and 10

also I removed a "/" from the place in my file path names where I had two instead of one. Nothing changed but i bet its still right coz im just a fortran newbie.

IOSTAT= assigns to an integer variable the value of which you can look up in the help (cf IOSTAT, errors returned to)
IOMSG= assigns to a character variable.
In a post above you say "both of them came up with errors for unpaired right brackets on lines 9 and 10" That sounds like a compile time error rather than a runtime error.

It would help us to help you if you attached the actual (unedited) code.

Is the code fixed or free form ?



The latest errors reported could be that the compiler assumes you have a fixed format (.for), rather than free format (.f90) code.

In the first post I did, I can now see that the use of cut/paste again did not work in this windows forum.  The paste changed the use of \, removing 2 of the 3 \ in each file name.
 ( For how long do we continue to have to work around basic things like cut/paste not working and the hastles of soft and hard carriage returns ! Again, this is a "windows" forum)

My best guess of your original problem is the .txt file is either not opened correctly (does not exist or access rights problems) or the first two entries in the file are not the values of the two integers, I & J.



Cut/paste works if you follow the instruction for including Fortran code.  You do this as follows:

[ fortran ]
your code here
[ /fortran ]

except that there are no blanks in the surrounding tags (if I removed the tags here then they'd be interpreted.) However, I am not aware that it removes backslashes. Why would you have three backslashes in a filename? Maybe you have this wrong in the source - the file you're opening should be specified as ''C:\Fort\pete.txt'. This is Fortran, not C, you don't escape backslashes (unless you're using C strings, which you're not.) In fact, this may be your entire problem.

Retired 12/31/2016


The three \ is not the problem, as I tested it, using Peter's original file names and found that the file opened successfully. Jim offered an explaination of this. However, I would change the name.
The answer might be in Windows 7/8 access rights. Opening the file for readonly access might remove the problem. My recommendation is to check the IOSTAT value of each file access.
A copy of pete.txt might also provide some insight.



The reason I wondered about the file name is that he hasn't yet told us what the error is. Often I see cases where the file that is opened is not the one the user wanted, and a new, empty file is created by default. Then a READ will get an end-of-file.

Yes, we are all trying our crystal balls and finding them inadequate...

Retired 12/31/2016

I disagree that paste works if you enclose it in Fortran delimiters. Yes it pastes, but the result is mangled. At the very least, it tends to delete blanks and insert line breaks. And the visual formatting is atrocious; everything appears double-spaced and occasionally triple-spaced if it happened that a real line break was inserted. After pasting, you have to go through the result carefully and fix it up or it won't appear right.


dboggs wrote:

...At the very least, it tends to delete blanks and insert line breaks..

Not only is the visual appearance affected but one has to "submit" the post, inspect the not-so-pretty results and correct line numbers if they are mentioned in the text of the post. Too often, the line numbers mentioned in the post do not match those in the program listing and one has to edit the post and fix the line numbers.


Steve Lionel (Intel) wrote:

However, I am not aware that it removes backslashes. Why would you have three backslashes in a filename? 

The syntax highlighting formatter devours characters such as backslash, <, >, [, ]. To compensate for this, one sometimes tries to give it two, with the hope that it will eat only one and leave the other intact so that readers can view it. See this thread to see how the formatter, given a simple C source, ate the angle brackets and the included file names: .  Even using the "view page source" feature of the browser does not reveal the include file names -- they are gone for ever.

There must be a fairly significant difference between the aims of the developers of this forum and the experiences of it's users. For those of us who are developing Fortran code in a windows environment, the way this forum IDE responds is very frustrating and distracting from what we are trying to do. I am becoming amazed and frustrated at the persistence of Intel in not fixing what is a user interface with significant problems.

The way it handles a simple Enter, and how it devours a basic cut and paste should have been corrected months ago. I suspect this response must be acceptable in some other computer environment, but not one I am familiar with. All other IDE's I use on my Windows system do not behave like this, and you can use a fairly general interpretation of IDE, such as Visual Studio, Word, Notepad, other forums etc. Even booking a flight on-line is easier than this !

Why can't it be fixed.

With regard to the learned approach of posting, then editing; this is only allowed in a response post, as the original post to a new thread can not be edited. There are a few examples there of devoured layouts in a new thread post.


For what it's worth, if you write

STRING = 'C:\\Fort\pete.txt'C

where the appended C marks the character string as a 'C-string',
and then compile, the COMPILER will treat the first backslash as a control character
telling it that the next backslash is ok and it will not store (i.e. remove) the first backslash,
so STRING will be filled with the string 'C:\Fort\pete.txt' after it is stored somewhere in the executable ready for when the program is executed.

However, suppose you have a concatenation such as


Then the COMPILER will not remove the extra backslash in STRING1, as it is not marked as a C-string (no appended 'C'),
but during compilation it will remove the extra backslash in the string being concatenated, as it is marked as a C-string and therefore recognised as such. The result will be STRING2 will have an extra backslash in the path and so that may cause a problem later.
Basically, if the compiler can 'see' and therefore 'recognise' a string as a C-string, it will interpret control combinations such as //, /r,/n,/b,/a (backslash, newline,backspace, bell) and store the appropriate ASCII character in the place of the 2-character escape sequence combination.
If it cannot recognise the string as a C-string, it will just take the characters presented and store them.


The \ removal came about when I copied text from a notepad screen to the forum comment box,via word paste (to try and overcome the hard/soft returns) and enclosed the text with the [ fortran ][ /fortran ], as Steve is suggesting.
I did not notice this change to the post until some time later. ( the later attached file would show the difference.)

It did not come about during a ifort compilation.

My apologies if I did not explain clearly, but it was another frustration with how this forum "IDE" works.


Leave a Comment

Please sign in to add a comment. Not a member? Join today