A question that came through on the sshpass mailing list (and also on stack overflow). Sshpass does not work on HP-UX.
Looking at the truss output, I see the following:
-u [/tmp/sshpass][14066]{3783827} fork() ................... (returning as child ...) ......... = 14064 {3783821}
The child process is 14066.
-u [/tmp/sshpass][14066]{3783827} setpgrp3(2)................................................. [entry]
-u [/tmp/sshpass][14066]{3783827} setpgrp3(2)................................................. = 14066
Start a new session, disconnecting from the previous TTY
-u [/tmp/sshpass][14066]{3783827} open(0x400132d0, O_RDWR, 01210)............................. [entry]
-u [/tmp/sshpass][14066]{3783827} open("/dev/pts/5", O_RDWR, 01210)........................... = 6
Open /dev/pts/5 with the flags O_RDWR. According to Posix, at this point pts/5 is supposed to become the controlling terminal for the new process. This, obviously, does not happen.
The HP-UX man page for open suggests that opening /dev/pts/5 should have made that process adopt it as its new controlling TTY. I have no idea why that doesn't happen, nor access to an HP-UX system to experiment.
The person whose system it was actually had to go to HP's support to get an answer, but since we have the answer now, I'll post it here.
From the HPUX termios(7) man page:
(Emphasis added).
As far as I can tell, the part in bold is an HPUX idiosyncrasy, and is not part of either Posix or, for that matter, other Unix platforms.
The problem is that sshpass opens the relevant tty, and immediately closes the file descriptor, as it assumes that it is already set as the controlling TTY of the process.
Because of the HPUX idiosyncrasy, this means that the TTY becomes the process' controlling TTY, and immediately stops after the close.