The meaning of '/' on read (num,'(/)')

Help
#1

Is there anyone here know what is the meaning of (‘/’)?

Thanks in advance

#2

read(num,‘/’) is bad Fortran; read(num,‘(/)’) means skip 2 lines of unit num.
(Thanks to RonShepard for the correction.)

write(unit(‘(A)’) trim(soimething) means write something, omitting trailing blanks.

#3

the ‘/’ format skips two lines, not just one line. One for the read statement, and the second line for the / in the format. You are right, it should be enclosed in parentheses. It should not compile without them.

1 Like
#4

Just a footnote that ‘/’ can take a count and can be used throughout a
format, so it is important to emphasize that a ‘/’ by itself proceeds
to the next line from the current line when encountered in the format,
and a read() defaults to positioning to the next line after the read()
completes. If you know what numbers will be printed and where the file
is positioned at after the read() completes in the example you have it.

Long ago there were arguments about whether any of the format should be
processed after the read was satisfied, so there were actually arguments
about whether things like “read(*,‘(100/)’)” with no list of values to
read should position at line 101 or line 2 when used as the first read().

Compiles varied in particular as to what they did on read() and
write() when the format ended with an X or T descriptor, particularly when
‘advance=“no”’ was involved.

Program

program testit
   read(*,'(i10,5/,i10,3/,i10,/)')i,j,k
   write(*,*)i,j,k
   read(*,*)i
   write(*,*)i
end program testit

Input

1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12

Output

           1           6           9
          11
1 Like
#5

I believe the : descriptor was added in f77 to give the programmer control over this. At least I don’t remember ever using : in formats before f77. The : says to stop processing the format statement if there are no more items in the read/write statement. Without the :, the processing of the format is continued. Something like

read(*,'(i1/)') i

will read the integer, ignore the rest of the line, skip the next line (because of the /), and then leave the file pointer at the beginning of the line after that.

read(*,'(i1:/)') i

would read the integer, ignore the rest of the line, and leave the file pointer at the beginning of the next line.

If advance='no' is specified, then that final line advance (from the read itself) would not occur in either case. This causes some odd things to happen. Consider the following:

read(*,'(i1/)',advance='no') i
write(*,'(i0)') i
read(*,'(i1:/)',advance='no') i
write(*,'(i0)') i
read(*,'(i1)') i
write(*,'(i0)') i
end

with the input

1
2
3
4

The first read statement leaves the file positioned at the beginning of the second line. The second read leaves the file positioned at the end of the second line. I think that third read statement should result in an EOR error, but at least with gfortran it doesn’t. gfortran finds a zero from somewhere and prints it with no error. This is probably some legacy feature where blank fields are treated as zeros in formatted i/o of integers, so to me, the result is a little unexpected.

Finally one other remark. What the programmer often wants to do is to read a value (integer in these examples) with unspecified field width. Not i1 or i10 as in the above examples. On output, as shown in this example, i0 will write an integer in the minimal width (and there are variations on that also for real values), but there is no way to specify something analogous for input. I think the standard should be changed to allow things like i0 on input. The processing should follow more or less the established rules for list-directed input, but for just that one input item, not for the entire record. This would give the programmer a nice mixture of free an fixed format fields to work with within a record, with no character parsing required.

Fortran format descriptors have always been a frustrating mix of flexible power and generality and inflexible restrictions and limitations.

1 Like
#6

Re: third value 0 … Added BLANK=“null” to the READ()s and still got zero with three compilers. Surprises me too.

Some of the arguments were whether T was relative to the beginning of the line (which some compilers implemented by buffering the I/O ) or relative to the current write statement; ie. was nnT referring to column nn or the nth character output by the WRITE() (not an issue before ADVANCE=‘NO’ as each WRITE() created a line); and whether X generated spaces or positioned for the next output, so did
"write(*,‘(10x)’) create a line with at least ten spaces (some machines had fixed record lengths). It was non-intuitive to some that ‘(10x,“A”)’ created 11 characters, but ‘(10x)’ created none, etc.

Unless three compilers have the same bug I need to reREAD something about READ and maybe ADVANCE=‘NO’ regarding why that got a zero.

1 Like