Bug 226584

Comment originally by lpd@users.sourceforge.net
I concur with the analysis and proposed fix. All of the utility scripts in lib/ should be reviewed to see whether they have this problem.

Comment originally by undefined@users.sourceforge.net
Logged In: YES 
user_id=16258

app: gs 7.00
os: win 2k
bat: ps2pdf.bat

i want to add that this bug also applies to the
ms-dos/windows bat files (not just the unix script as
mentioned in the original submission).

suggestion: in the "if" statements, do not enclose the
operands in quotes. i'm sure this was done because of null
strings, but the standard method of signifying a
command-line parameter containing spaces as a single
parameter is to enclose the parameter in quotes and this
wrecks havoc on the "if" statements.

you should easily see the problem with this example:
if ""postscript file.ps""==""
the parser sees the "if" keyword and expects to next see the
first operand, an operator, and then the last operand. but
instead the parser sees two consecutive operands: the null
string ("") and then the word "postscript", with no operand
imbetween. the parser throws an error.

instead signify the end of an operand with a forward slash.
(sorry for the long-winded explanation, but being more
familiar with bash scripting than win-batch scripting i
learned all this today and figured i would save someone the
headache of also searching all this out.)

Comment originally by lpd@users.sourceforge.net
Logged In: YES 
user_id=8861

A set of changes fixing this bug has been checked in to the
CVS tree.

The bug is still there at least on linux with the gs command.
If there is a space in the input file name, it gives error (additionally, the error message is not clear). I use backslashes to escape all spaces in file names, as you would do with any linux command.
Even using quotes "" doesnt fix the issue.