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
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
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 the
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
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.
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 u
On Wed, Jun 15, 2011 at 04:31:21PM +0100, Phil Holmes wrote:
> - Original Message - From: "Graham Percival"
>
> >Hmm. Does it only create key-initial.midi, or does it also create
> >key-initial.pdf ? (or .eps, or .png, etc)
>
> According to the output, it also creates *.pdf. However, n
On Fri, Jun 17, 2011 at 10:28:37AM +0200, David Kastrup wrote:
> "Phil Holmes" writes:
>
> > From: "David Kastrup"
> >> The normal behavior for a Unix utility is to write to stderr when
> >> something goes wrong and then bottom out with a non-zero exit status.
> >> Make (or similar tools) stop,
"Phil Holmes" writes:
> From: "David Kastrup"
>> Lilypond is commonly is called from a Makefile and other utilities,
>> obliterating all useful output from them.
>>
>> The normal behavior for a Unix utility is to write to stderr when
>> something goes wrong and then bottom out with a non-zero ex
- Original Message -
From: "David Kastrup"
I would not mind if Lilypond wrote, upon encountering an error, all
locators that are in the input tree concerning the error. Let it be a
dozen. Those are relevant to the error. Easier to sift through them
than two thousand lines not relevan
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc: "Graham Percival" ;
Sent: Thursday, June 16, 2011 9:27 PM
Subject: Re: Patch: small reduction in output from make doc
"Phil Holmes" writes:
TBH, I don't agree at all.
"Trevor Daniels" writes:
> David Kastrup wrote Thursday, June 16, 2011 3:48 PM
>
>> Carl Sorensen writes:
>>
>>> David Kastrup feels pretty strongly that progress messages belong
>>> on
>>> stderr along with warning/error messages, since ther are not the
>>> output of the program.
>>
>> Actually
"Phil Holmes" writes:
> TBH, I don't agree at all. I personally think there's nothing worse
> than a process that takes place in the background and gives no
> indication that anything is happening. I've frequently interrupted
> git grep for this reason - just to see if it's actually doing
> som
- Original Message -
From: "Graham Percival"
To: "David Kastrup"
Cc:
Sent: Thursday, June 16, 2011 5:40 PM
Subject: Re: Patch: small reduction in output from make doc
On Thu, Jun 16, 2011 at 04:48:36PM +0200, David Kastrup wrote:
Actually, I feel progress mes
On Thu, Jun 16, 2011 at 07:07:02PM +0200, David Kastrup wrote:
> Graham Percival writes:
> > and even worse, various "graphical" apps like lilypad, jedit,
> > frescobaldi, etc? I like that idea for normal linux usage, but I
> > don't think we should switch to that system without knowing how it
>
On Thu, Jun 16, 2011 at 06:46:57PM +0100, Phil Holmes wrote:
> - Original Message - From: "Graham Percival"
>
> >On Thu, Jun 16, 2011 at 04:48:36PM +0200, David Kastrup wrote:
> >>Iff stderr is on a tty, there may be some justification to put
> >>out some progress indicators to it, but the
David Kastrup wrote Thursday, June 16, 2011 3:48 PM
Carl Sorensen writes:
David Kastrup feels pretty strongly that progress messages belong
on
stderr along with warning/error messages, since ther are not the
output of the program.
Actually, I feel progress messages belong on /dev/null.
Graham Percival writes:
> On Thu, Jun 16, 2011 at 04:48:36PM +0200, David Kastrup wrote:
>> Actually, I feel progress messages belong on /dev/null. Iff stderr is
>> on a tty, there may be some justification to put out some progress
>> indicators to it, but they should not take useful space: one
On Thu, Jun 16, 2011 at 04:48:36PM +0200, David Kastrup wrote:
> Actually, I feel progress messages belong on /dev/null. Iff stderr is
> on a tty, there may be some justification to put out some progress
> indicators to it, but they should not take useful space: one can
> compress successive progr
On Wed, Jun 15, 2011 at 07:10:55PM +0200, Reinhold Kainhofer wrote:
> On Mi., 15. Jun. 2011 18:51:59 CEST, Phil Holmes wrote:
>
> > I can't say I disagree. As it stands, however, my initial goal is to
> > get the output down to a readable amount full stop - if that means
> > discarding a fe
On 6/16/11 8:48 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> David Kastrup feels pretty strongly that progress messages belong on
>> stderr along with warning/error messages, since ther are not the
>> output of the program.
>
> Actually, I feel progress messages belong on /dev/null.
Carl Sorensen writes:
> David Kastrup feels pretty strongly that progress messages belong on
> stderr along with warning/error messages, since ther are not the
> output of the program.
Actually, I feel progress messages belong on /dev/null. Iff stderr is
on a tty, there may be some justificatio
On 6/16/11 4:05 AM, "Reinhold Kainhofer" wrote:
> Am Mittwoch, 15. Juni 2011, 22:08:21 schrieben Sie:
>> I think there's another problem with this. If I run
>>
>> lilypond test.ly 1> test.log
>>
>> it should redirect non-error output to the file, and errors should appear
>> in the terminal. I
Am Mittwoch, 15. Juni 2011, 22:08:21 schrieben Sie:
> I think there's another problem with this. If I run
>
> lilypond test.ly 1> test.log
>
> it should redirect non-error output to the file, and errors should appear
> in the terminal. In contrast,
>
> lilypond test.ly 2> test.log
>
> errors
2011/6/15 Graham Percival :
> On Wed, Jun 15, 2011 at 06:02:54PM +0200, Reinhold Kainhofer wrote:
>> Hiding all error messages together with the progress messages is throwing out
>> the baby with the bath water (as we say here in German).
>
> Exactly the same phrase in English! We probably stole i
- Original Message -
From: "Phil Holmes"
To: "Reinhold Kainhofer" ;
Sent: Wednesday, June 15, 2011 5:51 PM
Subject: Re: Patch: small reduction in output from make doc
- Original Message -
From: "Reinhold Kainhofer"
To:
Sent: Wednesday, Jun
On Wed, Jun 15, 2011 at 06:02:54PM +0200, Reinhold Kainhofer wrote:
> Am Mittwoch, 15. Juni 2011, 16:22:14 schrieb Phil Holmes:
> > to the end of the call. > redirects output. $*.log expands to
> > filename.log (in this case key-initial.log - this expansion is a make
> > feature). 2>&1 sends err
- Original Message -
From: "Reinhold Kainhofer"
To:
Sent: Wednesday, June 15, 2011 5:02 PM
Subject: Re: Patch: small reduction in output from make doc
Am Mittwoch, 15. Juni 2011, 16:22:14 schrieb Phil Holmes:
2>&1 sends error and normal output to the same place.
On Mi., 15. Jun. 2011 18:51:59 CEST, Phil Holmes wrote:
> - Original Message -
> From: "Reinhold Kainhofer"
> To:
> Sent: Wednesday, June 15, 2011 5:02 PM
> Subject: Re: Patch: small reduction in output from make doc
>
>
> > Am Mittwoch, 15. Ju
Am Mittwoch, 15. Juni 2011, 16:22:14 schrieb Phil Holmes:
> It creates new logfiles, since there is no existing logfile. It uses the
> name of the .ly file to generate the logfile name. So - there is a file
> called key-initial.ly. Part of the build process calls lily to process
> that, and sinc
- Original Message -
From: "Graham Percival"
To: "Phil Holmes"
Cc:
Sent: Wednesday, June 15, 2011 3:35 PM
Subject: Re: Patch: small reduction in output from make doc
On Wed, Jun 15, 2011 at 03:22:14PM +0100, Phil Holmes wrote:
- Original Message - Fr
On Wed, Jun 15, 2011 at 03:22:14PM +0100, Phil Holmes wrote:
> - Original Message - From: "Graham Percival"
>
> To: "Phil Holmes"
> Cc:
> Sent: Wednesday, June 15, 2011 2:42 PM
> Subject: Re: Patch: small reduction in output from make doc
>
- Original Message -
From: "Graham Percival"
To: "Phil Holmes"
Cc:
Sent: Wednesday, June 15, 2011 2:42 PM
Subject: Re: Patch: small reduction in output from make doc
On Wed, Jun 15, 2011 at 02:19:23PM +0100, Phil Holmes wrote:
The attached patch reduces the
On Wed, Jun 15, 2011 at 02:19:23PM +0100, Phil Holmes wrote:
> The attached patch reduces the output from make doc slightly and
> produces some new log files instead. Graham - could you push,
> please? (I have done at least one make doc using it, with no
> problems).
Are you sure that it creates
The attached patch reduces the output from make doc slightly and produces
some new log files instead. Graham - could you push, please? (I have done
at least one make doc using it, with no problems).
--
Phil Holmes
Bug Squad
0001-Redirect-lilypond-output-making-midi-files.patch
Description:
35 matches
Mail list logo