This has been on my mind for a long time, and it's time I ask. Every version of WINE I have ever used Wine cmd in has this "bug", but I don't know if it's Wine's fault, or terminal's fault. Or if WINE cmd can at least be made more compatible with terminal. If I open terminal (only tried this in Linux) and run wine's cmd, I get wine's cmd in the terminal. If I enter (or drag in) a line longer than the width of the terminal window in Wine's cmd, I experience funny behavior. It can be weird in either xterm or the gnome-terminal, but there is variation in this strange behavior between the two. I don't think that necessarily implies that it's terminal's fault. Or at least, I'm thinking, that doesn't prove that Wine cmd can't improve terminal compatibility. Let's focus on just how it behaves in gnome-terminal right now: The easiest to notice of this funny behavior is that if I type past the width of the terminal in Wine cmd, and it "wraps around" to start a new "graphical line" (even though it's still all one "line" in the sense that you are entering a "line" at a prompt), I cannot backspace back up to the previous "graphical line" if I realize I made a typo up there after I have been "wrapped around". If you delete all of the "graphical line" (that's as much as it will let you) and hit enter, the above graphical line(s) in your prompt line are ignored, and you are taken to a clean prompt, just like if you hit enter at an actually blank prompt. The first character I strike after being wraped around replaces the wrapped-around remainder with as much as possible of the entire "prompt line", with the character you hit appended. Note that this can overflow to the next graphical line, repeating the bug. It could even go for several graphical lines, resulting in several cloned graphical lines. Once a line has been cloned and you are on a new graphical line after the first clone (that should be graphical line 3. The prompt line (1), the clone line (2), and now this one, a second clone line (3)), every character you hit causes a new clone line to be added above. This can cause a finite chain-reaction if you drag something in that is long enough to go over the first cloned line: there will be a number of cloned lines equal to the number of characters in the remainder line, because for each character that was entered in the remainder line, a cloned line was added. It's just that when you do it yourself it's slow enough to see that that is why it turns out that way, whereas dragging something in seemingly instantly throws that all up at once. Also, when you try to use the up arrow key to have what you entered at the last (or earlier) prompt show up at the current prompt, when the terminal window is narrower than the "summoned" line is long, there is strange behavior. If you edit this "summoned" line in any way, or even move the cursor with the left arrow key, the moment you do, the entire earlier entered line (or as much of it as possible) is put at the current graphical line, replacing the remainder that wrapped around, leaving a partial copy up by the prompt. Again, you cannot backspace your way up to a higher "graphical line" in your "prompt line". In other words, the above described bug still applies when you use the up arrow key. I find this very strange because I noticed that DOSBox has the same (or similar) bug. It makes me wonder if this bug is traditional of DOS-like CLI and is to be expected. That's why in the title I call it a "common CLI" bug. If it is terminal's fault, one solution is that a WINE cmd that is it's own window could be made. This would also solve any other bash-related Wine cmd woes. And it could take a parameter to run within terminal for when people log into Linux or other Unix operating system in CLI-only mode. Cheers, Jake
