FreeBSD & Debian: pty.sh fail: process/terminal group exercise

[McDutchie]

On this FreeBSD version, the following regression test failure occurs:

$ uname -vm
FreeBSD 12.1-RELEASE-p6 GENERIC  amd64
$ bin/shtests -p pty
[...]
        pty.sh[445]: process/terminal group exercise: line 451: read timeout

On Debian 10 (Buster) as hosted by shell.xs4all.nl, this test also fails, slightly differently:

$ cat /etc/issue; uname -srm
Debian GNU/Linux 10 \n \l

Linux 4.9.0-9-amd64 x86_64
$ bin/shtests -p pty
[...]
        pty.sh[445]: process/terminal group exercise: line 451: expected "Stopped", got ""

The test in question:

ksh/src/cmd/ksh93/tests/pty.sh

Lines 445 to 454 in f811482

	TERM=vt100 tst $LINENO <<"!"
	L process/terminal group exercise
	w m=yes; while true; do echo $m-$m; done | less
	u :$|:\E|lines
	c \cZ
	r Stopped
	w fg
	u yes-yes
	!

[aweeraman]

My knowledge of this test syntax is limited, so please see if the following makes sense:

c \cZ
u Stopped

"c \cZ" puts the while loop that's printing "yes-yes" to the background, and expects the immediate next line to match "Stopped", however, I'm seeing the following output from the test on Debian in debug mode:

process/terminal group exercise: debug-1: w "\cZ"
process/terminal group exercise: debug-2: b "\r\E[K\000\000\000\000\000\000\000\000\000\000\000\000\E[?1l\E>"
process/terminal group exercise: debug-2: b "[1] + Stopped                  m=yes; while true; do echo $m-$m; done | less\r\n"

There seems to be an extra line of output immediately after the suspend. Am I reading that right?

If I put a "u ?." to consume what appears to be an EOF as shown below, just to test that hypothesis, the test seems to pass:

c \cZ
u ?.
u Stopped

This is of course not the solution, but it would seem that there's some extra output after suspending the job that's causing the test failure.

Just an observation, FWIW.

[McDutchie]

Thanks for investigating that, @aweeraman, it's worth a lot.

Note that pty self-documents: arch/*/bin/pty --man. This says that the "u re" command should "read lines from master until one matches re". (And the re is an ERE, extended regular expression.) So your u ?. should be superfluous as the next u Stopped should simply keep reading lines until encountering Stopped.

After changing r Stopped to u Stopped, the test still fails on the Debian 10 system at xs4all, as follows:

$ bin/shtests -x -p pty
[...]
process/terminal group exercise: debug: r "yes-yes\r\n"
process/terminal group exercise: debug: r "yes-yes\r\n"
process/terminal group exercise: debug: r "yes-yes\r\n"
process/terminal group exercise: debug: r "yes-yes\r\n"
process/terminal group exercise: debug: r ":\E[K"
process/terminal group exercise: debug: w "\cZ"
process/terminal group exercise: debug: r ""
process/terminal group exercise: debug: r ""
process/terminal group exercise: debug: r EOF
        pty.sh[445]: process/terminal group exercise: line 451: expected "Stopped", got EOF

So this does show that the u command works: it keeps reading lines, encountering two empty lines and then EOF. I'm mystified by this. That same system does print 'Stopped' if I try it manually on a real terminal.

In addition, further investigation on my part reveals that some systems (at least OpenBSD and FreeBSD) print "Suspended", not "Stopped". So the test would need to be updated for that as well. But then, that indicates that whole test is unportable. Who knows what string might appear on different current and future OSs.

I still don't really understand what's going on here, but I'm about ready to conclude that whether and how that "Stopped" line is printed is OS-specific, and the test should simply ignore whether and how that happens and instead check for the next PS1 prompt to appear (using u) before writing the fg command.

So I just tried changing the test to this on the Debian system in question:

# err_exit #
whence -q less &&
TERM=vt100 tst $LINENO <<"!"
L process/terminal group exercise

w m=yes; while true; do echo $m-$m; done | less
u :$|:\E|lines
c \cZ
u :test-
w fg
u yes-yes
!

…and now the test intermittently either fails or succeeds on that Debian system. Randomly. The failures are the same kind of "got EOF" again.

<throws up hands> I'm feeling pretty clueless right about now… Is ksh broken on this system, or is pty broken, or is the OS broken, or some combination of all three?

[aweeraman]

Looks like this has been investigated before (att#375) with the conclusion that pty is not handling the SIGTSTP signal correctly.

This also had been a trigger to deprecate pty and related tests in ksh2020 and go with an expect for testing job related functions: https://github.com/ksh2020/ksh/blob/master/src/cmd/ksh93/tests/b_jobs.exp

[JohnoKing]

OpenSUSE has a patch that fixes the pty regression test failure on Linux, although it doesn't fix the test on FreeBSD:
https://build.opensuse.org/package/view_file/shells/ksh/ksh93-builtin.dif?expand=1

[McDutchie]

Thanks for the links. I don't want to replace pty or insert code that fixes it for one specific OS – I'd rather see it fixed properly at some point. Until then I think we can live without this one regression test.

[McDutchie]

Thanks for the links. I don't want to replace pty or insert code that fixes it for one specific OS – I'd rather see it fixed properly at some point. Until then I think we can live without this one regression test.

Actually, I'm changing my mind on a Linux-specific fix for pty. If we can only detect a SIGTSTP-related regression that we introduce on Linux, that's still a lot better than nothing. I'll test the OpenSUSE patch and apply it if it's good.