There are a couple of things in this discussion that are still unanswered. One is whether it is allowed to change the access type of a file (back and forth between stream and
sequential), and the other is what happens with the NEW_LINE('a') statement when the file is connected with access='sequential'. These two issues are important when trying to write portable code, particularly when that code is outside the standard (as with those last two write statements). I think for the first question that it is allowed by the standard to change access, but a compiler is not required to perform this function. If it can perform this function, I don’t think it is required to do so for all connected files, so there may be some files where it can be done by the programmer but others where it cannot. The other question is really about what happens on windows type file systems when the NEW_LINE('a') write statement is executed on a sequential file. Does it work anyway, does it append everything to a single line, does it generate an error, or what?
Another related question is how to change the access type for the preconnected unit associated with print fmt and write(*,fmt). There are some file characteristics that can be modified with an open() statement without closing the file, but I don’t think access= is one of them, and if you close and reopen output_unit, then it loses its association with print fmt and write(*,fmt). Without the ability to change the access type, and with unspecified behavior for the default access='sequential' case, the use of this feature seems to be nonportable when applied to output_unit (i.e. to screen output).
Unfortunately, ACCESS is not a changeable mode. That makes it difficult to write filter programs that often require stream access on stdin and stdout. Unfortunately, it is just easier to call the C I/O procedures than to try to deal with this deficit, as many aspects of getting the name of the actual file preconnected is allowed to be compiler-dependent, so using INQUIRE and trying to CLOSE and OPEN stdin and stdout is not a portable solution. Non-advancing I/O is not the same as stream I/O so reading stdin one byte at a time or writing to stdout one byte at a time using non-advancing I/O will fail with larger files and so on as well. It would be really nice if Fortran addressed this, as binary filters are an essential part of the GNU/Linux and Unix approach of creating filters as tools and creating custom commands by permuting the filter commands, connecting their I/O via pipes.
23 12.5.2 Connection modes
24 Aconnection for formatted input/output has several changeable modes: these are the blank interpretation mode
25 (13.8.7), delimiter mode (13.10.4, 13.11.4.2), sign mode (13.8.4), leading zero mode (13.8.5), decimal edit mode
26 (13.8.9), input/output rounding mode (13.7.2.3.8), pad mode (12.6.4.5.3), and scale factor (13.8.6). A connection
27 for unformatted input/output has no changeable modes.
NEW_LINE is not part of the I/O system and has no knowledge of how a particular unit is connected. If you send the result of a reference to NEW_LINE to file connected for sequential access, you’ll get the character with ordinal 10 (typically LF).
As for changeable modes, I wrote about this topic in Doctor Fortran in “The Modes, They are A-Changin’” - Doctor Fortran
It should be added that for sequential access, the records terminator is still (probably) platform-dependent —e.g., CRLF for Windows, LF for Unix.
The Intel Fortran compilers have a non-standard RECORDTYPE specifier to change the default records terminator. Do gfortran|flang|nvfortran have anything similar?
Yeah, those originated on VMS, which had a variety of protocols for record separators. I would not recommend trying to propagate them.
Hello all!
Very good advice here, but I’ll add this;
That’s a link to an ANSI module that I’ve written for my own text stuff. Just make sure to include it as a use line and on the compiler line BEFORE your program file. There are functions for writing to a specific position, clearing part/all the screen, or changing colors.
Knarfnarf
p.s. rename from .txt to .f90 before trying to compile.