Re: stdout vs. stderr (was: Patch: small reduction in output from make doc)
in C++ there's std::cout, std::cerr and std::clog, and I use all three in my private projects. p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stdout vs. stderr
Jan Nieuwenhuizen writes: > Graham Percival writes: > >> I think we need to go here. > > No. There will be no progress, warning or error messages to stdout. stdout is usually line-buffered (like stdin), so progress messages are not really useful. The GNU utilities take the distinction between normal output and diagnostics seriously enough that ps -b will output a complete usage info along with an error message to stderr (because the option is wrong, and the usage info is part of the error output) while ps --help will output the complete usage info to stdout (since it is the regular output of this option). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stdout vs. stderr (was: Patch: small reduction in output from make doc)
Am Samstag, 25. Juni 2011, 20:09:50 schrieb Matthias Kilian: > On Sat, Jun 25, 2011 at 05:27:03PM +0100, Graham Percival wrote: > > 1. what's the official unix definition of STDERR vs. STDOUT? > > Quoting the standard: > > 3.358 Standard Error > An output stream usually intended to be used for diagnostic messages. > [...] > > 3.360 Standard Output > An output stream usually intended to be used for primary data output. > > Of course, this definition is meant for typical unix command line > tools, where you want to pipe the output of one program as input > into another program and still see "diagnostic messages" from the > first program. Lilypond is a little bit different. Many GNU applications work like that. On the other hand "tar -v" print the processed filenames to stdout (not to stderr!). (la|pdf|)tex on the other hand prints everything to stderr, so as a user you have no other choice than either silencing tex altogether (i.e. using batchmode) or having the whole excessive output on the console... There is no way (at least none that I'm aware of) to separate the warning messages of latex from the excessive debug output about including file X and file Y and graphics Z etc Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stdout vs. stderr (was: Patch: small reduction in output from makedoc)
Am Samstag, 25. Juni 2011, 19:21:53 schrieb Phil Holmes: > I think we need to cover it properly - based on past experience it's likely > to generate some heated discussion. Yes, I also think that we should properly discuss the console output of lilypond and probably different log levels. > I also think we should discuss general "quietening" of make. Should it > always generate as little output as possible, consistent with seeing > errors, or should that be restricted to when using the QUIET_BUILD flag? I would prefer having a quieter build by default. Usually, the build will run without any problems, then you don't need the excessive debug output we currently have. And if a problem makes the build fail, it is usually pretty obvious what the problem is. And for more intricate problems, you can always run another build with verbose output to easier debug the problem if it is not obvious anyway. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stdout vs. stderr
On Sat, Jun 25, 2011 at 08:58:43PM +0200, Jan Nieuwenhuizen wrote: > Graham Percival writes: > > > I think we need to go here. > > No. There will be no progress, warning or error messages to stdout. But we *do* have progress messages on stderr. This makes sense to some people, but doesn't make sense to others. Maybe I should clarify -- by "go here" / "go there", I mean "we need to have a serious discussion about this". I'm not advocating for any particular decision; I just want to clearly understood what the question(s) and answer(s) are. If the final decision is "unix standard says that progress messages should be on stderr, and that is what we shall do", then I certainly won't complain! > > 3. do we believe in the general unix statement "no news is good > > news", in which case why does "lilypnond foo.ly" spam out 16 lines > > of text? (regardless of whether that spam happens on stderr or > > stdout or stdstrangequark) > > I used that to try to make the distinction clear. We're past > that stage, and it is not uncommon to print progress messages > to stderr so that the user knows what's going on. A --quiet > flag could be a feature. Yes, definitely. > > 4. we responded to a request from users to add more spam (i.e. > > "success: compilation successfully completed") a few months ago. > > Yes, that made me frown a bit. I think responding to user > requests is very important, however it's equally important > not to implement misguided features. Judging this is your > task, the user is free to ask for stupid things. When it comes to notation, I think our general policy has been "by default we do what you *should* want, but if you want bad output, here's how to do it with scheme callbacks". I see no reason to argue against misguided features (as long as they are not the default behavior) when it comes to command-line handling. Do you think we should remove all progress messages on stderr? (i.e. make a hypothetical -q flag the default behavior) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stdout vs. stderr
Graham Percival writes: > I think we need to go here. No. There will be no progress, warning or error messages to stdout. > 3. do we believe in the general unix statement "no news is good > news", in which case why does "lilypnond foo.ly" spam out 16 lines > of text? (regardless of whether that spam happens on stderr or > stdout or stdstrangequark) I used that to try to make the distinction clear. We're past that stage, and it is not uncommon to print progress messages to stderr so that the user knows what's going on. A --quiet flag could be a feature. > 4. we responded to a request from users to add more spam (i.e. > "success: compilation successfully completed") a few months ago. Yes, that made me frown a bit. I think responding to user requests is very important, however it's equally important not to implement misguided features. Judging this is your task, the user is free to ask for stupid things. > 0. (meta-question) do we think that we can resolve this once and > for all right now That's what I tried to do. Fix outputting to stdout (read from stdin means write to stdout, also have -o - write to stdout); for .svg that may make sense. Jan. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stdout vs. stderr (was: Patch: small reduction in output from make doc)
Graham Percival percival-music.ca> writes:
> >
> > Stdout is used for valuable program output, stderr for any kind of
> > message, including progress. The name stdERR is possibly somewhat
> > unfortunate and comes from the days that unix commands would only
> > print something (to stdERR) if there was an error. No news
> > [was considered to be] good news.
And now that users want some good news "successful completion" messages, we
still want it to be separate from the program output on stdout. I still want
to use :
\displayLilyMusic \transpose f d \relative c' {
\key des\major
des\p\< f as des\f
}
c:\> lilypond test > transposed_motif.ly
>
> Questions for those involved:
What does Lilypond currently put on stdout ?
The output of \displayLilyMusic and \displayMusic; anything else?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stdout vs. stderr (was: Patch: small reduction in output from make doc)
On Sat, Jun 25, 2011 at 05:27:03PM +0100, Graham Percival wrote: > 1. what's the official unix definition of STDERR vs. STDOUT? Quoting the standard: 3.358 Standard Error An output stream usually intended to be used for diagnostic messages. [...] 3.360 Standard Output An output stream usually intended to be used for primary data output. Of course, this definition is meant for typical unix command line tools, where you want to pipe the output of one program as input into another program and still see "diagnostic messages" from the first program. Lilypond is a little bit different. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stdout vs. stderr (was: Patch: small reduction in output from makedoc)
- Original Message - From: "Graham Percival" 0. (meta-question) do we think that we can resolve this once and for all right now, or should we wait a month to cover it as a GOP-PROP ? If we discuss it now, then I do *not* want to have it left hanging (as we've done the last 3-4 times we discussed it). I want to have a definite decision; I personally don't care what that decision is. I think we need to cover it properly - based on past experience it's likely to generate some heated discussion. I'd go with "wait a month and have it as a GOP-PROP". I also think we should discuss general "quietening" of make. Should it always generate as little output as possible, consistent with seeing errors, or should that be restricted to when using the QUIET_BUILD flag? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
