🚀 go-pugleaf

On Tue, 5 Jan 93 06:19:34 GMT, michael@chpc.utexas.edu (Michael Lemke) said:

         [... about carriage control interpretation...]

Michael> In either case you get a file which does not print propoerly
Michael> without further action.  I am still waiting for an
Michael> explanation if this Unix behavior is standard conform or not
Michael> (sorry, I don't have a copy of the standard to check myself).

ISO/IEC 1551:1991 (aka Fortran 90):

  9.4.5 Printing of Formatted Records.  The transfer of information in a
  formatted record to certain devices determined by the processor is called
  printing.  If a formatted record is printed, the first character of the
  record is not printed. ....

  The PRINT statement does not imply that printing will occur and the
  WRITE statement does not imply that printing will not occur.

The same identical words appear in the f77 standard, section 12.9.5.2.3.

As with most issues relating to specific hardware (in this case a
"printer"), the language standard avoids any attempt to define hardware
characteristics.  This leaves the processor with quite a bit of
latitude in determining what devices are "printers" and how the
"transfer of information" to these devices is accomplished.  It would
be perfectly valid for a processor to say that it has no "printers";
indeed there are plenty of processors that don't have anything I'd
call a printer.  It would also be valid for a processor to consider
an interactive display screen to be a printer.  Also, it is valid for
the "transfer of information" to the printer to involve running
asa, nroff, whatever.  The Fortran standard certainly doesn't address
such operating-system-dependent issues as whether you print a file by
using the lpr command or whether you use a rodent to drag a file icon
onto a printer icon.  Compared to this kind of difference, the distinction
between using the lpr or asa commands is pretty trivial.

No I'm not particularly pleased with the resulting portability problems.
But the standard is pretty explicit and is generally given more weight
than my personal preferences. :-)  I'd have preferred some way of specifying
in the open statement whether the file was to have carriage control
interpretation.  Some systems have something like that, but the standard
doesn't.

In my personal coding, I long ago gave up using any carriage control
characters except for blank.  If I want to skip a line, I just print
a blank line.  Overprinting doesn't work on too many devices anyway
(notably terminal screens, which are sometimes considered "printers").
I regretfully avoid top-of-page actions in most places, and when I
do need it I make a small system-dependent subroutine for it so that
I can change it as needed (sometimes writing a control-L, or whatever).

I put the blank carriage control on all files destined for human
consumption (i.e. printing or displaying on a screen).  That way, if
the carriage control does get interpreted, I'm fine.  If the
carriage control just gets displayed, the only effect is that everything
is shifted over one character to the right, which is seldom a big deal.
On formatted files meant for data transfer to another program, I can't
be quite so cavalier about whether the file is or isn't shifted over
a character.  However, I haven't generally noticed systems trying
to interpret carriage control characters on formatted files opened with
standard default characteristics that aren't sent to some "device".

Michael> I don't know right now how you can affect `channel *' or PRINTs.

You can't in any portable way.  That's why I don't use them in
substantial programs.  I will admit to using writes to unit "*" for
"quickies" and for temporary diagnostics because it is so easy, but
for big programs, I always use a unit number.  Even though the right
number may be system dependent and may require a special open, that's
a simple, easily isolated system dependency (of course, you use a
parameter or variable instead of hardwiring a unit number in every
write statement).

--
--
Richard Maine
maine@altair.dfrf.nasa.gov