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
?Common CLI Wrap Bug Strikes WINE?
-
SpawnHappyJake
- Level 5
- Posts: 272
- Joined: Sun Feb 06, 2011 5:57 am
-
Martin Gregorie
?Common CLI Wrap Bug Strikes WINE?
On Thu, 2011-10-06 at 02:00 -0500, SpawnHappyJake wrote:
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
AFAIK the terminal is fairly dumb and doesn't do a lot more than echoIf 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.
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
