POV-Ray

The Persistence of Vision Raytracer (POV-Ray).

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.

Tasklist

FS#42 - command line parameters are not parsed properly on Unix

Attached to Project: POV-Ray
Opened by Christoph Lipka (clipka) - Thursday, 16 July 2009, 19:05 GMT
Last edited by William F Pokorny (wfpokorny) - Saturday, 05 November 2016, 12:19 GMT
Task Type Definite Bug
Category Frontend → Other
Status Tracked on GitHub
Assigned To Chris Cason (chrisc)
Operating System Unix
Severity Medium
Priority Normal
Reported Version 3.70 beta 32
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

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 task depends upon

Comment by Thorsten Fröhlich (thorsten) - Sunday, 20 June 2010, 05:49 GMT

This is a platform specific code issue. POV-Ray's internal command-line parser can handle both as needed. The method ProcessOptions::ParseString offers a parameter to handle this case correctly.

Comment by Andrey Zholos (aaz) - Thursday, 19 May 2011, 11:46 GMT

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.

Comment by Christoph Lipka (clipka) - Friday, 26 August 2011, 00:37 GMT
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).
Comment by Thorsten Fröhlich (thorsten) - Wednesday, 05 September 2012, 04:35 GMT
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.

Comment by William F Pokorny (wfpokorny) - Saturday, 05 November 2016, 12:19 GMT
  • Field changed: Status (Assigned → Tracked on GitHub)
  • Field changed: Due in Version (3.70 release → Undecided)

Now tracked on github as issue #145.

Loading...