Home > Archive > Fortran > January 2006 > Moving a text file
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Moving a text file
|
|
|
| Hi,
I'm trying to write a subroutine to move a file. I know this is kind of
a fortran FAQ, but I'd like to hear comments on the following piece of
code. It seems to work OK, but I would like to know if it can be
improved. I don't want to use a system call for this, or non-standard
(95) Fortran as I want it to be as portable as possible. However, it
does not need to be highly efficient and furthermore, I'm already happy
if it works for text files, preserving the number of spaces at the end
of lines is a bonus.
That's how far I get, it seems to work fine as long as the obvious
limitation (lines shorter than max_line_length characters) is not
important:
SUBROUTINE move_file(file_in,file_out)
IMPLICIT NONE
CHARACTER(len=*) :: file_in,file_out
INTEGER, PARAMETER :: max_line_length=1024*32
INTEGER, PARAMETER :: iunit_in=10
INTEGER, PARAMETER :: iunit_out=11
CHARACTER(len=max_line_length) :: line
CHARACTER(len=100) :: myfmt
INTEGER :: i
WRITE(myfmt,'(A,I0,A)') '(A',max_line_length,')'
OPEN(iunit_in,FILE=file_in,ACTION="READ", &
PAD="YES",POSITION="REWIND")
OPEN(iunit_out,FILE=file_out,ACTION="WRITE", &
STATUS="UNKNOWN",POSITION="REWIND")
DO
READ(iunit_in,FMT=myfmt,SIZE=i,ADVANCE="NO", &
EOR=100,ERR=10,END=999) line
STOP "No EOR (line too long), file not moved"
10 CONTINUE
STOP "Error, file not moved"
100 CONTINUE
WRITE(iunit_out,'(A)') line(1:i)
ENDDO
999 CONTINUE
CLOSE(iunit_in)
CLOSE(iunit_out)
OPEN(iunit_in,FILE=file_in,ACTION="WRITE")
CLOSE(iunit_in,STATUS="DELETE")
END SUBROUTINE move_file
CALL move_file("tmp.F","tmp.F.bak")
END
| |
| Steven G. Kargl 2006-01-10, 9:58 pm |
| In article <1136907625.877124.270540@f14g2000cwb.googlegroups.com>,
"Joost" <jv244@cam.ac.uk> writes:
>
> OPEN(iunit_in,FILE=file_in,ACTION="READ", &
> PAD="YES",POSITION="REWIND")
>
> OPEN(iunit_out,FILE=file_out,ACTION="WRITE", &
> STATUS="UNKNOWN",POSITION="REWIND")
IOSTAT should probably used to check that a user
has access to the file and the location to where
you want to move it.
>
> OPEN(iunit_in,FILE=file_in,ACTION="WRITE")
> CLOSE(iunit_in,STATUS="DELETE")
What if you are on a read-only filesystem. Again,
use IOSTAT.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Richard E Maine 2006-01-10, 9:58 pm |
| Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
> What if you are on a read-only filesystem. Again,
> use IOSTAT.
Unless, of course, aborting is what you would want to do in that case.
If that's all you want to do for such a case, then I actually recommend
not using IOSTAT, as the system is likely to get a better error message
without IOSTAT than you are going to be able to generate in your own
code (until f2003's errmsg specifier, which I look forward to for
exactly this kind of reason - I hate having to turn off my own error
handling in order to be able to find what the system's error message
would have been).
Above all, I caution people *AGAINST* specifying iostat= and no0t
checking what it returns. This might be obvious to you, Steven, but I
have known people for whom it was not obvious, who actually thought that
just specifying iostat= would do useful things for them without the need
for extra code. That's why I try to be quite explicit about
recommendations relating to iostat and say to test the returned value
rather than just to "specify" or "use" it.
So either specify iostat= and then check the value, or don't specify it
at all. But don't specify it and then ignore the returned value.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| beliavsky@aol.com 2006-01-10, 9:58 pm |
| Since iunit_in and iunit_out may already be connected to other files, I
suggest writing a loop to find the first unused unit number (starting
at 20, say), using the INQUIRE statement.
|
|
|
|
|