pty2pty A Unix software NULL modem. Summary
Allows two programs using the pseuto ttys to open and close their device at will without giving the other program a notification of the open or close. Very useful with pose as it tends to open and close the serial port frequently in the middle of a hotsync operation. It also removes the ordering which program had to be run first and be waiting for input.

Download
pty2pty_1.9.tar.gz

This program allows two programs on the same computer to talk through a tty local null modem like cable. Things like baud rates are ignored, along with I'm sure other real hardware serial interfaces, but the termios calls do not fail which allows at least some programs to work without a problem using it.

The Unix Palm Pilot utilities use the serial port to connect to the Palm Pilot's serial port for synchronization etc. The Palm Pilot emulator has the ability to use a Unix serial port as if it was the serial port on the Palm Pilot. The normal case as listed in the emulator manual is to connect a physical serial null modem between the two ports and talk over that. It is closer to simulating the connection to a real Palm handheld, but it seems silly to use up two serial ports to talk from one program to another on the same computer. The Unix /dev/pty /dev/tty pairs provide a terminal interface that allows the normal serial setup calls to be executed ignoring what doesn't make sense for the real hardware such as baud rate. The problem is the order of operation. The /dev/pty?? must be opened first, then the /dev/tty?? and if either of them close the sequence must be started over. Unfortunately pose frequently closes the serial port making it hard to complete even a single hotsync operation.

That is the reason for this program. It opens two /dev/pty ports and relays data from one to the other. If a program closes the /dev/tty port this program gets a read error which it retries after a delay until the /dev/tty port is opened and data can again flow. The other program need not be notified. An alternate way to delaying and retrying the read operation is to close the /dev/pty and open it again. This has the advantage that read will block until there is data instead of returning EIO. Unfortunately this introduces a race condition, which with pose frequently opening and closing the device comes up rather quickly. The race condition is, pose closes port, pty2pty gets EIO from read, pose opens port, pty2pty closes port, pty2pty opens port. The pty must be opened first, and if the pty is closed while the tty is still open the pty can't be opened again until the tty is closed. At this point pose has the tty open and pty2pty gets EIO each time it tries to open the port. This is a real race condition I'm seeing and polling read is the only way I see to get around it.

Future improvement might include some circular buffers. For now it is keep the program simple stupid, besides the kernel has buffers, why not use them?