Handling backspace behavior on z/OS #199
Replies: 1 comment 1 reply
-
Interesting. ^H is the result of \b via the underlying pty driver. That is the behavior on both Linux and OSX, and I believe it has been tested on FreeBSD and OpenBSD as well. This usually can be changed by changing the termios via ioctl. While having a slightly different behavior on how backspace is handled by z/OS may not be a blocker, I would think the different behavoir on the tty read is concerning. The idea of the test is to ensure that a read on the tty yields the exact data written to it. Seem like it is not the case here and get the interpreted result on the tty side which could cause issues. |
Beta Was this translation helpful? Give feedback.
-
So this is interesting. In doc_test.go there is a test named TestReadWriteControls. In this test it writes "pind", the "\b" (backslash), then "g\n" to the pty. This, of course, shows up as just "ping" (and newline) on a terminal.
The test checks two results. One reading from the tty, and one the echo back from the pty.
For the tty the expected result is "pind\bg\n". This makes sense, as it is exactly what was written to the pty.
For the pty echo the expected result is "pind^Hg\r\n". To be honest, this doesn't make sense to me. While I know that ^H is the control code for backspace, how it gets the literal "^" followed by the literal "H" is beyond me. Regardless, that's what it is and I guess it must work.
On z/OS, however, the results are a bit different.
On the tty read we are getting simply "ping\n". Which is logically the same, but not the same exact behavior.
On the pty echo we are getting "pind\b \bg\r\n". I have no idea why it behaves this way, but it's essentially result.
So my question is, do I need to somehow fix the behavior to get the exact same results as the test is looking for? If so, what should I be looking at? Or can I just have a different expected result for the zos platform?
Thanks.
Beta Was this translation helpful? Give feedback.
All reactions