Message-ID: <357D521A.DF04200B@CGSTE.MQ>
Date: Tue, 09 Jun 1998 11:17:46 -0400
From: HANRIGOU <HANRIGOU AT cgste DOT mq>
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: spector AT EnchantedLearning DOT com, djgpp AT delorie DOT com
Subject: Re: Bash hangs -- to be continued...
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980604211752 DOT 2197Z-100000 AT is> <35775F4A DOT 40F0 AT EnchantedLearning DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Eli and Mitchell!

I'm back! excuse me for not having responding before... I've had (and
I'm still having) big problems with my internet access: 
my administrator share a unique RNIS line between our internet provider
and a "weather" server. For the moment we're connected almost all the
time to the "weather" server, because we must be aware of every
hurricane that would be forecasted (in the french West-Indies). That's
why I haven't been able to mail you before. If you mail me, it's
still possible that your message returns back to you (we haven't solve
this unique RNIS line problem yet).

Eli Zaretskii wrote:
>
> I'm still trying to understand the problem you both had with bash
> hanging.  I woul really appreciate if you could check whether the
> same happens for you with Less, or Emacs, or Info from the latest port
> of Texinfo 3.12. 
I've done the tests for you. But I've got no new information,
in fact I've got exactly the same behaviours as those described by 
Mitchell.

Mitchell Spector wrote:
> Specifically, when
> running in a Win95 DOS box, when I type
> 
> !command
> 
> (where command is some djgpp program), the command is executed
> correctly, less prints
> 
> !done (press RETURN)
> 
> and the DOS box then hangs, in the same way bash does.
> 
Same thing for me.

Mitchell Spector wrote:
> When I run just DOS, without running Windows 95, less works as
> it should, without hanging in that situation.  This again is just
> what bash does, working correctly under plain DOS.
Idem.

Mitchell Spector wrote:
>   I did as you suggested.  The version I compiled with the
> -DREPLACE_YIELD switch worked perfectly; the version compiled
> without the switch hung in apparently the same way as bash and
> less.
Again, it do work for me.

Note: Since last month I've been using a bash compiled with every
__dpmi_yield call stripped, and it works perfectly (If you don't 
consider its ugly idle behaviour, of course ;-))

Nevertheless Eli's redefinition of __dpmi_yield seems to be more
interesting :-)

> Eli Zaretskii wrote:
> #ifdef REPLACE_YIELD
> void
> __dpmi_yield(void)
> {
>   __dpmi_regs r;
> 
>   r.x.ax = 0x1680;
>   __dpmi_int(0x2f, &r);
>   if (r.h.al != 0)
>     errno = ENOSYS;
> }
> #endif

Does it really give CPU control to other programs?
How does __dpmi_int works? What happens after running a child 
process (as opposed to previous __dpmi_yield definition)?

Kind regards,
Philippe.