As not uncommon, RendView writes error and warning messages to
stderr while dumping verbose and debug messages to
stdout.
RendView produces quite a lot of verbose output.
This leads to the following problem: How can you quickly and
easily see (with our eyes on the terminal) what is an error
and what is just verbose output?
The solution was colored output.
By default, RendView turns on colored output if the stdout
and stderr are connected to a terminal. (Switching on/off
the colors is done separately for stdout and stderr.)
I actually do not know if the colors work when you are not using
a linux terminal.
The colors are as follows:
Error messages are written in
bold red.
Warning messages are written in
red (and not bold).
Special verbose messages appear in
bold blue, while
Normal verbose messages get dumped in
blue (not bold) and
debug (verbose) messages get written in normal (black/white) terminal
color.
As you may see, the colors are best viewed on an xterm with
light background (such as light yellow or white). Unfortunately, on
the default terminal with black background all the blue verbose messages
cannot be seen very well. Maybe, I add some code to supply user-defined
highlighting some day...
Options controlling terminal output
There are a few options which allow you to control the terminal
output. Note that all these options cannot take effect before they are
actually read in. For this reason, all the command line
is pardsed in two steps. First, the options presented here are
parsed, then all the others. Same applies to the options in the
RENDVIEWARGS, etc. environment variables. Note that the
env vars are read in after the command line but the command
line still overrides the settings in the env vars.
- -color,-no-color
-
Force colored output on and off, respectively.
- -verbose=SPEC
-
Switch on/off the various verbose message "streams". In fact, all the
verbose messages go to stdout, so there is only one file
"stream", but you can still select which type messages you want.
SPEC is a list of identifiers prefixed by either "+" or "-".
Possible stream identifiers are:
misc: misc info
tdi: task driver init info (start processing/end)
tdr: task driver runtime info (kill/start...)
tsi: task source init info (per-frame blocks...)
tsp: task source param parse/setup info (skipped xy,...)
tsr0: task source runtime info level 0 (less important)
tsr1: task source runtime info level 1 (more important)
tslr: local task source runtime info (file re-naming...)
tsllr: LDR task source runtime info
dbg: debug messages
dbgv: more debug messages
all: all of the above flags
(-all for none, +all for all)
I must admit, that the assigment of messages to streams should probably
get tidied up a bit in the code. Maybe you find messages which use a
different "stream" than they should.
The switch logic is clever enough to also switch off dbgv if you
tell it to switch off dbg and consequently also switches on
dbg if you specify only +dbgv. Same applies to
tsr0 and tsr1.
Example: -verbose=+all-dbg-misc
Note that the spec(s) on the command line override those in an env var.
You may use -verbose=+all-tdi in the env var and then
pass -verbose=+tdi-dbg on the command line and thus
finally get +all-dbg.