The best way to explain this bug is by describing how to reproduce it. Put this in a file called "foo.ps": ---cut here--- %!PS 0 0 moveto 72 72 lineto stroke showpage ---cut here--- 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: GS>GS>GS>GS>GS>GS> With ghostscript-6.51-6, you will see this: GS> 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"): ---cut here--- #include <sys/types.h> #include <stdio.h> #include <unistd.h> main() { int real_position = lseek(fileno(stdin), 0, SEEK_CUR); int stdio_position = ftell(stdin); printf("really = %d, stdio = %d\n", real_position, stdio_position); } ---cut here--- 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 using c++.
As gs is dynamically linked against libstdc++, this should work with libstdc++-2.96-98 and above (I've even tried it).