1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Corruption in TCMD tab window

Discussion in 'Support' started by vefatica, Oct 2, 2011.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     
  2. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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).
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     
  4. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    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:




    --
    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.
     
  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  6. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    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.
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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).
     
  9. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  10. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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]
     
  11. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     
  12. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     
  13. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    648
    Likes Received:
    1
    I cannot reproduce this.

    TCC 13.00.24 Windows Vista [Version 6.0.6002]
     
  14. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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).

     
  15. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     
  16. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     
  17. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     
  18. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     
  19. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     

Share This Page