Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WAD Escaped "r" dropped

May
3,515
5
I had to update an old batch file to discover this bug, which was introduced in going from version 12 to version 13. In the ECHOS and the ECHOSERR commands using %=r or ^r (assuming caret is the escape character) is supposed to move the cursor back to the left margin, allowing repeated overwriting. Up to V12.11 this worked. Starting with V13 the musical one-eighth note is displayed, which is the original IBM glyph for ASCII 13, the carriage return. I did not check whether or not the other escapable characters function as documented.
 
I had to update an old batch file to discover this bug, which was introduced in going from version 12 to version 13. In the ECHOS and the ECHOSERR commands using %=r or ^r (assuming caret is the escape character) is supposed to move the cursor back to the left margin, allowing repeated overwriting. Up to V12.11 this worked. Starting with V13 the musical one-eighth note is displayed, which is the original IBM glyph for ASCII 13, the carriage return. I did not check whether or not the other escapable characters function as documented.
I tried TCC and TCMD going back to v12. In all cases, "ECHOS 123^r45" produced "453" as expected. What product and what test are you using?
 
I have a batch file which in the file comparison loop has the command:
if %@right[2,%z] EQC 00 echoserr %=r%z files tested
I tried both %=r and ↑r (my EscapeChar). I also tried a blank space after the r. In v12.11 and whatever version was current in July of 2010 the above command displayed identically - overwrote the ECHOSERR line from the left margin. The same file in V13..V16 displays the IBM glyph for the CR instead, and does not move the cursor to the beginning of the line.
NOTE: All tests in TCC windows, not TCMD tabs.
 
Not reproducible here. I'm quite certain this hasn't been broken for four years with nobody noticing!

You probably changed your escape character.
Though I did not change it, but using the symbolic value %= which is and always has been in my batch file should negate that issue anyway.
 
Well, with the barest possible TCC - using /i /l: /d in the minimized example below everything works as expected. Each test performed in a transient shell using start/wait. Now the hard part - putting back each item one-by-one until the issue is found.
@echo off
*on error exit
*on break exit
set zzzz=0
do forever
set /a zzzz+=1
echoserr %=r%zzzz
enddo
 
You’re trying to both colorize STDERR and embed escape characters in the output; that is not possible and has never been possible. Escape sequences work in non-colorized output because the Windows console tty output routines do the appropriate thing when they see a control character. The console output routines used for colored output do not – they’re going to print that character value, period. Some fonts won’t have a CR value, and you’ll get nothing. Some display the musical character. But none will treat it as “go to the beginning of the line”.

To do what you want here will require replacing a couple of the Windows console output routines; that is not going to happen in 16.0. You can add it to the feedback forum for a future version.
 
Thanks!

Apparently the ErrorColors directive is my problem. It turns out that in V9 through V12 I had "default" colors; since V13 I had selected red on white.

Two things confused me. When years back the ErrorColors directive and its OPTION dialog version were introduced, I don't recall any mention that one has a choice between EITHER colored error foreground/background OR using ASCII format effectors. The other confusion was that Output and Input Foreground and Background seem to work fine with all ASCII, including format effectors, but Error Foreground does not.

I changed ECHOERR and ECHOSERR to ECHO and ECHOS, resp., and this fixed my batch file. Removing the ErrorColors directive instead also works.
 
Colorizing stdout is completely different than colorizing stderr. For stdout, TCC simply sets the default console colors, and then writes everything as tty. For stderr, TCC has to intercept the write and rewrite it with one of the console output routines that supports colors (and not control characters).
 
Back
Top