[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [logcheck] I hear you...

>>>>> "Wouter" == Wouter Verhelst <wouter@debian.org> writes:

    Wouter> On 25 Nov 2001, Karl M. Hegbloom wrote:

    >> How about:
    >> [    ] Starting: foo bar baz ...
    >> ... then if it's OK, write the green "Ok" inside the brackets?

    Wouter> That's not always possible. You're assuming that output of
    Wouter> initscripts will never be more than one line, which is not
    Wouter> true.

 Perhaps what would need to be done for that is that the entire screen
 would need to be under the control of a process that can move the
 cursor at will, etc.  It would capture all subprocess and kernel
 printk output, and display it in some interesting and orderly way.
 Rather than the jumble we get when more than one thing tries to print
 to the console at the same time, we'll then have an orderly and
 readable display.

 The LSB mentions that they indend for the startup scripts to be
 parallelizable.  A simple implementation might use "make" as a
 driver... but anyone who has built, say, the Linux kernel, with "-j
 32", knows that the several instances of the compiler print whenever
 they feel like it, and all output is mixed together.

 The only way around that is to redirect every command to some file or
 something... it's totally unweildy, and thus a special purpose
 program is required to manage this...

 They specify comments with headers that declare "provides" and
 "depends" relationships, much like makefile targets.

 What if we have a nice hires framebuffer and display postscript or
 TeXmacs type display typesetting engine?  Wow, it sure could be made
 to look good.  On the fly PDF anyone?  In designing this, let's keep
 in mind that the display layer might someday need to evolve in that

 I suppose that it ought to have a display layer separate from the
 logic that manages the subprocesses and captures their output...

 Framebuffer GTK?  Newt?  Ncurses?  Bogl?

 There should be a way to interrupt one that's hung; but how to pick
 which one it is when several are fired off at once?

 In the "debian-installer" there's a little library begun where
 there's a function that's for running a shell command and logging
 it's output.  The other day I was looking at that, and started
 rewriting it.  I'm trying to make it capture stdout and stderr of the
 shell command on separate channels, which means foregoing "popen" and
 implementing that myself... anyway, I've never done anything like it
 so cannot say how it will eventually turn out.  (and I suppose that a
 careful study of "screen" and "emacs" are in order...)

Reply to: