Thanks SaGS for the following description: (1) In GS_OPTIONS, quotes are treated as regular characters, and not used for quoting spaces. gs\BIN>set GS_OPTIONS=-sDEVICE=nullpage <-/ -sTEST="HAVE -c TEST == SPACES" gs\BIN>gswin32c AFPL Ghostscript SVN PRE-RELEASE 8.55 (2006-05-20) Copyright (C) 2006 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. ("HAVE) Error: /undefined in SPACES" ... Expected behaviour: - use nullpage as initial device; Note: not related to this bug, but otherwise GS tries to install an initial device and fails. Don't know why; in (2) below it doesn't. - set /TEST to <(HAVE -c TEST == SPACES)> (I'm using "<>" for citing, to avoid confusion with quotes in cited text); - display the GS prompt (allows to examine /TEST). Actual behaviour: - use nullpage as initial device; - set /TEST to <"HAVE> (note: with a leading quote); - find <-c> and execute <TEST>, <==>, then <SPACES"> (note: last one has a trailing quote). The <-c> inside the string is only to show what /TEST has been set to, and is not connected to (2) below. Stefan adds: This fails because the parser pushes the GS_OPTIONS onto the argument list, this push mechanism is designed for the -c postscript argument parsing and will parse on spaces rather than do the argc argv argument parsing that regular command line arguments get.
Created attachment 2567 [details] SaGS_patch Thanks to SaGs for this patch. Needs testing with respect to affects on -c parsing.
More comments from SaGS: My [short] explanation of the cause: In the situations above, some text gets "pushed back" into the arguments list. But: (a) Sometimes this text represents a single [already parsed] argument, retrieved by a previous call to arg_next(). In this case, quotes were already found and removed, spaces are part of the argument itself and not a delimiter. When this text is encountered again it should be taken as-is. (b) Other times (GS_OPTIONS) this text is an [unparsed] list of arguments; [only the] unquoted spaces are delimiters. When arg_next() reaches the string it has to parse it normally. (c) Currently arg_next() cannot know if it's case (a) or (b). It does the parsing from the <spaces are delimiters> point of view, but does not do the parsing from the <quotes are for quoting> point of view. IMHO, the <&& f != NULL> (hunk <@@ -172,9 +189,9 @@> in the attached diff) was an [incorrect and partial] attempt to handle (a). Taking <"> as a regular character in GS_OPTIONS is a direct consequence of this. I see absolutely no reason for accepting spaces as delimiters without allowing <"> to quote them. Sincerely yours, Gh. Savulescu
The patch is committed as a rev. 8051. The failure to install display device is unrelated and unaffected by the patch. The content of GS_OPTIONS is executed first. If an error happens there, -dDisplayResolution= and -dDisplayFormat= are not interpreted but these options are required for the display device. Thanks to SaGS for the patch.