Hello all,
This is in response to David Kastrup.
- startup and shutdown messages. These are not usually omitted to stderr, or at
least 99.99% of the tools out there do not do it. Most tools actually *have no*
startup and shutdown messages. If you have other info then I'd appreciate a list
of famous tools which emit startup and shutdown messages to stderr (and I'm not
talking about daemons but regular command line tools). I doubt that you will
find any and most of the ones which you will find will have bug reports filed
against that behavior.
To prove my point here is gcc:
m...@cantor:~$ gcc -o test.o test.c
m...@cantor:~$
No startup/shutdown messages. No version. No progress. Quiet and nice. This is
the default behavior as no --quiet flag was required to enforce it.
Compare this to the lilypond behavior:
m...@cantor:~/links/lilypond$ lilypond test.ly > out
GNU LilyPond 2.12.3
Processing `test.ly'
Parsing...
Interpreting music... [8][16][24]
Preprocessing graphical objects...
Interpreting music...
MIDI output to `test.midi'...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `test.ps'...
Converting to `./test.pdf'...
m...@cantor:~/links/lilypond$
Wow! This is all standard error messages (as the redirection above proves) and
none of these are errors.
- stderr is called stderr and not stddiag since it is intended for errors. I
agree that stdout is intended for further processing but lilypond *does not*
create any further data for further processing so stdout could be used for
version and other stuff much like other tools. To prove my point here are a
bunch of tools:
m...@cantor:~$ ls --version > out
m...@cantor:~$ grep --version > out
m...@cantor:~$ nm --version > out
m...@cantor:~$ gcc --version > out
m...@cantor:~$ as --version > out
m...@cantor:~$ make --version > out
m...@cantor:~$ ld --version > out
m...@cantor:~$
The list could go on and on. This output proves that version info goes to stdout
and not stderr and that stderr is quiet *all the time* unless errors occur. No
startup message. No shutdown message. No progress reports. No "mighty gcc
version 4.5 was here" messages.
In summary:
stderr is for *errors* and not *diagnostics*. Seeing two pages of data in stderr
(which is the current situation by the way) is absolutely counter productive. It
may be cool for developers who want to understand where a problem occurs but it
is useless to users. If someone has to suffer from supplying an extra flag it
should be the developers and not the users (as a general rule). This is actually
what forces every big project that I saw to wrap the lilypond executable with a
script (which is really bad!).
All that being said I don't really care about version info, startup and shutdown
messages and the rest at all - You can keep directing them to stderr if you feel
like it - *just as long as they stay out of my way* - meaning that I have an
easy to use option to disable them. The current implementation has no option to
keep them out of my way and this option should actually be the default (as
demonstrated for all the standard tools above). And again, there is also
progress data there so what is the end result? When compiling 20 big lily files
which are perfectly fine I'm getting 10 pages of output which is useless to me
since I have no mental wish to process it instead of 20 lines of compilation.
I'm solving this with a wrapper that hides this useless output from me but I
expect every serious lilypond user has written a wrapper for him/her self.
Cheers,
Mark
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
