The best way to explain this bug is by describing how to reproduce it.
Put this in a file called "foo.ps":
0 0 moveto
72 72 lineto
It actually doesn't really matter what you put in this file, as long as
it's a short, valid PostScript program.
Now, run this command:
(cat > /dev/null ; gs -dSAFER -dNOPAUSE -q -sDEVICE=ljet4
-sOutputFile=/dev/null foo.ps; echo '') < foo.ps
With ghostscript-6.51-10, you will see this:
With ghostscript-6.51-6, you will see this:
That is, it will only print one prompt instead of six. Why the
difference? Because for some reason, ghostscript-6.51-10 is rewinding
stdin and reading the data in foo.ps, even though the "cat > /dev/null"
command has already read it. I narrowed this down to sread_file in
sfxstdio.c. It appears that ftell(file) is returning 0 on stdin even
though stdin's real position is not 0.
You can duplicate this problem outside of ghostscript by compiling this
simple test program with c++ instead of cc (i.e., "c++ test.c"):
int real_position = lseek(fileno(stdin), 0, SEEK_CUR);
int stdio_position = ftell(stdin);
printf("really = %d, stdio = %d\n", real_position, stdio_position);
Then run "(cat; ./a.out) < foo.ps" (where "foo.ps" is as shown above, or
heck, you can use any file you want), and you'll see that the "really" and
"stdio" numbers are different. If you compile the same program with cc,
the numbers are the same.
This suggests that there is a bug in the C++ libraries, and I will file a
separate bug report about that, but until it's fixed, the omni patch should
probably be removed from ghostscript unless it can be made to link without
As gs is dynamically linked against libstdc++, this should work with
libstdc++-2.96-98 and above (I've even tried it).