Welcome!

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

SignUp Now!

Corruption in TCMD tab window

May
12,845
164
The last command in TCC's history is

Code:
v:\> PDir z:\Windows\winsxs\* /A-D /S /(-128.182fn zc dy/m/d th:m:s fp) | d:\Gnu\sort.exe

Recalled in a console window, it's wrapped right after the 'u' in "gnu". If I start TCMD (13/TCC 13) and press [Up] the command appears wrapped, as above, even though there are 10 (or so) spaces left on the first line. [Esc] doesn't erase the wrapped part.

That does not happen in an identically-sized TCMD12.
 
The last command in TCC's history is

Code:
v:\> PDir z:\Windows\winsxs\* /A-D /S /(-128.182fn zc dy/m/d th:m:s fp) | d:\Gnu\sort.exe
Recalled in a console window, it's wrapped right after the 'u' in "gnu". If I start TCMD (13/TCC 13) and press [Up] the command appears wrapped, as above, even though there are 10 (or so) spaces left on the first line. [Esc] doesn't erase the wrapped part.

That does not happen in an identically-sized TCMD12.

This seems to be edgy in that it only happens when the most recent command in TCC's history wraps (any command will do) and the first thing you do after starting TCMD is Up-arrow. It doesn't happen on subsequent recalls, not even if you don't execute it (Up-arrow ... Esc ... Enter ... Up-arrow).
 
This seems to be edgy in that it only happens when the most recent command in TCC's history wraps (any command will do) and the first thing you do after starting TCMD is Up-arrow. It doesn't happen on subsequent recalls, not even if you don't execute it (Up-arrow ... Esc ... Enter ... Up-arrow).

I still didn't get it exactly. The command doesn't have to be at the end of the history. The corruption is observed as long as you up-arrow to a console-wrapped command before [Enter] is pressed in any new tab.
 
I can reliably reproduce the (or a similar) issue with this sequence:

.) Start tcmd with brand new, no history tcc tab
.) Size the tcmd window so a long command will not wrap
.) Get a long command into the history (Normally or with ^k)
.) Size the tcmd box so the command will wrap
.) Press up-arrow. The command does not wrap to the next line. The end of
the line gets overwritten.
.) Press esc
.) Press up-arrow. The command does wrap properly.
.) Press esc
.) Size the tcmd window so the command will not wrap
.) Press up-arrow. The command wraps, in spite of room

However, the problem goes away after the esc, and it does the same thing in
12, for me.


On Sun, Oct 2, 2011 at 21:37, vefatica <> wrote:


> ---Quote (Originally by vefatica)---
> This seems to be edgy in that it only happens when the most recent command
> in TCC's history wraps (any command will do) and the first thing you do
> after starting TCMD is Up-arrow. It doesn't happen on subsequent recalls,
> not even if you don't execute it (Up-arrow ... Esc ... Enter ... Up-arrow).
> ---End Quote---
> I still didn't get it exactly. The command doesn't have to be at the end
> of the history. The corruption is observed as long as you up-arrow to a
> console-wrapped command before [Enter] is pressed in any new tab.
>
>
>
>
>



--
Jim Cook
2011 Monday: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Tuesday.
 
I can reliably reproduce the (or a similar) issue with this sequence:

.) Start tcmd with brand new, no history tcc tab
.) Size the tcmd window so a long command will not wrap
.) Get a long command into the history (Normally or with ^k)
.) Size the tcmd box so the command will wrap
.) Press up-arrow. The command does not wrap to the next line. The end of
the line gets overwritten.
.) Press esc
.) Press up-arrow. The command does wrap properly.
.) Press esc
.) Size the tcmd window so the command will not wrap
.) Press up-arrow. The command wraps, in spite of room

However, the problem goes away after the esc, and it does the same thing in 12, for me.

WAD -- this is old, old, old behavior going back 20+ years. It's been brought up several times since then, and after explanations the users have always decided to keep it the way it is.

TCC checks its screen size before each character is entered. The problem in your example is that TCC is waiting for a Windows API to return a keystroke when you change the window size. So TCC doesn't recognize the new size until after it's processed the current keystroke.

Earlier trials that checked the window size, checked for a keystroke without waiting and looped back to check the window sized again always foundered due to either excessive overhead or slow response time to keyboard input. I might revisit this now that most people are running (much) faster systems. But IMHO it doesn't merit being put at the top of the new feature list.
 
I thought the behavior was acceptable, actually. I've been annoyed by it, but since ESC, Enter has always cleared the state, I always felt this was more in the lines of "I've done something silly, and a silly result happened" and it didn't seem worth complaining about.Vince's problem may be different.-- Sent from my HP TouchPadOn Oct 3, 2011 8:36, rconn <> wrote: ---Quote (Originally by Jim Cook)---
I can reliably reproduce the (or a similar) issue with this sequence:

.) Start tcmd with brand new, no history tcc tab
.) Size the tcmd window so a long command will not wrap
.) Get a long command into the history (Normally or with ^k)
.) Size the tcmd box so the command will wrap
.) Press up-arrow. The command does not wrap to the next line. The end of
the line gets overwritten.
.) Press esc
.) Press up-arrow. The command does wrap properly.
.) Press esc
.) Size the tcmd window so the command will not wrap
.) Press up-arrow. The command wraps, in spite of room

However, the problem goes away after the esc, and it does the same thing in 12, for me.
---End Quote---

WAD -- this is old, old, old behavior going back 20+ years. It's been brought up several times since then, and after explanations the users have always decided to keep it the way it is.

TCC gets its screen size when it enters the line input routine, and again after each character is entered. The problem in your example is that TCC is waiting for a Windows API to return a keystroke when you change the window size. So TCC doesn't recognize the new size until after it's processed the current keystroke.

Earlier trials that checked the window size, checked for a keystroke without waiting and looped back to check the window sized again always foundered due to either excessive overhead or slow response time to keyboard input. I might revisit this now that most people are running (much) faster systems. But IMHO it doesn't merit being put at the top of the new feature list.
 
Recalled in a console window, it's wrapped right after the 'u' in "gnu". If I start TCMD (13/TCC 13) and press [Up] the command appears wrapped, as above, even though there are 10 (or so) spaces left on the first line. [Esc] doesn't erase the wrapped part.

That does not happen in an identically-sized TCMD12.

Not reproducible here, nor can I conceive of any way that could possibly happen. (There is no wrap information contained in the history lists.)

Unless you've neglected to mention a critical factor, such as you've configured TCMD 13 to auto-attach existing consoles, and you're pressing [Up] in the same console that you were running stand-alone previously. In which case the wrap would be expected (see my previous explanation to Jim). Or that you have a plugin that's doing its own resizing.
 
On Mon, 03 Oct 2011 11:58:04 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|Recalled in a console window, it's wrapped right after the 'u' in "gnu". If I start TCMD (13/TCC 13) and press [Up] the command appears wrapped, as above, even though there are 10 (or so) spaces left on the first line. [Esc] doesn't erase the wrapped part.
|
|That does not happen in an identically-sized TCMD12.
|---End Quote---
|
|Not reproducible here, nor can I conceive of any way that could possibly happen. (There is no wrap information contained in the history lists.)
|
|Unless you've neglected to mention a critical factor, such as you've configured TCMD 13 to auto-attach existing consoles, and you're pressing [Up] in the same console that you were running stand-alone previously. In which case the wrap would be expected (see my previous explanation to Jim). Or that you have a plugin that's doing its own resizing.

I am not attaching consoles. Simply, start TCC ... issue "ECHO [enough
characters to make it wrap]" ... close TCC ... start TCMD ... press [Up-arrow].
The recalled line is wrapped at the same character as in the console even though
TCMD has more space available at the end of the first line. And [Esc] doesn't
clear the entire recalled command

Everything's fine in a tab after [Return] has been pressed once. But open
another tab and you see the problem again.

To put it another way, TCMD doesn't resize the console to match its tab window
width until [Enter] has been pressed. This is evidenced by the following: If I
make TCMD's COMSPEC "d:\tc13\tcc.exe echo %_ruler", when a tab opens I see an
80-character ruler, though the tab window can handle 91 characters. If I then
issue "ECHO %_RULER" I get a 91-character ruler.

Note _RULER is my plugin (4UTILS); it merely prints a ruler as wide as the
console screen buffer (and knows nothing about TCMD).
 
To put it another way, TCMD doesn't resize the console to match its tab window width until [Enter] has been pressed.

Definitely *not* true (and not reproducible). The console is created and resized when TCMD creates the tab window. There is no resizing at all going on in Take Command or in TCC when in the TCC line input routine.

There's something else happening in your configuration that you haven't revealed yet.
 
This is evidenced by the following: If I
make TCMD's COMSPEC "d:\tc13\tcc.exe echo %_ruler", when a tab opens I see an 80-character ruler, though the tab window can handle 91 characters. If I then issue "ECHO %_RULER" I get a 91-character ruler.

That's not a valid test. It's showing the state of the console window when it was initially created, not the current state.

When TCMD starts the TCC session, it cannot create the console in the size that TCMD wants. (There is no way to do that in Windows.) Instead, it starts TCC (hidden), and the Windows console manager creates the default window size. TCMD waits until it can access the console window, which (another Windows limitation) isn't for 20-30 milliseconds after TCC loads and begins execution. In that time, TCC can easily have executed TCSTART and be on to doing other things.


Note _RULER is my plugin (4UTILS); it merely prints a ruler as wide as the
console screen buffer (and knows nothing about TCMD).[/QUOTE]
 
On Mon, 03 Oct 2011 17:05:03 -0400, rconn <> wrote:

|Definitely *not* true (and not reproducible). The console is created and resized when TCMD creates the tab window. There is no resizing at all going on in Take Command or in TCC when in the TCC line input routine.
|
|There's something else happening in your configuration that you haven't revealed yet.

Well I'd like to hear from others. It's so simple. If there's a command
anywhere in TCC's history that would wrap if recalled in a console, and TCMD
shows more columns that a normally-started console, then start a TCMD and,
WITHOUT PRESSING ANY OTHER KEY, arrow-up until that command is displayed. Its
wrapping will be corrupt as I mentioned.

See it here: ftp://lucky.syr.edu/wrap.png ... the same command recalled in a
console and (first thing) in a (new) TCMD tab ... looks best in MSPAINT. That
particular TCMD had "/q /ii /is /ip" in its COMSPEC and that particular command
was 6 commands back in the history.
 
On Mon, 03 Oct 2011 17:35:07 -0400, vefatica <> wrote:

|Well I'd like to hear from others. It's so simple. If there's a command
|anywhere in TCC's history that would wrap if recalled in a console, and TCMD
|shows more columns that a normally-started console, then start a TCMD and,
|WITHOUT PRESSING ANY OTHER KEY, arrow-up until that command is displayed. Its
|wrapping will be corrupt as I mentioned.

It's as if the [up-arrow] isn't triggering something that (nearly?) any other
keystroke triggers.
 
If there's a command anywhere in TCC's history that would wrap if recalled in a console, and TCMD shows more columns that a normally-started console, then start a TCMD and, WITHOUT PRESSING ANY OTHER KEY, arrow-up until that command is displayed. Its wrapping will be corrupt as I mentioned.

I cannot reproduce this.

TCC 13.00.24 Windows Vista [Version 6.0.6002]
 
It's a bit elusive. I just tried it 30 times in a row (start TCMD, up-arrow, close TCMD) on both my home computer (Win7) and my work computer (XP, via remote desktop) ... with no intervening ANYTHING ... just 2-click a shortcut, up-arrow, Alt-F4, 30 times in a row. In both experiments, the corrupt display happened 23 out of 30 times (with the correct result the other 7 times).

On Mon, 03 Oct 2011 17:05:03 -0400, rconn <> wrote:

|Definitely *not* true (and not reproducible). The console is created and resized when TCMD creates the tab window. There is no resizing at all going on in Take Command or in TCC when in the TCC line input routine.
|
|There's something else happening in your configuration that you haven't revealed yet.

Well I'd like to hear from others. It's so simple. If there's a command
anywhere in TCC's history that would wrap if recalled in a console, and TCMD
shows more columns that a normally-started console, then start a TCMD and,
WITHOUT PRESSING ANY OTHER KEY, arrow-up until that command is displayed. Its
wrapping will be corrupt as I mentioned.

See it here: ftp://lucky.syr.edu/wrap.png ... the same command recalled in a
console and (first thing) in a (new) TCMD tab ... looks best in MSPAINT. That
particular TCMD had "/q /ii /is /ip" in its COMSPEC and that particular command
was 6 commands back in the history.
 
On Mon, 03 Oct 2011 21:23:48 -0400, vefatica <> wrote:

|It's a bit elusive. I just tried it 30 times in a row (start TCMD, up-arrow, close TCMD) on both my home computer (Win7) and my work computer (XP, via remote desktop) ... with no intervening ANYTHING ... just 2-click a shortcut, up-arrow, Alt-F4, 30 times in a row. In both experiments, the corrupt display happened 23 out of 30 times (with the correct result the other 7 times).

In another experiment, I repeated the above (at home) with a slightly different
sequence of events. With the long command last in TCC's history ...

start TDMC, up-arrow, Alt-T-T (new tab), up-arrow, Alt-F4

I got the corrupted wrapping 20 times out of 30 in the start-up tab and EVERY
time in the second, newly-created, tab.

I'm still using "/q /ii /ip /is" in TCMD's COMSPEC.
 
Here's another screen shot. It shows what happens if I type (in this case "12345") after up-arrowing to a wrapped command and getting corrupt output in TCMD.

ftp://lucky.syr.edu/wrap2.png

The "1" appears immediately after the end of the command, where you'd expect it. The "2345" appear on the previous line. Aparently the "1" keystroke caused the resizing of the console. If the command (with the additional "12345") is executed and recalled, the "12345" appears at the end.
 
Note that you can no longer see the tail of the original corrupt recalled
command (and the "1" I typed). They were overwritten by the command's output.

On Tue, 04 Oct 2011 11:44:35 -0400, vefatica <> wrote:

|Here's another screen shot. It shows what happens if I type (in this case "12345") after up-arrowing to a wrapped command and getting corrupt output in TCMD.
|
|ftp://lucky.syr.edu/wrap2.png
|
|The "1" appears immediately after the end of the command, where you'd expect it. The "2345" appear on the previous line. Aparently the "1" keystroke caused the resizing of the console. If the command (with the additional "12345") is executed and recalled, the "12345" appears at the end.
 
From: vefatica
| Note that you can no longer see the tail of the original corrupt recalled
| command (and the "1" I typed). They were overwritten by the command's output.
|
| vefatica <> wrote:
|
|| Here's another screen shot. It shows what happens if I type (in this
|| case "12345") after up-arrowing to a wrapped command and getting
|| corrupt output in TCMD.
...

Vince: I cannot remember whether or not you originally mentioned the answer - does any of this happen in stand-alone TCC?
--
Steve
 
On Tue, 04 Oct 2011 12:31:00 -0400, Steve Fabian <> wrote:

|From: vefatica
|| Note that you can no longer see the tail of the original corrupt recalled
|| command (and the "1" I typed). They were overwritten by the command's output.
||
|| vefatica <> wrote:
||
||| Here's another screen shot. It shows what happens if I type (in this
||| case "12345") after up-arrowing to a wrapped command and getting
||| corrupt output in TCMD.
|...
|
|Vince: I cannot remember whether or not you originally mentioned the answer - does any of this happen in stand-alone TCC?

No.

And (Rex) if, after producing the corrupt recalled line, I detach the console, I
see that it is corrupt there too. This seems to indicate that the console was
resized (in this case from 80 to 91 wide) AFTER the command was recalled.
 

Similar threads

Back
Top