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

Printing longer than 80-column lines to DOS window

vahrazj
Beginner
3,013 Views
Hi there,

This is really frustrating. I am trying to write a line to the DOS window which is longer than 80 columns long. No matter what I do it wraps around at 80 columns. I change the layout properties of the DOS command window so that it is 132 columns. The window becomes wider, but running the Fortran program, the output line still wraps around at 80 columns on the screen. What is the problem? and how to solve it? I really appreciate it.

Very Frustrated
0 Kudos
12 Replies
Steven_L_Intel1
Employee
3,013 Views
My guess is that you're using list-directed formatting. This wraps at column 80. You can change that by opening unit 6 with RECL=132 (or whatever you want) and doing the output to unit 6. Or use explicit formatted I/O which does not wrap.
0 Kudos
vahrazj
Beginner
3,013 Views
Thanks Steve,

You are absolutely right. I was using
write(6,*) 'longer than 80 columns text'
format which on screen wraps at 80. But by using
write(6,'(1x,A)') '...' I got around the problem. But do you know why list-directed format is limited to 80? Is there a way to change the default for it? Thanks. I really appreciate your response.

Vahrazj
0 Kudos
Steven_L_Intel1
Employee
3,013 Views
List-directed output is designed for human readability, and traditionally, output terminals have been 80 columns (and that's still the default for console windows). As I mentioned, opening the unit with an explicit RECL will change the wrap width for list-directed. In a future update, we plan to support an environment variable that will change the default for all units.
0 Kudos
skuitti
Beginner
3,013 Views

For printing more columns in DOS window you should adjust your DOS box. Windows 2000/XP allow set up as many columns/rows in the DOS window as you want. But you can have some problems in the fullscreen DOS session.

If you want to print reports on the printer which have more than 80 columns you should use escape sequences which allow print in condensed mode.

Also you can use special utilitie http://www.dosprn.comwhich can print DOS reports with specified font size.

0 Kudos
marshall-l-buhl
Beginner
3,013 Views
Steve,

I can't seem to get that to work. I'm using IVF v9.1.3250.2003. Here is my test program:

------------------------------------------------------------
program T_ListDirRecL

implicit none
integer :: i,j

OPEN ( 6, FILE='CON', STATUS='UNKNOWN', RECL=100 )

print '(100a)', ' ', ( ' ',char(48+i) , i=1,9 )
print '(100a)', ( ( char(j+48), j=0,9 ), i=0,9 )
print *, ' '
print *, ' ', ( ' ',char(48+i) , i=1,9 )
print *, ( ( char(j+48), j=0,9 ), i=0,9 )

stop
end program T_ListDirRecL
------------------------------------------------------------

The formatted prints work just fine, but the list directed ones wrap at column 79 (that's where that last character occurs). If I set RECL=10, I get the exact same output. It appears to me the RECL parameter is ignored for list-directed output. Is there some switch I need to set to tell the compiler to honor my RECL setting? The use or non-use of /assume:byterecl seems to have no effect either.

I had been cursing this lack of control all week when a coworker walked in and asked if the 80-column limit could be eliminated, so I decided I'd try here.


Marshall
0 Kudos
Steven_L_Intel1
Employee
3,013 Views
You opened unit 6 but used PRINT - those are not the same in our implementation at this time. Use WRITE (6,*) and it should work.
0 Kudos
marshall-l-buhl
Beginner
3,013 Views
Oh, I had tried that too and it didn't work either. For example:

OPEN ( 6, FILE='CON', STATUS='UNKNOWN', RECL=100 )
write(6,*) ( ( char(j+48), j=0,9 ), i=0,9 )

It gives the exact same output as a PRINT *. Try it!

Marshall
0 Kudos
Steven_L_Intel1
Employee
3,013 Views
Curious. If I open a file instead, then the RECL is honored. Something odd about the terminal. I'll check into this.
0 Kudos
marshall-l-buhl
Beginner
3,013 Views
Lionel,

Thanks for trying it. Should I open a new issue? This is really annoying.

Marshall
0 Kudos
Steven_L_Intel1
Employee
3,013 Views
Yes, please do and ask that it be assigned to Steve Lionel.
0 Kudos
drgfthomas
Beginner
3,013 Views

Here's how it works for me: in Win API speak,

!use whichever of these modsare appropriate

use dfwin
use user32
use dfwinty
use kernel32

type(T_COORD) ScrSize
type(T_CONSOLE_SCREEN_BUFFER_INFO) ScrBuff

AllocConsole

GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), ScrBuff)

ScrSize.X = 2*ScrBuff.dwMaximumWindowSize.X !Default is 80

ScrSize.Y = 100*ScrBuff.dwMaximumWindowSize.Y !Default is 25

Maximize the console window when it appears. It should be big enough.

PS

Oh, I forgot:

SetConsoleScreenBufferSize(GetStdHandle(STD_OUTPUT_HANDLE,ScrSize)

0 Kudos
Steven_L_Intel1
Employee
3,013 Views
vahrazj's problem is that if one tries to open unit 6 with a different RECL, and where it is effectively the same file, then the RTL treats this as "open on a connected unit" and does not change the RECL. This is a bug - unit 6 is preconnected but is not OPEN initially.

A workaround is to use some other unit such as 8.
0 Kudos
Reply