- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does anyone know why when I close stdin and reopen it as unformatted,
stream access I can successfully read in files using the redirection
'<' symbol, but if I 'cat' the file and pipe it into the code, I get
an 'illegal seek' error?
I have also tried to use a named pipe created with mkfifo and this still happens.
Say I use matlab to make some data:
then I try the following test program:
Also, please note, the original source code douse not have an extra 'd' in the doubleprecision declaration. This appears to be a bug with the source highlighter.
Compiled with:
Using a pipe I get this:
Using redirection i get this:
Is this because there are no longer record indicators so when I close then reopen stdin as stream access the program loses track of where it is in the stream?
If I try this technique with sequential access I don't encounter this problem. (Note, you need to write binary data with fortran so that it includes the sequential access record indicators which are stripped off for stream access.)
Thanks,
-Z
I have also tried to use a named pipe created with mkfifo and this still happens.
Say I use matlab to make some data:
[plain]>> fid = fopen('test.bin','w'); >> fwrite(fid,double(pi),'double'); >> fclose(fid);[/plain]
then I try the following test program:
[fortran]program tester use iso_fortran_env implicit none doubleprecision :: pi integer :: error close(input_unit) open(unit=input_unit,access='stream',form='unformatted',iostat=error) write(output_unit,*) error read(input_unit,iostat=error) pi write(output_unit,*) error write(output_unit,*) iostat_end write(output_unit,*) iostat_eor write(output_unit,*), pi end program [/fortran]
Also, please note, the original source code douse not have an extra 'd' in the doubleprecision declaration. This appears to be a bug with the source highlighter.
Compiled with:
[bash]ifort -g -warn all -check all -traceback -o tester tester.f90[/bash]
Using a pipe I get this:
[bash]$ cat test.bin | ./tester 0 38 -1 -2 1.117351266127586E-315 [/bash]
Using redirection i get this:
[bash]$ ./tester < src/matlab/roughness/test.bin 0 0 -1 -2 3.14159265358979[/bash]
Is this because there are no longer record indicators so when I close then reopen stdin as stream access the program loses track of where it is in the stream?
If I try this technique with sequential access I don't encounter this problem. (Note, you need to write binary data with fortran so that it includes the sequential access record indicators which are stripped off for stream access.)
Thanks,
-Z
Link Copied
- « Previous
-
- 1
- 2
- Next »
24 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hopefully the fix won't introduce an error.
The OPEN for stream I/O on pipe should work, however user program REWIND or SEEK should report error/warning (or at least be consistent with the FORTRAN standards committee position regarding this).
Perhapse a mode on the open can be used to indicate behavior for meaningless statements (or specify meaning of questionable statements).
Should REWIND on CON prompt the user to retype their input?
Should SEEK to 50 bytes from end of file on CON prompt the user to skip over the blah, blah, blah and type the last 50 bytes of their input.
Jim
The OPEN for stream I/O on pipe should work, however user program REWIND or SEEK should report error/warning (or at least be consistent with the FORTRAN standards committee position regarding this).
Perhapse a mode on the open can be used to indicate behavior for meaningless statements (or specify meaning of questionable statements).
Should REWIND on CON prompt the user to retype their input?
Should SEEK to 50 bytes from end of file on CON prompt the user to skip over the blah, blah, blah and type the last 50 bytes of their input.
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Iadded your comments in the internal report Jim so we'll see what the I/O developers have to say.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Observations from the F2008 standard:
The "processore dependent" behavior does not specifically mention file positioning behavior, except for the POS= specifier. But, note 9.3 states that the set of allowed actions on any external file are processor dependent, so just about any behavior is allowable within the standards.
IMHO, it is OK for any sort of explicit seek (REWIND or POS=) on a non-seekable file to fail. Standard I/O could be conditionally non-seekable, depending if it is a "tty" or a file.
Ideally, there should be a POSITIONABLE= specifier for the INQUIRE statement.
Quetion: Should an explicit REWIND on a non-seekable file that is already at the initial position be an error? Maybe it should just depend on the underlying OS handling of seek. If it is an error, then REWIND with IOSTAT on a freshly opened unit could be used to check postionability.
----
With regards to my "reopen" suggestion, it is already supported. If OPEN defines a file and unit already connected, only the "changeable modes" may be modified:
The "processore dependent" behavior does not specifically mention file positioning behavior, except for the POS= specifier. But, note 9.3 states that the set of allowed actions on any external file are processor dependent, so just about any behavior is allowable within the standards.
IMHO, it is OK for any sort of explicit seek (REWIND or POS=) on a non-seekable file to fail. Standard I/O could be conditionally non-seekable, depending if it is a "tty" or a file.
Ideally, there should be a POSITIONABLE=
Quetion: Should an explicit REWIND on a non-seekable file that is already at the initial position be an error? Maybe it should just depend on the underlying OS handling of seek. If it is an error, then REWIND with IOSTAT on a freshly opened unit could be used to check postionability.
----
With regards to my "reopen" suggestion, it is already supported. If OPEN defines a file and unit already connected, only the "changeable modes" may be modified:
"A connection for formatted input/output has several changeable modes: these are the blank interpretation mode (10.8.6), delimiter mode (10.10.4, 10.11.4.2), sign mode (10.8.4), decimal edit mode (10.8.8), I/O rounding mode (10.7.2.3.7), pad mode (9.6.4.5.3), and scale factor (10.8.5). A connection for unformatted input/output has no changeable modes."
So, my proposal is to extend the set of changeable modes, at least for a file that is connected but has not yet transferred anything.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The I/O issues involving pipes and redirection discussed in this thread are fixed in the Intel Fortran Composer XE 2011 Update 1 release (12.0.1.107 - Linux)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »