Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']

[Ralf S. Engelschall]

On Mon, Oct 08, 2007, Julio M. Merino Vidal wrote:

> [...]
> From the screenshots you posted, I don't see how you are piping mtn's
> output to your engine. Did you replace the mtn executable with a
> script that executes the real one and pipes the output?

Yes, OSSP p2 can be either activated via a shell alias (in GNU bash:
alias mtn="p2 mtn") or via automatically generated wrapper symlinks
(e.g. "p2 --generate ~/.p2/wrapper" plus "PATH=~/.p2/wrapper:$PATH").
For interactively entered commands there is no difference. For
indirectly called commands (e.g. "make" executing "gcc" and OSSP p2
should provide error colorization for "gcc") the aliasing doesn't work
and the symlink wrappers have to be used. In the screenshots I used the
wrapper symlink for "mtn", but the alias would just fine, too.

OSSP p2 itself spawns the "mtn" command itself and connects its stdin
to the stdin of "mtn" and intercepts the "stdout" and "stderr" of the
"mtn" command in an I/O multiplexing way. The this way captured outputs
are then passed through one or more plugins which in turn use regular
expression based output post-processing. The plugins theirself can be
either written programmatically as Perl modules or in a declarative way
via an OSSP cfg style configuration file. The "mtn" plugin is coded as a
Perl module. After the output post-processing OSSP p2 sends the output
to its own stdout and stderr channels. This whole approach is a lot more
tricky than it sounds on the first spot because of line-based output
buffering, interrupts through signals, the pager has to read interactive
keyboard input not from stdin but /dev/tty to not conflict with data for
the command on stdin, etc.

                                       Ralf S. Engelschall
                                       address@hidden
                                       www.engelschall.com