Re: Weird interaction between chroot jail and shell-mode

[Sean McAfee]

Sean McAfee <eefacm@gmail.com> writes:
> This is probably the most perplexing Emacs issue I've ever
> encountered...
>
> I've been trying to build the debian "apt" package in a shell-mode bash
> shell, inside of which I've entered a chroot jail.  The build process
> (initiated with the command "dpkg-buildpackage") would reach a point
> where it executes the command:
>
>   po4a --previous --no-backups po4a.conf
>
> ...whereupon the command hangs, consuming 100% of the CPU until I kill
> it.

Well, I guess this is pretty much solved...

On investigating the po4a command, which is a Perl program, I found that
the hanging was occuring in a call to a function called "wrap_msg."
Ultimately this routine uses the terminal size reported by the
GetTerminalSize function in the standard Term::ReadKey module, which in
a shell-mode shell explicitly reports a screen width and height of zero.
Small wonder that a trusting wrapping function would get stuck in an
infinite loop...

But then, why would I still be able to build successfully in a
shell-mode shell outside of a chroot jail?  Because wrap_msg will check
the COLUMNS environment variable, and use that if it's set instead of
calling Term::ReadKey::GetTerminalSize.  Outside of the chroot, my
COLUMNS variable is set correctly.  Inside, however it is that the root
user's shell environment gets set up, COLUMNS is set as a shell
variable, but it is not exported as an environment variable.  Adding an
"export COLUMNS" to the end of the chrooted root user's .bashrc file
fixed the hanging problem.

Ultimately, this would seem to be Term::ReadKey's fault.  It advertises
a way to indicate that the terminal size could not be
determined--returning an empty list--but instead it returns nonsensical
screen dimensions of 0x0.