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
direction!
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: