On Thu, Nov 17, 2011 at 11:44:12AM -0800, David Wolfskill wrote: > At $WORK, we have recently been reminded that xterm doesn't cope all > that well with being invoked in an environment that returns ENOENT on > xterm's attempt to open /dev/tty (in main.c). > > (The environment in question is a jailed 32-bit FreeBSD running on a > FreeBSD/amd64 host. Developers need to build in the jail; apparently > they also want to run things like emacs in the jails.) > > In looking at the xterm sources, I found that there's some code (near > main.c:3311 - 3329) to take evasive action if the attempt to open > /dev/tty fails. > > There's even a bit to effectively ignore ENOENT -- if __CYGWIN__ is > defined. > > But that's not our case -- and we don't want to be defining __CYGWIN__ > when we're building xterm for FreeBSD. > > Given that FreeBSD (with devfs) *can* return ENOENT to the attempt to > open /dev/tty, it isn't clear to me why that aprticular "error" > condition isn't ignored unconditionally (in a FreeBSD environment, at > least). > > Accordingly, I cobbled up a patch (attached), and a colleague has > verified that it avoids the issue we were encountering: it allows xterm > to run in the jail. > > Do you think the xterm folks would be receptive to either making the > "ignore ENOENT" unconditional or conditioning it on (say) "__CYGWIN_" > being defined or "__FREEBSD__" being defined? > > Failing that (or in the mean time) would you be receptive to a patch to > the FreeBSD xterm port to patch xterm in a way similar to the attached > patch? > > (I realize we're approaching 9.0-RELEASE; I'm not asking anyone to make > changes before that release date.)
I am sure that the issue is a misconfiguration of the jail or attempt to start xterm from the process that has no control terminal. For jail misconfiguration, I mean either failure to properly mount devfs into the jail /dev, or a rule that hides /dev/tty from the jail. I use very similar configuration (32bit stable/8 jail on amd64 stable/9 kernel) and have no issues starting xterm. That said, you should diagnose the issue further, otherwise I think the patch is unneccessary.
pgpl06o1Li6O7.pgp
Description: PGP signature