I've got a Wyse WY-50 terminal here that, for various nolstagia and productivity reasons (really!), I'd like to connect to my Macbook and use as a login terminal. I'm using OSX 10.10 El Capitan.
The terminal itself has two ports on the back, one marked MODEM and one marked AUX. From the manual, normally the device you're connecting to uses the MODEM port, and another ancilliary device like a printer uses the AUX port. These are both DB25 ports.
The MODEM port is connected to my mac via a DB25-DB9 converter, and from there to the mac via a USB-DB9 adapter using a Prolific chipset.
I had to install a driver for the converter to become available. After that was done, I got two devices created in
/dev/, those are
I followed the guide here to set up a LaunchDaemon Plist to spawn a
getty session attached to the terminal, since apparently you can't just either edit
/etc/ttys or run
getty by hand in modern OSXes.
The terminal itself is set to VT100 emulation mode at 19200 baud, with DTR flow control on receive and no flow control on send (the only option for send flow control is
This setup has proven difficult to troubleshoot, since incorrect communication with the serial device tends to "hang" it, requiring a reboot to become usable again.
In all cases, calls to
getty whether in a file or by hand were of the form
/usr/libexec/getty std.19200 cu.usbserial
Anytime you see "No output", this means the terminal was slient, showing nothing, and was unresponsive to keypresses.
gettyby hand: No output. (Seems to validate the guide)
- Adding a line to
/etc/ttys: No output. (Again, validates the guide)
From here, I tried the plist method by adding a file to
console.plist with the following content:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Disabled</key> <false/> <key>KeepAlive</key> <false/> <key>Label</key> <string>serialconsole</string> <key>ProgramArguments</key> <array> <string>/usr/libexec/getty</string> <string>std.19200</string> <string>cu.usbserial</string> </array> <key>StandardErrorPath</key> <string>/tmp/serialconsole.err</string> <key>StandardOutPath</key> <string>/tmp/serialconsole.out</string> </dict> </plist>
After loading and running the job, the following things were tried, each time attempting to stop, edit, unload, reload, and run the job in order:
- Flow control on the terminal set to NONE: No output.
- Different baud rates set on the
gettycommand and the terminal (from 9600 to 19200): No output.
- Using the
tty.usbserialdevice rather than the
cu.usbserialdevice in combination with the above: No output.
- Moving the serial line on the terminal to the AUX port and reconfiguring it to use the AUX port for communication: SOMETHING HAPPENS!
On another port
So, I can get basic communication if the computer is connected to the terminal by way of the AUX port. With settings as follows:
launchdwith the above plist
- Terminal personality set to
- Flow control disabled
However, this results in a lot of garbage characters on the terminal screen. The login prompt itself is clean, but hitting return always generates a small amount of garbage. After logging in, this garbage tends to get concatenated to the end of commands, making the session almost unreliable and unusable.
With the settings as described above, here's an example of what I mean on the terminal output:
You can see some noise once the port is initialized, and then a "clean" login display. I enter my username and press Return on the terminal keyboard. Rather than dropping down a line and prompting for a password, You see the
UTHx appear, and then the Password prompt on the same line.
Entering my password (which is properly not echoed) displays the "last login" message, and then a completely trashed shell afterwards. It's almost as if linefeed characters are being mangled somehow.
If I press Ctrl+l on the terminal, the last line resets itself, and I see a clean prompt (not pictured). However, the garbage returns the next time I press return on the terminal.
My terminal is set to
Another suggestion I read was to try using the
reset command to clear the display to known-good settings. Typing reset and hitting return gives me a clean error "Unknown terminal type: su (-1)". With a prompt for
Changing the "personality" setting on the terminal, correlated with a reset above, to other promising options only modifies the "kind" of garbage I see - none of it is clean.
- VT100 (as shown)
- UNIX CONSOLE (lots of high-ascii symbols)
- WY-50 (the actual model of the terminal: lots of high-ascii symbols sprayed all over the screen)
I don't think so. The exact same adapter/terminal/etc setup was connected to an Ubuntu Linux machine, with
getty configured as described, and it Just Worked®, with no noise or garbage on the screen.
Furthermore, using the third party application Serial to just write plain text to the terminal works without issue - no garbage, and newlines are handled correctly.
Something about Mac OS's configuration with
getty is causing issues with this terminal.
I found a way to get a usable terminal session. Run
screen, pointed at the serial port like so:
screen /dev/cu.usbserial 57600
And then from within screen, hit ctrl + a, : and then type:
exec ::: /usr/libexec/getty std.57600
Et voila, a clean and usable login shell appears on the terminal!
However, this method still has some drawbacks.
The prompt line is doubled. that is, any time you hit return at the prompt, the prompt, a newline, and another prompt appears. There's also still a ton of noise on the line - any commands that dump a lot of text at once like an
ls results in garbled output.
Programs are convinced that the terminal type is set to
screen, even if i do an
export term='vt100' - this means that most full screen terminal apps like
mutt drop a lot of control codes that the terminal can't handle, usually hanging it to the point a reset is necessary to gain input again.
I'm still searching for a way to have the terminal Just Work on login.