-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FreeBSD & Debian: pty.sh fail: process/terminal group exercise #45
Comments
My knowledge of this test syntax is limited, so please see if the following makes sense:
"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:
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:
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. |
Thanks for investigating that, @aweeraman, it's worth a lot. Note that pty self-documents: After changing
So this does show that the 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 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? |
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 |
OpenSUSE has a patch that fixes the |
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. |
On this FreeBSD version, the following regression test failure occurs:
On Debian 10 (Buster) as hosted by shell.xs4all.nl, this test also fails, slightly differently:
The test in question:
ksh/src/cmd/ksh93/tests/pty.sh
Lines 445 to 454 in f811482
The text was updated successfully, but these errors were encountered: