Prev: Fortran 95 equivalent of read(..., POS=...)
Next: Output units nowadays
From: Richard Maine on 30 Mar 2010 20:11
Steve Lionel <steve.lionel(a)intel.invalid> wrote:

> On 3/29/2010 7:01 PM, Richard Maine wrote:
> > Intel's compilers come from a line that historically processed standard
> > output to make it emulate asa printer behavior. I believe there is a way
> > to turn that processing off, but I don't know the details.
>
> As was noted later, the Intel compiler default is to NOT treat column 1
> as indicating carriage control. If you have enabled the PowerStation
> compatibility options, "Fortran carriage control" is enabled, and you
> can ask for it (or disable it) with an OPEN keyword.

Ah. Sorry if I got that part confused. I was thinking the default was
the other way, but I was pretty sure there was at least an option to
keep the compiler from "mucking" with column 1. Glad to know that the
option is actually the default. That makes it easier.

For those who need a PowerStation compatibility option, well...
obviously those users must not be much into portability. Presumably they
get what they ask for (in whatever way one wants to interpret that.)

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: John on 30 Mar 2010 21:15
On Mar 29, 7:01 pm, nos...(a)see.signature (Richard Maine) wrote:
> Luka Djigas <ldigas@___gmail___.com> wrote:
> > Simple question really; is there an option which disables command
> > characters actions (1,0,+ or blank in column 1) in either Intel's or
> > gfortran's line of compilers ?
>
> Many modern compilers don't do anything about them in the first place.
> They were more descriptions of how one class of printers worked than of
> something that a compiler was particularly expected to do. Most printers
> today don't work like that. (Some do, but most don't). Typically, if you
> want the carriage control characters to work on most of today's
> printers, you process the output with a sparate program (such as the asa
> program).
>
> I believe that's the case with gfortran. I suppose I could be wrong, but
> I doubt there is a way to make gfortran do anything about carriage
> control, so if you want it off, there is nothing to do.
>
> Intel's compilers come from a line that historically processed standard
> output to make it emulate asa printer behavior. I believe there is a way
> to turn that processing off, but I don't know the details.
>
> Note that it only applied to standard output. If you open any other
> file, you shouldn't get carriage control interpretation unless you go
> out of your way to ask for it (which might be possible).
>
> > If I understood correctly, they're deleted out of f2003 (or have I misread ?).
>
> Yes, they are gone. In a way, they were never in the standard. Yes,
> there were words in the standard about it, but those words were pretty
> much without substantive content. I will give my version below. These
> are my words rather than the standard's, but I claim that they are
> equivalent, if a bit more verbose and... um... informal. :-)
>
> "Some printers might act like this. (Insert the details here). Others
> might not. It doesn't hecessarily have anything to do with Fortran, as
> the printers might act that way for files created by any language. We
> just thought it might be useful to remind you of it in the Fortran
> standard for some reason. Not that we are going to tell you comparable
> things about any other output devices.
>
> The Fortran standard doesn't specify what files, if any, this stuff will
> happen to. Nor does it provide a way for you to control it, or even
> inquire about it. Hope this is helpful.
>
> Completely unrelated things might happen instead. Heck, the printer
> might do something like interpret data sent to it as Postscript. But
> this margin is too small to describe Postscript in, so we won't. Besides
> which, Postscript didn't exist when we wrote the first version of this.
>
> And all this stuff might have happened if we hadn't said anything about
> it. If some future committee deletes all this from the standard, the
> same things might continue to happen.
>
> Don't ask me why we even bothered to mention this is the Fortran
> standard in the first place. Maybe someone said they would vote 'no'
> unless this was in. Seemed harmless enough as it has no effect."
>
> --
> Richard Maine                    | Good judgment comes from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle           |  -- Mark Twain

That is the most honest interpretation of a standard I've read in
quite some time.
I'm still chuckling.

In other places in this thread I get the idea some people
don't know how nearly universal the use of ASA carriage control was
(especially on "record-based" systems, as opposed to
"stream-based".); nor how many large installations
still use ASA carriage control, albeit less and less. You may note
that a good number of commercial applications
still keep column 1 "clear" no matter what language they are written
in, because many
non-Unix/GNU-Linux systems still treat column 1 as special.

Our last major use of ASA carriage control was probably for
COM (ie. "microfiche") output; but we have many codes dating back
decades that can still
generate ASA carriage control. Why? There really isn't any better way
to generate plain ASCII
files that are easily manipulated with standard Unix utilities that,
when printed, put page
breaks where you want them. And odd habits developed over the years,
like printing almost
nothing but data values on "plain" lines; so you could easily extract
just the numbers
from a file and remove all the superfluous information by just
ignoring lines beginning
with anything other than a space and so on(ie. "grep -v '^[+01']'").
And embedding machine code characters in a file has it's own
set of issues. Although we use HTML and XML more nowadays for such
things(it also CAN be simple text that is easily
used with the many ASCII-based Unix commands, but can be beautifully
formatted with CSS for printing) we still find ASA carriage control
handy. Not great,
not overwhelmingly important, but better than nothing. And large sites
with printers capable of printer-generated
forms still use ASA channel control for placing data at specific
locations(there was more to it than "+10 "; which can be very
efficient.
I find a number of people using asa2pdf (http://home.comcast.net/
~urbanjost/CLONE/ASA/asa_carriage_control.html).
So, I still keep column 1 clear; even though I rarely print ASCII
output now-adays.

PS:
asa2pdf(1) converts a file with ASA carriage control to a clear-text
Adobe PDF file. Think of it as a "super-asa(1)"
command. And a good number of Fortran compilers still come with asa(1)/
nasa(1) or fpr(1); which can convert to
or between ASA and "machine" carriage control. The last time I updated
asa2pdf(1) was probably five years ago, and it was
a bit of a "quick hack", but it still gets used. It's in C, I'm
afraid.

From: Clive Page on 31 Mar 2010 07:43
In message <1jg4gps.1io1gie1cpyh54N%nospam(a)see.signature>, Richard Maine
<nospam(a)see.signature> writes
>Don't ask me why we even bothered to mention this is the Fortran
>standard in the first place. Maybe someone said they would vote 'no'
>unless this was in. Seemed harmless enough as it has no effect."

I don't agree that it's entirely harmless. The harmful legacy is that
list-directed output (and NAMELIST which uses the same rules) outputs a
space as the first character of every line, just to avoid the awful
possibility that the output stream is being treated as a "printer". This
is, to me, really annoying as it means that I often have to construct a
real format string when otherwise a list-directed write would be fine.


--
Clive Page
First  |  Prev  | 
Pages: 1 2 3
Prev: Fortran 95 equivalent of read(..., POS=...)
Next: Output units nowadays