Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28440 Discussions

reading stream binary data from stdin: pipes vs redirects ('<')

Izaak_Beekman
New Contributor II
3,160 Views
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:

[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
0 Kudos
24 Replies
jimdempseyatthecove
Honored Contributor III
219 Views
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

0 Kudos
Kevin_D_Intel
Employee
219 Views

Iadded your comments in the internal report Jim so we'll see what the I/O developers have to say.

0 Kudos
joseph-krahn
New Contributor I
219 Views
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:

"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.

0 Kudos
Kevin_D_Intel
Employee
219 Views
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)
0 Kudos
Reply