Re: non-interactive usage and color error messages

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 28 October 2009, Philipp K. Janert wrote:
> 
> You have a point, that works. I even convinced myself
> that I can do redirection of this form when I call gnuplot
> as a subprocess from Perl:
> 
> open GP, "| /usr/bin/gnuplot >& foo.log " or die "Fail: $!";
> $cmd = "set t png; set o 'foo.png'; plot 'foo' u 1:2 w lp\n";
> print GP $cmd;
> close GP;
> 
> Personally, I find it hacky, and would prefer a way for
> gnuplot to take care of its logging destination itself,
> without having to rely on shell redirection.
> 
> But I admit that the shell redirection works.

It also has the advantage that you can use this mechanism from
a cgi script (web server back end) independent of whether the
gnuplot scripts it calls know anything about the redirection.
I use this to create task-specific log files from the web server
even if the various distinct tasks call the same gnuplot script
somewhere along the way.

But what happened to the impetus for the original complaint?
I understood the problem to be that Octave triggers error messages
that appear on the user's screen, even though the user has no way
to do anything about it.  That does seem worth fixing if there is
a well-defined set of harmless messages that are triggered.
Of course, that fix may lie on the Octave side rather than the
gnuplot side :-)  

I never got an answer to my question of whether gnuplot considered 
itself to be in "interactive" mode while being driven from Octave.
Does it?

   Ethan