I want to resurrect this to clear up some ambiguities:
Your question isn't at all about xterm--it's about the /bin/sh program on the different BSDs.
xterm is a terminal emulator. That means it emulates hardware, in this case most often a vt220 with color. It doesn't care about the software running inside it (including but not limited to the shell). It is the shell that is executing your script and the differences between /bin/sh on OpenBSD vs. the other BSDs is what matters here.
On FreeBSD, DragonFly BSD, and NetBSD, /bin/sh is ash--the Almquist shell. A modified version of this shell is used for Debian's /bin/sh (dash, the Debian Almquist shell). However, on OpenBSD, /bin/sh is effectively a hardlink to /bin/ksh; in other words, /bin/sh on OpenBSD is ksh (Korn shell).
Now here's where things go awry: read is a shell built-in. That means it is something handled by the shell and is not guaranteed to work the same way between shells. And indeed, that matters here, because the ksh read built-in is quite different from the one in ash.
Additionally, your use of echo suffers from the same fate; calling it unqualified like that will use the shell built-in instead of /bin/echo. And again, the echo built-in is different between ksh and ash. And even /bin/echo is not guaranteed to be the same between *BSD and SYSV (there are historical differences). So if you care about portability, it is best to never use options with built-ins unless you can guarantee such an option will always be handled the same way on all shells (POSIX mandates a theoretical POSIX /bin/sh) and to use fully qualified external commands, such as /usr/bin/printf.
|