On 4/19/12, Ihar `Philips` Filipau <[email protected]> wrote: > On 4/19/12, Albert Astals Cid <[email protected]> wrote: >> >> That is a problem, since we can't limit the characters to only >> alfanumeric for filenames :D >> > > LOL. > > Well, shell escape then? As it turned out, on Windows one can simply > use double quote around the parameters - double quotes are illegal > characters for files names there. cmd.exe on my WinXP and Win7 handle > them as expected (e.g. `dir "_vim""rc"` is the same as `dir "_vimrc"` > is the same as `dir _vimrc`). (IOW, on *nix shell escape as in > previous patch, on Windows - simply wrap in double quotes.) > > Actually shell escaping can be seen as an independent fix: the gs > command line generation already tries to wrap the file names using > double quotes. And with the knowledge of how it works on Windows, the > choice of the double quotes doesn't seem to be arbitrary. E.g. from > debug output (my backslashes; bad device name is quoted as per my > previous shell quote patch): > > gs -sDEVICE='"'\''jpeg'\''"' -dBATCH -dNOPROMPT \ > -dNOPAUSE -r108 -sOutputFile="Der Mond%03d.jpeg" \ > -g892x1263 -q "Der Mond.ps" >
Here is a patch which extends shell escape to cover: device name, output file name, ps file name. Win32 part was /tested/ on *nix with my eyes. And as it turned out (live and learn) cmd.exe has a command separator - &, accidentally a valid file name character - and it too has to be escaped. Guess what's escape character? 3... 2... 1... Wrong - it's '^', which itself has to be escaped too. Have fun. _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
