This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Details

POV-Ray does not follow common practice on command-line handling; for instance:

povray +i"My File"

entered on a Unix shell would be passed to POV-Ray as

povray
+iMy File

(each line representing a distinct parameter here), which POV-Ray would further dissect, interpreting it as

povray
+iMy
File

To achieve the desired effect, one would actually have to quote the string twice:

povray +i"'My File'"

which the shell would translate to

povray
+i'My File'

which POV-Ray would interpret as

povray
+iMy File

In both cases, this is obviously not what a Unix user would expect.

The further dissecting of individual command-line parameters may have had its valid roots in the peculiarities of DOS’ command-line handling, but to my knowledge all major contemporary operating systems follow a concept akin to Unix, passing a list of parameters instead of a monolithic command line, and burdening the respective command shells with the task of dissecting command lines into parameters.

Therefore I suggest to disable this anachronistic feature in favor of contemporary standards; a compiler flag might be used to allow for easy re-enabling of the feature, for compiling POV-Ray on exotic targets.

- edit -

It has been pointed out that the described behaviour differs from 3.6, so I’m promoting this to a bug and changing the title.

This is a platform specific code issue. POV-Ray's internal command-line parser can handle both as needed.

Not really, at least if you consider vfeSession::SetOptions(...) in the generic vfecontrol.cpp as part of POV-Ray's internal command-line parser. That's where ProcessOptions::ParseString(...) is called from, but it never passes the singleswitch parameter (so it always defaults to false).

Another parsing problem:
$ povray Declare=\'foo=\"bar\"\' # works
$ povray Declare=foo=\"bar\" # doesn't work
Passing the singleswitch flag to ParseString solves this, but I think the second form should be accepted even without singleswitch.

It can't detect this without singleswitch because the quotes get removed otherwise. Then it is faced with an ambigious "Declare=" "foo=" "bar" and can't know "bar" is meant to be a string in the tokenizer without singleswitch.

– The best approach to recommend to any user when passing INI paramaters on the command-line (which is a very non-standard feature!) would be the recommendation to quote them as a whole.