On Thu, 2011-10-06 at 02:00 -0500, SpawnHappyJake wrote: > 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. > AFAIK the terminal is fairly dumb and doesn't do a lot more than echo whats typed in or displayed by a program and interpret xterm terminal control sequences. All history maintenance and command line editing is done by the program, e.g. bash. A clue is that the amount of scrollable history is a bash configuration parameter and the history is held on ~/.bash_history. In fact, bash uses the readline() function, "man 3 readline", to read the command line. This handles all editing and back-scrolling through the command history and is responsible for showing the command prompt. I think you'll find that other interactive command line programs use it too, such as psql (PostgreSQL's interactive client), vi and emacs to name a few. It seems likely that Wine's cmd and DOSbox don't use it, either for portability reasons or because their authors didn't think of it. Martin > 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 > > > >
