Date: Mon, 10 May 1999 09:38:37 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Richard Dawe <richdawe AT bigfoot DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Scrollback in bash?
In-Reply-To: <3735781E.9651454D@meridian22.net>
Message-ID: <Pine.SUN.3.91.990510093810.2882L-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Sun, 9 May 1999, Richard Dawe wrote:

> I guess this question boils down to: Is it possible to capture stdout,
> stderr, etc. and still have them printed to the display?

Any DJGPP program can easily capture its own output using the FSEXT
features.  That's exactly what the ported `ls' does to implement
colored output: it captures stdout and redirects it to direct screen
writes using conio functions.

So Bash could easily capture and stash away its own output (except
that in Bash's case you will need some more trickery to catch handles
other than 1 and 2 that were connected to the screen).

The *real* problem is to catch output of other programs.  You need
either (1) install a real-mode callback that filters Int 21h
functions, or (2) hook Int 31h in protected mode and monitor the
__dpmi_int calls to Int 21h, or (3) implement some low-level machinery
that will allow the parent and child to jump between one and the other
using some ljmp/lcall trickery and hidden parameters a-la !proxy.

The first solution is a royal pain because RMCBs impose a lot of
restrictions: you need to lock all memory touched while in the
callback, so you cannot call library functions (or need to lock
everything and lose virtual memory); and the RMCB stack is too small
for anything serious.

(During one of the related discussions another possibility came up:
use the debugger support in libdbg.a to load and run another program
as debuggers do.  This makes some problems, like jumping between the
two programs, easier, but raises other problems.)

The two other solutions above are, of course, DJGPP-specific, but
otherwise don't have any major drawbacks (at least no KNOWN drawbacks,
that is ;-).  Solution (3) is probably the best one, since hooking Int
31h will make things slow.  But they both require some low-level
infrastructure to be written.

Note that if we implement something like this, we would have done 90%
of work required to allow simulated multi-processing a-la fork/execc
(e.g., by switching context on a __dpmi_int call), signal delivery
between processes (see library function `kill'), and a few other
lucrative features.  There's much more here than just capturing output.

So: any takers?