lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stdout vs. stderr


From: Graham Percival
Subject: Re: stdout vs. stderr
Date: Sat, 25 Jun 2011 20:19:11 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]