#1756 pipe out line ending problem on windows

[Anonymous]

Using version 5.0.3 on windows, suppose that we have the following python3 program (test.py):

from sys import stdin
data = stdin.buffer.read(None)
open("test.png","wb").write(data)

This program simply reads from the standard input binary stream and writes what it sees into test.png. For example type sample.png | test.py effectively copies sample.png into test.png.

Now suppose that we run the following commands in gnuplot

set term png
set output "| test.py"
plot sin(x)
set output

this will create a plot and pipe it through that python program. However, the resulting png is unreadable. After some investigation, I discovered the problem is that the file that is written out using the normal output methods (set output sample.png) differs from the piped version in that every occurance of "\n" in the good version is replaced by "\r\n" in the bad version. In other words, every newline in the good version is replaced by the windows newline in the bad version.

I don't know if the fault lies with Windows or with gnuplot here. I suspect that gnuplot is translating the newlines itself. This is exactly what should be happening for text output, but is not desireable for binary output. It is possible to replace the bad newlines with good newlines with another process (set output "| fixnewlines.py | test.py" where fixnewlines simply replaces "\r\n" with "\n"), so there is a workaround, but it is a bit of a hack.

Obviously, this example isn't particularly useful. There is no reason to pipe through a program that simply writes the results to disc, but similar scenarios exist where we may be piping through a conversion program, a server, or any number of things. This example is useful for illustrating the problem, however.

There should be a way to turn off the newline behavior in this case - possibly a command like set lineendings unix where the normal windows behavior could be restored with set lineendings windows. There may be such an option but if there is, I am unaware of it.

[Shigeharu TAKENO]

The change for src/term.c may not be correct on FreeBSD or NetBSD. BSD's popen see the second character of second argument and "wb" is incorrect on BSD. Popen manual of FreeBSD says:

The type argument is a point to a null-terminated string which masut be 'r' for reading, 'w' for writing, or 'r+' for reading and writing.

In fact, "set out '| command'" failed and png data was put out to stdout on FreeBSD.

[Matthew Halverson]

My original patch to term.c was simplified by Bastian Märkisch by applying the same modes on all platforms before it was committed. Originally I had sought to keep the behavior the same as in the existing code except for on windows. With the note about FreeBSD and NetBSD, it may be necessary to apply that approach and test for the OS again.