povray
povray copied to clipboard
Port of FS328 - Unlike 3.6.1, 3.7 on does do not allow = char in scene name.
http://bugs.povray.org/task/32
User interface. Linux. No scene file needed. Command: povray one=two.pov
Details:
The following command fails with parsing error:
povray +OqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw==.png +IqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw==.pov +W1000 +H1000
The following command succeeds:
povray +OqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw.png +IqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw.pov +W1000 +H1000
Any option that gets a filename as parameter will fail if it contains '='.
It is a regression, as it worked fine with 3.6
Notes.
I'm getting a segmentation fault. As mentioned it happens with more than scene file names. I just triggered it with the command line typo:
File_Gamm=sRGB
Where typing:
File_Gamma=aRGB
Triggers a failed to parse message.
Tracked part of the issue here to the following call in vfe/vfecontrol.cpp :
if ((err = options.ParseString (i->c_str(), &obj)) != kNoErr)
where it should be:
if ((err = options.ParseString (i->c_str(), &obj, true)) != kNoErr)
because we are passing command line arguments one at a time and the ParseString default is false.
With the change above stuff like File_Gamm=sRGB now comes back with a parse error instead of a seg fault.
There is unfortunately some issue behind the first (v37 or v38) where if one uses say:
+ohmm=2.png
you end up with and output file with single quotes around it like: 'hmm=2.png' where if you do:
+ohmm.png
you get an output file of hmm.png as one might expect. So... there is still some issue with the '=' chars and file names to be sorted out. Should also look at +L flags too as reasonable to expect they are getting mangled too, but who knows. Not able to look at the issue behind the issue at the moment.
Lastly, I don't have windows so didn't test it, but it looked like windows might have been OK at least by some command line to parsing paths. At least one method correctly used true on the ParseString call.
Good find ... I'll take a closer look and see if I can locate a workaround or fix that works on all platforms.
@chris20 Any news on this?
For the records: I'll file this as "long-standing issue that we haven't found a simple solution to yet, so we sure don't want to tackle it in a hurry while we prepare for v3.8.0 release".
See too:
[BUG][UNIX] Failed to parse command line option with space in filename #448