Le_Forgeron <jgr### [at] freefr> wrote:
>
> Would have the command line splitted by argument (hence displaying:
> * povray
> * spine.ini[Atlas
> * superior]
> * rainbow.ini
> ) helped ?
>
> I'm afraid line-feed might not be the right character to use, IIRC my
> very long command line.
>
> May be some other markup around each element ?
> (it's in vfe/unix/unixconsole.cpp circa line 541)

A parse tree might be overkill (although it would have helped in this particular
example), and yet wouldn't necessarily give sufficient helpful information.  You
can split "povray nexiste[pas]" any way you want, but that won't tell you that
the file is in a different directory.  The way POV-Ray 3.6 handles command line
errors is fine.  Why was it changed?

This is sample output from a POV-Ray 3.7 call:
______________________________________________________________________

ricky@linux-g9n0:~/Documents/POV-Ray/vseries> povray nexiste[pas]
povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is
discouraged.

Problem with option setting
povray nexiste[pas]
Failed to parse command-line option
______________________________________________________________________


This is sample output from a POV-Ray 3.6 call ("povray36" is aliased to the 3.6
executable):
______________________________________________________________________

ricky@linux-g9n0:~/Documents/POV-Ray/vseries> povray36 nexiste[pas]
Could not find file 'nexiste.ini'
Cannot open INI file 'nexiste'.
Cannot process command-line due to a parse error.
This is not a valid command-line. Check the command-line for syntax errors,
correct them, and try again!
Valid command-line switches are explained in detail in the reference part of the
documentation.
To get a short list of command-line switches, use either the '-h', '-?', '-help'
or '--help' switch.
Failed to render file due to error(s)!
______________________________________________________________________

The first two lines of the 3.6 error message tell me exactly what I need to
know.

Come to think of it, maybe I should just use 3.6 whenever I run across a problem
like this.  Nevertheless, this won't help where the front end changes, such as
with new command line switches, new quotation mark behavior, or new bugs.  It's
also a rather kludgey way to handle a problem with a new and improved software
version.

Post a reply to this message