povray icon indicating copy to clipboard operation
povray copied to clipboard

Port of FS328 - Unlike 3.6.1, 3.7 on does do not allow = char in scene name.

Open wfpokorny opened this issue 8 years ago • 6 comments

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

wfpokorny avatar Oct 15 '16 17:10 wfpokorny

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.

wfpokorny avatar Jul 25 '20 12:07 wfpokorny

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.

wfpokorny avatar Aug 06 '20 19:08 wfpokorny

Good find ... I'll take a closer look and see if I can locate a workaround or fix that works on all platforms.

chris20 avatar Aug 13 '20 06:08 chris20

@chris20 Any news on this?

c-lipka avatar Jun 11 '21 10:06 c-lipka

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".

c-lipka avatar Jun 16 '21 13:06 c-lipka

See too:

[BUG][UNIX] Failed to parse command line option with space in filename #448

wfpokorny avatar Sep 03 '22 09:09 wfpokorny