Skip to content

bpo-41914: Fix issue running test_pdb inside GNU screen#28564

Closed
leonplanken wants to merge 1 commit into
python:mainfrom
leonplanken:fix-issue-41914
Closed

bpo-41914: Fix issue running test_pdb inside GNU screen#28564
leonplanken wants to merge 1 commit into
python:mainfrom
leonplanken:fix-issue-41914

Conversation

@leonplanken

@leonplanken leonplanken commented Sep 25, 2021

Copy link
Copy Markdown

For some reason, two tests in test_pdb failed when running inside GNU
screen. The screen environment injects an ANSI control sequence into
the output from pdb, which did not match the expected output.

https://bugs.python.org/issue41914

For some reason, two tests in test_pdb failed when running inside GNU
`screen`.  The `screen` environment injects an ANSI control sequence into
the output from `pdb`, which did not match the expected output.
@the-knights-who-say-ni

Copy link
Copy Markdown

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

CLA Missing

Our records indicate the following people have not signed the CLA:

@phaunt

For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@github-actions

github-actions Bot commented Nov 3, 2021

Copy link
Copy Markdown

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions Bot added the stale Stale PR or inactive for long period of time. label Nov 3, 2021
Comment thread Lib/test/test_pdb.py
f'(Pdb) *** Cannot run {bad_arg}: {msg}',
'(Pdb) ',
])
self.assertIn(f'(Pdb) *** Cannot run {bad_arg}: {msg}', stdout)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to remove the other expected lines?

@@ -0,0 +1,4 @@
Fix issue running test_pdb inside GNU `screen`: for some reason, two tests

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd remove everything after the first colon, NEWS entries just need to say what the change is, not a detailed motivation.

Comment thread Lib/test/test_pdb.py
'(Pdb) ',
])
]
self.assertTrue(all(e == s for (e, s) in zip(stdout_lines, expected_lines)))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could use a comment explaining why we aren't checking for an exact match.

Also, the use of assertTrue means we won't get a detailed error if the test fails. Perhaps you could loop over the pairs of lines and self.assertEqual for each line instead.

@iritkatriel iritkatriel left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See @JelleZijlstra 's comments.

@bedevere-bot

Copy link
Copy Markdown

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@encukou

encukou commented Mar 19, 2024

Copy link
Copy Markdown
Member

I cannot reproduce with Python 3.11 (or main branch) under screen. Could you share more detail about your setup? The output of screen --version, and infocmp (from inside screen) might be useful.

Without a good reproducer, and with unaddressed review comments, it's probably best to close this PR. I'll do so in a month if there's no follow-up.

@leonplanken

Copy link
Copy Markdown
Author

Hi Petr, thanks for following up. I'll see if I still get the issue, and gather the requested information.
(P.S. also, sorry for letting this grow stale.)

@leonplanken

Copy link
Copy Markdown
Author

I got (and still get) this issue in screen version 4.05.00 under Debian 9.13 Stretch, but can't reproduce in that same version of screen under Ubuntu 22.04 Jammy.

So I think this can be closed.

I'm not savvy enough to parse it myself, but for the record, here's the output of infocmp from the offending environment:

#	Reconstructed via infocmp from file: /usr/share/terminfo/s/screen.xterm-256color
screen.xterm-256color|GNU Screen with xterm using 256 colors,
	am, bw, km, mc5i, mir, msgr, npc, xenl,
	colors#256, cols#80, it#8, lines#24, pairs#32767,
	acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
	bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
	clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M,
	csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
	cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
	cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
	cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
	dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
	el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
	hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
	il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS,
	is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F,
	kHOM=\E[1;2H, kLFT=\E[1;2D, kRIT=\E[1;2C, kb2=\EOE,
	kbs=\177, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC,
	kcuu1=\EOA, kdch1=\E[3~, kend=\E[4~, kent=\EOM, kf1=\EOP,
	kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P,
	kf14=\E[1;2Q, kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~,
	kf18=\E[17;2~, kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~,
	kf21=\E[20;2~, kf22=\E[21;2~, kf23=\E[23;2~,
	kf24=\E[24;2~, kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R,
	kf28=\E[1;5S, kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~,
	kf31=\E[18;5~, kf32=\E[19;5~, kf33=\E[20;5~,
	kf34=\E[21;5~, kf35=\E[23;5~, kf36=\E[24;5~,
	kf37=\E[1;6P, kf38=\E[1;6Q, kf39=\E[1;6R, kf4=\EOS,
	kf40=\E[1;6S, kf41=\E[15;6~, kf42=\E[17;6~,
	kf43=\E[18;6~, kf44=\E[19;6~, kf45=\E[20;6~,
	kf46=\E[21;6~, kf47=\E[23;6~, kf48=\E[24;6~,
	kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q, kf51=\E[1;3R,
	kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
	kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
	kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
	kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
	kf8=\E[19~, kf9=\E[20~, khome=\E[1~, kich1=\E[2~,
	kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
	kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, op=\E[39;49m,
	rc=\E8, rev=\E[7m, ri=\EM, rin=\E[%p1%dT, rmacs=\E(B,
	rmam=\E[?7l, rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>,
	rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m, rs1=\Ec,
	rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
	setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
	setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
	sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p5%t;2%;m,
	sgr0=\E(B\E[m, smacs=\E(0, smam=\E[?7h, smcup=\E[?1049h,
	smir=\E[4h, smkx=\E[?1h\E=, smm=\E[?1034h, smso=\E[7m,
	smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
	u8=\E[?%[;0123456789]c, u9=\E[c, vpa=\E[%i%p1%dd,

@sumagnadas sumagnadas mannequin mentioned this pull request Apr 9, 2024
@encukou

encukou commented Apr 9, 2024

Copy link
Copy Markdown
Member

The extra sequence, \\x1b[?1034h', appears in that output as smm=\E[?1034h. According to man terminfo, smm is “turn on meta mode (8th-bit on)”.

Presumably this is related to readline option enable-meta-key.

We should probably change tests to ignore all ANSI escape sequences -- there's apparently bunch of stuff that readline can try to set up an unknown terminal. However, since it looks like it last appeared on out-of-support Debian, it likely won't make the top of anyone's TODO list.

So I think this can be closed.

Agree. Thanks for following up!

@encukou encukou closed this Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting changes stale Stale PR or inactive for long period of time.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants