Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ANSI escape sequences in gfortran
254 views
Skip to first unread message
Dave Tholen
Feb 2, 2021, 4:29:44 AM2/2/21
to
In more recent versions of Windows 10, the Command Prompt has been enhanced to
understand ANSI escape sequences. Indeed, I've seen the gfortran compiler,
as installed by equation.com's Windows installer, change the foreground and
background colors of the command prompt window when it generates error
messages. I wrote a little program to try it out, but it failed to do what
I expected it to do. I googled the issue, and ran across a little test
program that also failed to do what I expected.
My test program:
PROGRAM TestColor
WRITE (6,'(A)') 'Hello'//CHAR(27)//'[38;2;255;255;255m' ! set foreground color to bright white
WRITE (6,'(A)') CHAR(27)//'[48;2;128;0;0m'//'World' ! set background color to dark red
END PROGRAM TestColor
produces the output:
Hello←[38;2;255;255;255m
←[48;2;128;0;0mWorld
with no change in colors. [N.B. Windows has its own "Color" program, which
I discovered the hard way when I just happened to use the same name for my
test program, and it behaved nothing like what I written, until I invoked it
with .\Color to avoid getting the built-in command. I changed the program
name above because of this.]
While writing the test program, I wondered if the first character in the
output stream would get stripped away as a carriage control character, but
the test program demonstrates that it wasn't getting stripped away, and
adding 1X to the format didn't make any difference either. It's been so
long since I've used carriage control that I had almost forgotten about it!
The test program I found from the google search:
program main
implicit none
character(len=*), parameter :: ESC = achar(27)
write (*, '(a)', advance='no') ESC // '[2J' ! Move cursor to top left.
write (*, '(a)', advance='no') ESC // '[44;1m' // ESC // '[38;5;200mThis text is colourised.'
write (*, '(a)') ESC // '[0m' ! Reset colours.
end program main
generated the output:
←[2J←[44;1m←[38;5;200mThis text is colourised.←[0m
No change in colors.
So I don't think it's a misunderstanding on my part of how to incorporate
escape sequences into the source code. Neither my own test program or
someone else's test program works as expected. Can somebody explain why,
and how to coax it into working?
On a completely different matter, I have another program that is signalling
IEEE_UNDERFLOW_FLAG after completion. I don't think it's a problem (the results
seem fine), but would still like to find out which statement is triggering the flag.
Looking over the various compiler options, it's not obvious to me which one might
cause the program to stop execution when it happens and inform me of the source
code line that caused the underflow. Nor it is obvious whether I would need to
recompile every single subroutine in the library with the same compiler option
to produce an executable that would crash when the error occurs. I'm pretty sure
that I can narrow down the triggering code to one of two subroutines, because I've
never seen the flag when I don't use the option that calls one particular subroutine
(which in turns calls the second subroutine). Would appreciate a recommendation on
how to proceed, otherwise I'll have to take the experimental approach.
understand ANSI escape sequences. Indeed, I've seen the gfortran compiler,
as installed by equation.com's Windows installer, change the foreground and
background colors of the command prompt window when it generates error
messages. I wrote a little program to try it out, but it failed to do what
I expected it to do. I googled the issue, and ran across a little test
program that also failed to do what I expected.
My test program:
PROGRAM TestColor
WRITE (6,'(A)') 'Hello'//CHAR(27)//'[38;2;255;255;255m' ! set foreground color to bright white
WRITE (6,'(A)') CHAR(27)//'[48;2;128;0;0m'//'World' ! set background color to dark red
END PROGRAM TestColor
produces the output:
Hello←[38;2;255;255;255m
←[48;2;128;0;0mWorld
with no change in colors. [N.B. Windows has its own "Color" program, which
I discovered the hard way when I just happened to use the same name for my
test program, and it behaved nothing like what I written, until I invoked it
with .\Color to avoid getting the built-in command. I changed the program
name above because of this.]
While writing the test program, I wondered if the first character in the
output stream would get stripped away as a carriage control character, but
the test program demonstrates that it wasn't getting stripped away, and
adding 1X to the format didn't make any difference either. It's been so
long since I've used carriage control that I had almost forgotten about it!
The test program I found from the google search:
program main
implicit none
character(len=*), parameter :: ESC = achar(27)
write (*, '(a)', advance='no') ESC // '[2J' ! Move cursor to top left.
write (*, '(a)', advance='no') ESC // '[44;1m' // ESC // '[38;5;200mThis text is colourised.'
write (*, '(a)') ESC // '[0m' ! Reset colours.
end program main
generated the output:
←[2J←[44;1m←[38;5;200mThis text is colourised.←[0m
No change in colors.
So I don't think it's a misunderstanding on my part of how to incorporate
escape sequences into the source code. Neither my own test program or
someone else's test program works as expected. Can somebody explain why,
and how to coax it into working?
On a completely different matter, I have another program that is signalling
IEEE_UNDERFLOW_FLAG after completion. I don't think it's a problem (the results
seem fine), but would still like to find out which statement is triggering the flag.
Looking over the various compiler options, it's not obvious to me which one might
cause the program to stop execution when it happens and inform me of the source
code line that caused the underflow. Nor it is obvious whether I would need to
recompile every single subroutine in the library with the same compiler option
to produce an executable that would crash when the error occurs. I'm pretty sure
that I can narrow down the triggering code to one of two subroutines, because I've
never seen the flag when I don't use the option that calls one particular subroutine
(which in turns calls the second subroutine). Would appreciate a recommendation on
how to proceed, otherwise I'll have to take the experimental approach.
Cyrmag
Feb 2, 2021, 5:51:34 AM2/2/21
to
On 2/2/2021 3:29 AM, Dave Tholen wrote:
> In more recent versions of Windows 10, the Command Prompt has been
> enhanced to
> understand ANSI escape sequences. Indeed, I've seen the gfortran compiler,
> as installed by equation.com's Windows installer, change the foreground and
> background colors of the command prompt window when it generates error
> messages. I wrote a little program to try it out, but it failed to do what
> I expected it to do. I googled the issue, and ran across a little test
> program that also failed to do what I expected.
>
> In more recent versions of Windows 10, the Command Prompt has been
> enhanced to
> understand ANSI escape sequences. Indeed, I've seen the gfortran compiler,
> as installed by equation.com's Windows installer, change the foreground and
> background colors of the command prompt window when it generates error
> messages. I wrote a little program to try it out, but it failed to do what
> I expected it to do. I googled the issue, and ran across a little test
> program that also failed to do what I expected.
>
> While writing the test program, I wondered if the first character in the
> output stream would get stripped away as a carriage control character, but
> the test program demonstrates that it wasn't getting stripped away, and
> adding 1X to the format didn't make any difference either. It's been so
> long since I've used carriage control that I had almost forgotten about it!
> <---CUT--->
> output stream would get stripped away as a carriage control character, but
> the test program demonstrates that it wasn't getting stripped away, and
> adding 1X to the format didn't make any difference either. It's been so
> long since I've used carriage control that I had almost forgotten about it!
You have to call an API function, or set a registry variable prior to
starting CMD.EXE. For details, see:
https://devblogs.microsoft.com/commandline/understanding-windows-console-host-settings/
In short, you can do the following, if you are comfortable using Regedit
or an equivalent. In HKCU\Console create a DWORD named
VirtualTerminalLevel and set it to 0x1; then restart cmd.exe.
- Cyrmag
Dave Tholen
Feb 3, 2021, 4:45:14 PM2/3/21
to
>> In more recent versions of Windows 10, the Command Prompt has been enhanced to
>> understand ANSI escape sequences. Indeed, I've seen the gfortran compiler,
>> as installed by equation.com's Windows installer, change the foreground and
>> background colors of the command prompt window when it generates error
>> messages. I wrote a little program to try it out, but it failed to do what
>> I expected it to do. I googled the issue, and ran across a little test
>> program that also failed to do what I expected.
>>
>> While writing the test program, I wondered if the first character in the
>> output stream would get stripped away as a carriage control character, but
>> the test program demonstrates that it wasn't getting stripped away, and
>> adding 1X to the format didn't make any difference either. It's been so
>> long since I've used carriage control that I had almost forgotten about it!
>> understand ANSI escape sequences. Indeed, I've seen the gfortran compiler,
>> as installed by equation.com's Windows installer, change the foreground and
>> background colors of the command prompt window when it generates error
>> messages. I wrote a little program to try it out, but it failed to do what
>> I expected it to do. I googled the issue, and ran across a little test
>> program that also failed to do what I expected.
>>
>> While writing the test program, I wondered if the first character in the
>> output stream would get stripped away as a carriage control character, but
>> the test program demonstrates that it wasn't getting stripped away, and
>> adding 1X to the format didn't make any difference either. It's been so
>> long since I've used carriage control that I had almost forgotten about it!
> You have to call an API function, or set a registry variable prior to starting CMD.EXE. For details, see:
>
> https://devblogs.microsoft.com/commandline/understanding-windows-console-host-settings/
Interesting article. The full list of every setting for Windows Console doesn't
>
> https://devblogs.microsoft.com/commandline/understanding-windows-console-host-settings/
indicate what the range of possible values for VirtualTerminalLevel can be,
however, so your value of 1 below was a crucial bit of information.
> In short, you can do the following, if you are comfortable using Regedit or an equivalent. In HKCU\Console create a DWORD named
> VirtualTerminalLevel and set it to 0x1; then restart cmd.exe.
not implement color control via ANSI escape sequences, because it worked just
fine without this registry entry. Also, the gfortran error messages managed
to change the colors as well without this registry entry. Must be calling the
API function.
That article describes the hierarchy of loaded settings, which might explain
some other issues I've encountered with Command Prompt. When you pin the
"Command Prompt" from Start --> Windows System to the Start menu, is that the
equivalent of creating a shortcut? Because I've seen different behavior from
a command prompt started from the Start menu tile in comparison to one started
with (right click) Start --> Run --> cmd. In particular, launching the Brief
editor from a Command Prompt will sometimes cause the command prompt window to
completely disappear, leaving the editor running as a zombie background process
and chewing up one thread (13 percent CPU usage on a four-core eight-thread
processor). I say "sometimes", because I've never seen it happen when the
editor is the first thing run from a freshly launched Command Prompt. It also
doesn't happen if I change the buffer to same size as the window (no vertical
scroll bar), and I have yet to see it happen when the command prompt is
started via Run --> cmd /k. I've also had PowerShell disappear after launching
the Brief editor. What I don't understand is why these disappearing acts are
far more common on one Windows 10 machine than on another Windows 10 machine.
I suspect it has something to do with the dimensions of the command prompt
window and the size of the buffer. Or that hierarchy of console settings.
Would the ANSI escape sequences also work if I created a VirtualTerminalLevel
DWORD with a value of 1 in HKCU\Software\Microsoft\Command Processor? Unclear
to me what settings go into "Console" versus "Command Processor".
dpb
Feb 3, 2021, 5:42:37 PM2/3/21
to
On 2/3/2021 3:45 PM, Dave Tholen wrote:
...
> That article describes the hierarchy of loaded settings, which might explain
> some other issues I've encountered with Command Prompt. When you pin the
> "Command Prompt" from Start --> Windows System to the Start menu, is that the
> equivalent of creating a shortcut? Because I've seen different behavior from
> a command prompt started from the Start menu tile in comparison to one started
> with (right click) Start --> Run --> cmd. In particular, launching the Brief
> editor from a Command Prompt will sometimes cause the command prompt window to
> completely disappear, leaving the editor running as a zombie background process
...
I know nuthink! of the questions but am most interested to know which
implementation of the Brief editor you're running? I miss it terribly
altho I have a freeware Windows workalike (in most ways, but not all
including no macro language that is a kick on customized compiler
settings/language support).
It also is only a single file buffer in the freeware version and the one
that is supposed to support multiple buffers still has no macros and is
extremely expensive.
--
...
> That article describes the hierarchy of loaded settings, which might explain
> some other issues I've encountered with Command Prompt. When you pin the
> "Command Prompt" from Start --> Windows System to the Start menu, is that the
> equivalent of creating a shortcut? Because I've seen different behavior from
> a command prompt started from the Start menu tile in comparison to one started
> with (right click) Start --> Run --> cmd. In particular, launching the Brief
> editor from a Command Prompt will sometimes cause the command prompt window to
> completely disappear, leaving the editor running as a zombie background process
I know nuthink! of the questions but am most interested to know which
implementation of the Brief editor you're running? I miss it terribly
altho I have a freeware Windows workalike (in most ways, but not all
including no macro language that is a kick on customized compiler
settings/language support).
It also is only a single file buffer in the freeware version and the one
that is supposed to support multiple buffers still has no macros and is
extremely expensive.
--
Dave Tholen
Feb 4, 2021, 2:46:44 PM2/4/21
to
> but am most interested to know which implementation of the Brief editor you're running?
www.briefeditor.com version 4.50 basic
> I miss it terribly altho I have a freeware Windows workalike (in most ways, but
> not all including no macro language that is a kick on customized compiler
> settings/language support).
>
> It also is only a single file buffer in the freeware version and the one that is
> supposed to support multiple buffers still has no macros and is extremely expensive.
implemented key mapping to emulate BRIEF, including RimStar. RimStar eventually
came out with a Windows version, but it has since disappeared from the market, and
I've not found anybody selling their copy.
dpb
Feb 5, 2021, 3:38:46 PM2/5/21
to
On 2/4/2021 1:46 PM, Dave Tholen wrote:
>> but am most interested to know which implementation of the Brief
>> editor you're running?
>
> www.briefeditor.com version 4.50 basic
OK, that's the version I was speaking of, thought (was hoping) maybe was
>> but am most interested to know which implementation of the Brief
>> editor you're running?
>
> www.briefeditor.com version 4.50 basic
another out there wasn't aware of. If it weren't $300 for the other
version I've probably spring for it, but as it is w/o the macro language
it just isn't worth that much out of pocket having retired from ...
> The original BRIEF on OS/2 was superb. That's probably why so many
> other editors
> implemented key mapping to emulate BRIEF, including RimStar. RimStar
> eventually
> came out with a Windows version, but it has since disappeared from the
> market, and
> I've not found anybody selling their copy.
to be a nearly identical keybinding and (I think) does include scripting
iiuc although I've not used it yet extensively.
It has extensions like language templates; not sure exactly how they're
implemented; whether follow the original as the compiled macro or not.
It also includes automagic color-encoding that the original didn't have.
I think it's definitely worth a look; if I were actively coding I
suspect it is what I would be using; I'm most just playing in MATLAB at
their user support forum these days instead of Fortran.
And for an IDE environment that supports Brief key mappings, look at
ZEUS <https://www.zeusedit.com/index.html> altho it's not all that
expensive, <$100 USD for a nonexpiring license with like a 60-day trial
period before you have to purchase. I let the trial expire, but thought
it a decent product.
There is a free subset of the IDE that apparently is just the editor I
just now see; wasn't aware of that before
<https://www.zeusedit.com/lite/index.html>
--
Jeff Ryman
Feb 7, 2021, 4:12:38 PM2/7/21
to
dpb
Feb 8, 2021, 8:23:40 AM2/8/21
to
On 2/7/2021 3:12 PM, Jeff Ryman wrote:
> On Friday, February 5, 2021 at 12:38:46 PM UTC-8, dpb wrote:
>> On 2/4/2021 1:46 PM, Dave Tholen wrote:
>>>> but am most interested to know which implementation of the Brief
>>>> editor you're running?
>>>
>>> www.briefeditor.com version 4.50 basic
>> OK, that's the version I was speaking of, thought (was hoping) maybe was
>> another out there wasn't aware of. If it weren't $300 for the other
>> version I've probably spring for it, but as it is w/o the macro language
>> it just isn't worth that much out of pocket having retired from ...
...
> On Friday, February 5, 2021 at 12:38:46 PM UTC-8, dpb wrote:
>> On 2/4/2021 1:46 PM, Dave Tholen wrote:
>>>> but am most interested to know which implementation of the Brief
>>>> editor you're running?
>>>
>>> www.briefeditor.com version 4.50 basic
>> OK, that's the version I was speaking of, thought (was hoping) maybe was
>> another out there wasn't aware of. If it weren't $300 for the other
>> version I've probably spring for it, but as it is w/o the macro language
>> it just isn't worth that much out of pocket having retired from ...
>>
>> There is a free subset of the IDE that apparently is just the editor I
>> just now see; wasn't aware of that before
>> <https://www.zeusedit.com/lite/index.html>
>>
>> --
> At the Brief web site, the Brief Professional version is offered for $120. See http://www.briefeditor.com/download.htm .
Ah! I overlooked the pricing -- that's a significant reduction from
>> There is a free subset of the IDE that apparently is just the editor I
>> just now see; wasn't aware of that before
>> <https://www.zeusedit.com/lite/index.html>
>>
>> --
> At the Brief web site, the Brief Professional version is offered for $120. See http://www.briefeditor.com/download.htm .
when last had looked...and worth at least consideration.
Still, w/o the macro language to implement the language templates
amongst other things it's still a limited implementation and I'd
probably move to one of the above alternatives if still coding "in anger".
The freeware version was perfect for some work just completed of using
it being driven by a COM process to clean up comments in a series of
complicated spreadsheets since it use the system clipboard for its
cut/paste function under Windows and its small footprint is a real
advantage.
--
0 new messages