Hi,

The script shows, after preamble for Debian and Wine versions, what happens
on typing 'wine python' at the '$' command prompt followed by 'import subp rocess' at the '>>>' Python command prompt and then 'exit()' at the next '> >>'.

Each statement at a '>>>' is echoed several times while incomplete followed
by a final echo when the command is completed by pressing the 'Enter' key.
The command seems to be processed correctly apart from the highly confusi
ng additional echos.

The odd behaviour does not occur with the native Python invoked by typing ' python3' at the '$' command prompt.

Ideas on fixing this would be helpful.

Thanks,

Roger


Script started on 2026-05-21 19:56:52+01:00 [TERM="xterm-256color" TTY= "/dev/pts/0" COLUMNS="80" LINES="24"]
0;roger@debian: ~roger@debian:~
$ uname -a

Linux debian 6.12.74+deb13+1-amd64 #1 SMP PREEMPT_DYNAMIC Debi
an 6.12.74-2 (2026-03-08) x86_64 GNU/Linux
0;roger@debian: ~roger@debian:~
$ wine --version

wine-10.0 (Debian 10.0~repack-6)
0;roger@debian: ~roger@debian:~
$ wine python

Python 3.14.2 (tags/v3.14.2:df79316, Dec 5 2025, 17:1
8:21) [MSC v.1944 64 bit (
AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more i
nformation.

?25
h
?25l>>> i

1;

i?

25h?

im?

25l
?25l
25h

im

imp?2
5l

impo

[?25l

i

mpo?

impor?

25h
?25l

impor

i

mport
?25l

import

?25l>>> impo
rt s

import s

?25l
[1;35m>>> import su
?25l

?25l>>> i
mport su

import sub?25

h
?25l

import sub

[?25l>

import subp

?25l

import

subp>>>
1
;34mimport subpr

?25h
;34mimport subpr

impor

t subpro

?25l
t subpro

import su

bproc

import subproce?25

h
bproc>>>
import subproce
[19D
[?25l1;3

import subproces

[19D>>>
[1;34mimport subproces
[?25h

import subprocess
[?25h2

import subproces

s?25
h?2
5h

?25
h
?25l>>> e

1;

e?

25h?

ex?

25l
?25l
25h

ex

exi?2
5l

exit

8D

1
;35m>>> exit(
?
25l

exit()

10
C1
0D
0;roger@debian: ~roger@debian:~
$ exit

exit

Script done on 2026-05-21 19:58:33+01:00 [COMMAND_EXIT_CODE="0"]

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/21/26 3:10 PM, Roger Marsh wrote:

That looks like escape codes?

I tried rendering your post in my terminal without success. I saved it
to a text file like escape-codes-dump.txt then in the terminal I run:
cat escape-codes-dump.txt
sometimes that displays things more or less formatted and colored. Not
this time.

Next I fed your entire post into chat gpt. Due to my limited
understanding of what is going on here, I refrain from blindly echoing
the fixes it suggested, as I do not know whether they were even relevant.

It claims those are escape codes for moving, hiding, and showing the cursor.



--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

nwe wrote:

On 5/21/26 3:10 PM, Roger Marsh wrote:

?

That looks like escape codes?

Yes. Roger's capture is unreadable unless you know or can guess
the exact terminal type he is using and can interpret those
codes.

It's the sort of thing which happens when there's a program
thinks that it is sending to a terminal but is actually sending
to a file.

And it's the sort of thing which everyone tends to do once, then
they realize their mistake and double-check in the future.

It's also likely that it has nothing much to do with the odd
behavior that he's trying to report, but it certainly obscures
whatever that is.

-dsr-

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 22/05/2026 11:18, Dan Ritter wrote:

nwe wrote:

On 5/21/26 3:10 PM, Roger Marsh wrote:

That looks like escape codes?

Yes. Roger's capture is unreadable unless you know or can guess
the exact terminal type he is using and can interpret those
codes.

Is this actually input to "script(1)"? Script produces a "typescript"
and, although the man page isn't explicit,ÿ it's conceivable that the
format is tuned for itself. The OP did start by saying "the script
shows...".


As for the original problem, it seems that python.exe is maybe making
some assumptions about the terminal which wine isn't handling correctly.
I would probably start by seeing if the bug is reproducible in "wine
cmd" and "wine pythonw" (it's been a while since I used pythonw; it
might *not* offer an interactive prompt).

It's the sort of thing which happens when there's a program
thinks that it is sending to a terminal but is actually sending
to a file.

And it's the sort of thing which everyone tends to do once, then
they realize their mistake and double-check in the future.

It's also likely that it has nothing much to do with the odd
behavior that he's trying to report, but it certainly obscures
whatever that is.

-dsr-

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, May 22, 2026 at 12:28:29 +0100, Darac Marjal wrote:

On 22/05/2026 11:18, Dan Ritter wrote:

nwe wrote:

On 5/21/26 3:10 PM, Roger Marsh wrote:

4

C
?25h>>>

That looks like escape codes?

Yes. Roger's capture is unreadable unless you know or can guess
the exact terminal type he is using and can interpret those
codes.

Is this actually input to "script(1)"?

It's the *output* of script, though it could have been mangled during
email tranmission.

If the log hasn't been mangled, then simply "cat"ing it on a compatible terminal should leave the terminal in some sort of state resembling
what the OP saw on their terminal while recording the session. However, there's a non-zero security risk in doing this (some terminal emulators
may execute commands when given certain escape sequences), so I would
not advise it.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 22 May 2026 10:12:40 -0400
Greg Wooledge <greg@wooledge.org> wrote:

On Fri, May 22, 2026 at 12:28:29 +0100, Darac Marjal wrote:

On 22/05/2026 11:18, Dan Ritter wrote:

nwe wrote:

On 5/21/26 3:10 PM, Roger Marsh wrote:

That looks like escape codes?

Yes. Roger's capture is unreadable unless you know or can guess
the exact terminal type he is using and can interpret those
codes.

Is this actually input to "script(1)"?

It's the *output* of script, though it could have been mangled during
email tranmission.

If the log hasn't been mangled, then simply "cat"ing it on a compatible terminal should leave the terminal in some sort of state resembling
what the OP saw on their terminal while recording the session. However, there's a non-zero security risk in doing this (some terminal emulators
may execute commands when given certain escape sequences), so I would
not advise it.

(I think I have seen the 'non-zero security risk' thing happen several times recently, probably when using the scroll-wheel to look back through a session log and, I think, on one occaision when I decided to remove dirt from the ball contact points without turning the trackball off first.)
Normally I work at an OpenBSD XServer, just the base system with no packages added except firmware by the OpenBSD installer, and ssh into whatever box has the application package to be used. The problem was first noticed in this environment but I did not think the scope narrow enough to ask anyone about it until it was seen on the Debian box without ssh being involved.
The script *output* included in the body of the first email, wine-python-debian, is attached. It was collected with a monitor, keyboard, and trackball, connected to the Debian box and all input was via the keyboard with trackball focusing assistance. No ssh into the Debian box in other words. It seemed to me the 'cat' interpretation of the script output file did not accurately represent what was seen on the terminal as the characters were being typed. Specifically all of the '>>>' lines displayed except those terminated by a typed-in 'Enter' looked blank in part with the input cursor at an apparently random position on the latest line.
The script *output* attached as wine-python-openbsd-xserver shows what happens with the 'import subprocess' statement in
a Microsoft Windows 'py -3.14' session, a Debian 'wine python' session, and a Debian 'wine cmd python' session. The 'pythonw' command is accepted in wine but does nothing visible.
OpenBSD 'less' translates the 'square with four things in it' symbol as ESC in both attachments.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 23 May 2026 13:31:38 +0000
Roger Marsh <r.m@rmswch.plus.com> wrote:

On Fri, 22 May 2026 10:12:40 -0400
Greg Wooledge <greg@wooledge.org> wrote:

On Fri, May 22, 2026 at 12:28:29 +0100, Darac Marjal wrote:

On 22/05/2026 11:18, Dan Ritter wrote:

nwe wrote:

On 5/21/26 3:10 PM, Roger Marsh wrote:

1;3

4

That looks like escape codes?

Yes. Roger's capture is unreadable unless you know or can guess
the exact terminal type he is using and can interpret those
codes.

Is this actually input to "script(1)"?

It's the *output* of script, though it could have been mangled during
email tranmission.

If the log hasn't been mangled, then simply "cat"ing it on a compatible terminal should leave the terminal in some sort of state resembling
what the OP saw on their terminal while recording the session. However, there's a non-zero security risk in doing this (some terminal emulators
may execute commands when given certain escape sequences), so I would
not advise it.

The script *output* included in the body of the first email, wine-python-

debian, is attached. It was collected with a

The script *output* attached as wine-python-openbsd-xserver shows what ha

ppens with the 'import subprocess' statement in

Whoops.

I think I should have given the two attachments in my previous email the '. txt' extension.

Anyway I cannot open them here directly from the email. Saving them first seems ok though. With or without '.txt' extension.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat 23 May 2026 at 13:31:38 (+0000), Roger Marsh wrote:

On Fri, 22 May 2026 10:12:40 -0400 Greg Wooledge wrote:

It's the *output* of script, though it could have been mangled during
email tranmission.

If the log hasn't been mangled, then simply "cat"ing it on a compatible terminal should leave the terminal in some sort of state resembling
what the OP saw on their terminal while recording the session. However, there's a non-zero security risk in doing this (some terminal emulators
may execute commands when given certain escape sequences), so I would
not advise it.

When I read you first post, I copied the body to a file and edited all
the Esc chars to ? so that the less output wasn't ablaze with inverse
video. I then edited some of the commonest escape sequences to tiny
characters so that I could see the wood for the trees.
I don't know what terminal wine thinks you have, but it sure has fun.
Sequences like ?[?25h?[?25l?[?25l?[?25h?[?25l?[?25l?[?25h?[?25l are
VT220 commands to show and hide the cursor.
As you type the letters, the cursor is jumping back and forth between
the start and end of the line. There are many Clear-to-end-of-line
occurrences, most of which are at the end of the typing so far.
There are many colour commands, required to keep the >>> prompt
magenta, import blue, and exit cyan.
Anyway, with zapping the sequences in turn, there was little enough
left to do any damage, so I've attached a pasted cat of your attached
version, lacking the colours. (I've added a .txt.)

The script *output* included in the body of the first email, wine-python-debian, is attached. It was collected with a monitor, keyboard, and trackball, connected to the Debian box and all input was via the keyboard with trackball focusing assistance. No ssh into the Debian box in other words. It seemed to me the 'cat' interpretation of the script output file did not accurately represent what was seen on the terminal as the characters were being typed. Specifically all of the '>>>' lines displayed except those terminated by a typed-in 'Enter' looked blank in part with the input cursor at an apparently random position on the latest line.

Your output contains sporadic ^M (CR) characters, and I think all of
them cause a line feed, which means that you see the line printed
as far as you have typed at this point. (I haven't looked hard
enough to check whether your typing was perfect or included
corrections.)
Some of the ^M chars cause the Esc to be missing from the following
escape sequence, which is why there are fragments of them printed at
the start of five lines. I don't know why this should be happening.
Just to check my copy is good, here's its MD5 digest: 52bd7b55a5d579ae6b9dfee8d3e52fd8 /tmp/wine-python-debian

The script *output* attached as wine-python-openbsd-xserver shows what happens with the 'import subprocess' statement in
a Microsoft Windows 'py -3.14' session, a Debian 'wine python' session, and a Debian 'wine cmd python' session. The 'pythonw' command is accepted in wine but does nothing visible.

OpenBSD 'less' translates the 'square with four things in it' symbol as ESC in both attachments.

Your first post starts: "The script shows, after preamble for
Debian and Wine versions, what happens on typing \u2026 \u2026", but you
don't actually state what you observed when you were originally
typing the commands yourself, after typing the script command.
Did the output look normal as you typed it?
I don't use wine, but here's a run from my system: a cut-and-paste
of the original typing, the typescript, and the replay from cat.
(Note that my bash prompt updates xterm's window title with the
hostname and pseudoTTY number.)
Cheers,
David.

axis 08:51:47 ~$ cat /tmp/wine-python-debian
Script started on 2026-05-21 19:56:52+01:00 [TERM="xterm-256color" TTY="/dev/pts/0" COLUMNS="80" LINES="24"]
roger@debian:~$ uname -a
Linux debian 6.12.74+deb13+1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.74-2 (2026-03-08) x86_64 GNU/Linux
roger@debian:~$ wine --version
wine-10.0 (Debian 10.0~repack-6)
roger@debian:~$ wine python
Python 3.14.2 (tags/v3.14.2:df79316, Dec 5 2025, 17:18:21) [MSC v.1944 64 bit (
AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

i

im

impo
impor
import
import s
import su

import sub

mport subp
import subpr
import su
import subproce

[19D>>> import subproces
[?25h>>> import subprocess

e

ex

exit
exit(
exit()

roger@debian:~$ exit
exit
Script done on 2026-05-21 19:58:33+01:00 [COMMAND_EXIT_CODE="0"]
axis 19:31:15 ~$

axis 21:09:17 ~$ scrip my-typescript.txt
Script started, output log file is 'my-typescript.txt'.
axis 21:35:25 ~$ python3
Python 3.9.2 (default, May 14 2026, 03:00:00)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.

import subprocess
exit()

axis 21:35:51 ~$ exit
exit
Script done.
axis 21:35:54 ~$

Script started on 2026-05-23 21:35:25-05:00 [TERM="xterm-256color" TTY="/dev/pts/10" COLUMNS="100" LINES="33"]
0;AXIS /dev/pts/23 AXISaxis 21:35:25 ~$ python3

Python 3.9.2 (default, May 14 2026, 03:00:00)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.

import subprocess
exit()

0;AXIS /dev/pts/23 AXISaxis 21:35:51 ~$ exit

exit

Script done on 2026-05-23 21:35:54-05:00 [COMMAND_EXIT_CODE="0"]

axis 21:46:20 ~$ cat /tmp/my-typescript.txt
Script started on 2026-05-23 21:35:25-05:00 [TERM="xterm-256color" TTY="/dev/pts/10" COLUMNS="100" LINES="33"]
axis 21:35:25 ~$ python3
Python 3.9.2 (default, May 14 2026, 03:00:00)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.

import subprocess
exit()

axis 21:35:51 ~$ exit
exit
Script done on 2026-05-23 21:35:54-05:00 [COMMAND_EXIT_CODE="0"]
axis 21:46:31 ~$


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 23 May 2026 22:15:53 -0500
David Wright <deblis@lionunicorn.co.uk> wrote:

On Sat 23 May 2026 at 13:31:38 (+0000), Roger Marsh wrote:

On Fri, 22 May 2026 10:12:40 -0400 Greg Wooledge wrote:

It's the *output* of script, though it could have been mangled during email tranmission.

If the log hasn't been mangled, then simply "cat"ing it on a compatib

le

terminal should leave the terminal in some sort of state resembling
what the OP saw on their terminal while recording the session. Howev

er,

there's a non-zero security risk in doing this (some terminal emulato

rs

may execute commands when given certain escape sequences), so I would
not advise it.

When I read you first post, I copied the body to a file and edited all
the Esc chars to ú so that the less output wasn't ablaze with inverse
video. I then edited some of the commonest escape sequences to tiny characters so that I could see the wood for the trees.

I don't know what terminal wine thinks you have, but it sure has fun. Sequences like ú[?25hú[?25lú[?25lú[?25hú[?25l?

?[?25lú[?25hú[?25l are

VT220 commands to show and hide the cursor.

According to printenv, and 'set' at the 'wine cmd>' prompt, it must be xter
m (from TERM=xterm). After checking with 'man xterm' I guess VT220 is a
good bet. The outputs in my first post were on an almost default graphical
install: network is manual not DCHP and desktop is Xfce. I am building an other box tailored to what I want: manual network, just SSH server and Stan dard system utilities during installation, plus wine64 and wine32:i386 adde
d later so far. (64-bit Python cannot be installed on Wine without wine32: i386 being present.) printenv gives TERM=linux and 'wine cmd>set' gives TERM=xterm on this box.

As you type the letters, the cursor is jumping back and forth between
the start and end of the line. There are many Clear-to-end-of-line occurrences, most of which are at the end of the typing so far.

There are many colour commands, required to keep the >>> prompt
magenta, import blue, and exit cyan.

Anyway, with zapping the sequences in turn, there was little enough
left to do any damage, so I've attached a pasted cat of your attached version, lacking the colours. (I've added a .txt.)

The script *output* included in the body of the first email, wine-pytho

n-debian, is attached. It was collected with a monitor, keyboard, and trac kball, connected to the Debian box and all input was via the keyboard with trackball focusing assistance. No ssh into the Debian box in other words.
It seemed to me the 'cat' interpretation of the script output file did not
accurately represent what was seen on the terminal as the characters were being typed. Specifically all of the '>>>' lines displayed except those te rminated by a typed-in 'Enter' looked blank in part with the input cursor a
t an apparently random position on the latest line.

Your output contains sporadic ^M (CR) characters, and I think all of
them cause a line feed, which means that you see the line printed
as far as you have typed at this point. (I haven't looked hard
enough to check whether your typing was perfect or included
corrections.)

Some of the ^M chars cause the Esc to be missing from the following
escape sequence, which is why there are fragments of them printed at
the start of five lines. I don't know why this should be happening.

Just to check my copy is good, here's its MD5 digest: 52bd7b55a5d579ae6b9dfee8d3e52fd8 /tmp/wine-python-debian

The script *output* attached as wine-python-openbsd-xserver shows what

happens with the 'import subprocess' statement in

a Microsoft Windows 'py -3.14' session, a Debian 'wine python' session,

and a Debian 'wine cmd python' session. The 'pythonw' command is accepted
in wine but does nothing visible.

OpenBSD 'less' translates the 'square with four things in it' symbol as

ESC in both attachments.

Your first post starts: "The script shows, after preamble for
Debian and Wine versions, what happens on typing ? ?", bu

t you

don't actually state what you observed when you were originally
typing the commands yourself, after typing the script command.
Did the output look normal as you typed it?

Short answer: no

Long answer is a bit like a Shipping Forecast:

My typing and response starting from the '>>>' prompt:

' always magenta

insertion point for next character typed is immediately after last of same line and next line '...' unless stated otherwise.

'i' same line '>>> i' next line ' '
'm' same line '>>> im'
'p' same line '25h>>> im' next line ' imp '
'o' same line '>>> impo'
'r' same line '>>> impo' next line '>>> impor'
't' same line '>>> impor' next line 'mport ' "mport" blue
' ' same line '>>> import' next line ' ' "import" blue
's' same line '>>> import s' "import" blue
'u' same line '>>> import s' next line '>>> import su' "import" blue
'b' same line '>>> import su' next line '>>> import sub' "import" blue
'p' same line '13D>>> import sub' next line '>> import subp ' "import" blue
">>" magenta
'r' same line '>>> mport subp' next line 'import subpr ' "mport" blue "i mport" blue
'o' same line '>>> import subpr' next line 'o subpro ' "import" blu
e "o" blue
'c' same line '>>> import su' next line 'bproc ' "import" blue
'e' same line '>>> import subproce' next line ' ' "import
" blue
's' same line '[19D>>> import subproces' next line ' ' " import" blue
's' same line '[?25h>>> import subprocess' next line '
' "import" blue
'\n' same line '' next line '>>> '
'e' same line '>>> e' next line ' '
'x' same line '>>> ex'
'i' same line '25h>>> ex' next line ' exi '
't' same line '>>> exit' insertion point at right-most column of session "e xit" cyan
'(' same line '>>> exit' next line '>>> exit(' "exit" cyan
')' same line '>>> exit(' next line '>>> exit()' "exit" cyan
'\n' same line '[9D>>> exit()' next line '' "exit" cyan

The Python session was run by:

$ ssh debian
...
roger@debian:~$ wine python

so it was next to the email session on the monitor for ease of describing t
he changes seen.

I made lots of typing mistakes on the way to this. If I just accepted the SyntaxError, or whatever, and started typing the example again the "same li
ne" "next line" patterns could be different.

I don't use wine, but here's a run from my system: a cut-and-paste
of the original typing, the typescript, and the replay from cat.
(Note that my bash prompt updates xterm's window title with the
hostname and pseudoTTY number.)

What I see for python3 (native debian) is like your cat replay, and identic
al for the Python prompts.

Cheers,
David.

I have probably seen Python's magenta '>>>' prompts on Wimdows before but n
ot taken much notice till now. Installing several older Python versions on
Wine shows that the magenta '>>>' prompt first appears in 3.13 and older v ersions do not have this problem.

Thanks,
Roger

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)