|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-14 19:08:57
|
On Thursday 14 July 2005 11:24 am, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> > On Thursday 14 July 2005 10:09 am, Dave Denholm wrote:
> >
> >>I can't remember right now what TERM_CANNOT_MULTIPLOT means : probably
> >>referring to issuing a prompt during multiplot at all.
>
> > Furthermore, the code segment that tests it can never be reached.
>
> For that I'd like to see proof.
My bad.
There is in fact one way to the code path, which is piping to gnuplot
with no arguments on the command line, and no load command involved:
gnuplot < somefile
This is distinct from 3 other cases which one might expect to behave
similarly:
gnuplot somefile
echo "load somefile" | gnuplot
gnuplot
gnuplot> load "somefile"
Here is the analysis:
term_check_multiplot_ok() has only one caller: com_line()
com_line() occurs in only 4 places. Here they are:
misc.c (load_file):
} else if (fp == stdin) {
/* DBT 10-6-98 go interactive if "-" named as load file */
interactive = TRUE;
while (!com_line());
plot.c (main):
618:
if (strcmp(*argv, "-") == 0) {
/* DBT 10-7-98 go interactive if "-" on command line */
interactive = TRUE;
/* will this work on all platforms? */
while (!com_line());
631:
#ifdef _Windows
if (noend) {
interactive = TRUE;
while (!com_line());
}
#endif
} else {
/* take commands from stdin */
while (!com_line());
}
That last "else" condition corresponds to (argc < 1), and is the only
site at which interactive is not guaranteed to be TRUE.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|