On 16 Apr 2000, Niels M�ller wrote:
> 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.
It shouldn't hold up 1.0, but my curiosity wants to know :-) Maybe when
I'm caught up on my life, I'll dig into it and figure it out.
> > (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.
Sounds resonable, and not a major issue. This was the deciding factor in
whether or not to install bash on all the machines we support at my
weekend job, though the decision was nearly a tossup without this.
One last thing I've noticed while checking my lsh port for FreeBSD
(we still support one 2.2.8 machine) is that POLLNVAL, POLLHUP, and
POLLPRI aren't defined by jpoll.h, but io.c uses them even if the system
doesn't have poll(), so I can't get lsh to compile on older versions of
FreeBSD.
Is this an issue on all systems that don't have poll(), or have I managed
to find another case where configure on FreeBSD isn't producing the
desired results?
