I'm just going to quote from a post I made for the creack/pty package, https://github.com/creack/pty/discussions/199#discussioncomment-9822385.
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?
And the response from the package owner:
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.
Terminals often writes the literal ^ followed by a literal something to indicate non-printable characters.
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.
This may be more of a z/OS system issue rather than a Go for z/OS issue, but figured this was a good place to start. Thanks.
I've attached a git diff and four new files that allow the pty package to work on z/OS. An additional requirement is an update to x/sys/unix that has not been implemented yet. You can find it at https://github.com/ccw-1/sys.
------------------------------
Frank Swarbrick
------------------------------