🚀 go-pugleaf

In article <C0CGGB.1tE@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
>In article <1993Jan3.040453.20688@chpc.utexas.edu>, michael@chpc.utexas.edu (Michael Lemke) writes:
>|> I'd rather think the *Unix* stuff should honor
>|>FORTRAN carriage control.  Well, I know it doesn't but a PRINT
>|>statement after all creates a print file (or even sends something to a
>|>printer), so doesn't FORTRAN require print files to honor the carriage
>|>control character?  What is the excuse this time that the Unix joke is
>|>still standard conform?
>
>They have put there a filter called asa, and you just pipe the output
>through it.  But then you will have a bit of a problem for interactive
>programs (buffering will be your enemy!), and also for "batch"
>programs writing on a file if you like to peek at the output while the
>program is running.

Yes, I know that beggar and associated problems.  In my opinion this is
not a solution.  With the same argumentation they could output troff or
TeX or postscript.  Doesn't matter if the filter is called asa or
nroff.  In either case you get a file which does not print propoerly
without further action.  I am still waiting for an explanation if this
Unix behavior is standard conform or not (sorry, I don't have a copy of
the standard to check myself).

>
>|>  BTW, in Sun Fortran there is a special STATUS='PRINT' in
>|>the OPEN statement which causes the first character to be ignored if a
>|>blank or to be converted to a CTRL/L if a 1 etc.  `+' does not work
>|>though. This evne works for stdout but I don't know about PRINT.  Maybe 
>|>your Unix compiler has something similar.
>
>This sounds a neat idea and I wholeheartly suggest that all Unix compiler
>writers put this feature in (hopefully, with the same syntax ...).  
>I only have two questions: how can you OPEN the unit where the PRINTs
>go (usually mapped to the Unix standard output) ?  OPEN(*,) ???
>And, are you sure that the keyword is 'STATUS'? I think that STATUS
>has another meaning associated with it and cannot be overloaded.

Yes, they do overload STATUS and this is why I don't consider it a nice
idea.  Also, I think all files should have this attribute set by
default (see above) and second, I wonder if the standard says anything
about the external (file) representation of the carriage control
character -- does it have to be in the file literally?  If not,
something like the Sun solution would really be an acceptable way to
deal with it under Unix. asa et al. certainly is not.

I don't know right now how you can affect `channel *' or PRINTs.  PRINTs
might have a negative channel number or something else special.  * might
not work at all.

Michael
-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])