Re: names of gnuplot Win32 binaries

[Hans-Bernhard B. <HBB...@t-...>]

Petr Mikulik wrote:

> The primary intention was to achieve better functionality of programs piping 
> commands to gnuplot, like Octave, i.e. an efficient pgnuplot.exe 
> replacement.

Not quite.  Given that pgnuplot itself was always meant as a replacement 
for the missing console, pipe-capable implementation of gnuplot for MS 
Windows.

We're effectively talking about the replacement of a replacement here.

> Thus, what should be the name of this executable?

gnuplot.exe

> Choice 1.
> The executable will be called pgnuplot.exe -- it will replace the current 
> pgnuplot.exe. No change is required for programs using gnuplot as a plotting 
> engine.

There already *is* a change in octave and similar programs right now --- 
the change that if they're running on Windows, they call "pgnuplot" 
instead of "gnuplot".  So we're not really talking about a new change, 
but rather the removal of a previous change.

> Choice 2.
> The executable is called gnuplot.exe. Then, every platform will have an
> executable called gnuplot. However -- this will happen somewhen in future 
> (when gnuplot 4.4 is released).

Why the delay?

> Drawbacks:
> 1. the name clashes with the name of the x11-capable executable 
>    (user/program cannot determine which one gets called)

Which is exactly as it should be.  gnuplot on Linux is called the same 
regardless of whether it's built with wxt or X11 as the default 
terminal.  gnuplot on Windows should be called gnuplot regardless if the 
primary terminal is Windows or X11.

> 2. no piping program is set-up to use gnuplot.exe under Windows, 

So you know for sure that _no_ piping program on Windows expects to find 
the cygwin+X11 (or even a non-GUI) gnuplot.exe?

> Thus, it would at least require to reimplement pgnuplot.c so that it 
> redirects all characters from stdin into gnuplot.exe instead of WinMessages 
> into wgnuplot.exe.

No.  pgnuplot should stay exactly as it is (bugfixes set aside), and 
continue to provide the same service it always did, for programs 
expecting exactly that behaviour.