On 2/8/06, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
>
> > Any other Ideas?
> >
>
> Yes, buffering the log output for this reason will complicate the code, and we want to switch to dumpcap as the Ethereal capturing engine anyway.
>
> I *might* find some time fixing the remaining dumpcap problems so we might have a solution in the next days. It shouldn't be too much work remaining, most of the problems should already be solved. BTW: This will also slightly simplify the main.c code, as the capture_child detection and handling can be removed.
>
> There's still the remaining problem with the console not available/open on Ethereal/Win32 so you might want to implement the g_log vs. stdout mechanism into the lua plugin, but that's up to you.
I think it is appropriate to do it anyway, I was wondering on whether
it would be a good idea or not to use the console window on unix too.
We could add a [Save...] button to it and have an option to redirect
the console output to a file/series.
I do not see "$ ethereal >outfile" as a nice way to collect the
print()ed output not even on unix. And I believe that most users
would actually loose the output as they might be launching it without
a controlling terminal (e.g. from a menu of the windowing system). I
see stdout always becuase I usualy run ethereal under gdb, but mine is
a special case.
We could add something like "-X warn_out:outfile -X info_out:outfile2
-X critical_out:- " options to redirect the "console" output to files
instead of stdout/stderr as it's now even on tethereal. That way
warnings, logs and so are not mixed with tethereal's output on stdout.
Just few thoughts.
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan