"Eric J. Schwertfeger" <[EMAIL PROTECTED]> writes:
> I'm flabbergasted. I was aware of that patch, but hadn't tracked it down,
> since the reason I had run with --debug was because it was dying without
> it, and I wanted to find out why. But, i threw in that patch to see what
> the debug output looked like. And the connection worked. I then stopped
> and restarted lshd without --debug. And it still works. Thank you.
I don't quite understand how that bug could cause the env to be
corrupted, with or without --debug. But as long as it is gone, perhaps
that doesn't matter.
> Is it possible that that bug might affect lshd even without the --debug
> flag? it looks like debug is called regardless of the debug state.
It should not. The debug() function (in werror.c) looks like this:
void debug(const char *format, ...)
{
va_list args;
if (debug_flag)
{
va_start(args, format);
werror_vformat(format, args);
va_end(args);
werror_flush();
}
}
> Examining this closely, I suspect that this is some kind of strange
> interaction, rather than lsh by itself, since the 07s all appear after the
> next shell prompt, and the letters e, x, i, and t (the second exit
> command) are interspersed throughout the 07s. If lsh were spitting them
> out, I'm pretty sure the exit would come after all the 07s.
...
> (testing other shells; csh, tcsh, zsh, pdksh) Hmm... Only happens with
> FreeBSD's /bin/sh, which is based on ash (has most of the features of
> bash).
My guess is that the problem is that lsh leaves the stdio
filedescriptors in non-blocking mode, which is a little unfriendly to
the shell. It seems most shells can cope with that, and reset the fd:s
to a state they can deal with. Perhaps ash don't do that.
/Niels
