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
>
>
>
>