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
stdout vs. stderr (was: Patch: small reduction in output from make doc)
On Thu, Jun 23, 2011 at 01:44:59PM +0200, Jan Nieuwenhuizen wrote: Carl Sorensen writes: it should redirect non-error output to the file, and errors should appear in the terminal. 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 is good news. ... I am *so* confused right now. I have no problem with putting progress messages on stdout, even though that's not the standard for GNU utilities. But I can see where David K. is coming from. Please, don't go there. I think we need to go here. I don't think we should make a formal GOP question for this (since that would delay it by a month or two), but let's get this sorted out. Questions for those involved: 1. what's the official unix definition of STDERR vs. STDOUT? 2. what do most users/programmers think that those names mean, and is it worth following an official definition if it simply leads to confusion? 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) 4. we responded to a request from users to add more spam (i.e. success: compilation successfully completed) a few months ago. There may be a culture clash between unix users and windows users. We can control this behavior with a flag (either -q --quiet, or -s --print-success), but which behavior should be the default? (I note that unix people are more likely to know how to add flags) 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. Cheers, - Graham ___ 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 gra...@percival-music.ca 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
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 make doc)
Graham Percival graham at 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
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 jann...@gnu.org | 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
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 (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 (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
Jan Nieuwenhuizen jann...@gnu.org 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
