POV-Ray : Newsgroups : povray.beta-test : Re-discovering issues with finding ini files in library path : Re: Re-discovering issues with finding ini files in library path Server Time
19 Jun 2024 16:07:49 EDT (-0400)
  Re: Re-discovering issues with finding ini files in library path  
From: William F Pokorny
Date: 15 Apr 2024 22:49:13
Message: <661de729$1@news.povray.org>
On 3/20/24 01:49, William F Pokorny wrote:
> With that change I'm able to run the following (reminder yuqk is 
> linux/unix only):
>      yuqk playpen.pov include_ini="quickres.ini[1024x768, AA 0.3]"
> or
>      yuqkZ playpen.pov +ini"quickres.ini[1024x768, AA 0.3]"
> Of course, with that set up you can then only reach local directory ini 
> files afterward because those are all that will be found.

First, as an addition to the previous post, I should have added as a 
footnote that using include_ini= (*) or +ini with a full path or 
complete relative path specification for ini files works.

Today. These options are in fact the only way other than copying all the 
ini files you need into the local rendering directory to be sure(**) you 
find ini files (other than install or user-local povray.ini) correctly.

(*) - The include_ini= option exists today in official releases, but 
isn't documented.

(**) - This isn't the same as saying the current ini mechanism doesn't 
often work. Of course, this is an ugly position to be in as it means the 
ini behavior, where other than having all same directory ini file(s), is 


The above said, the aim of this post is to document that I've found 
issues with ini parsing error reporting when ini files are directly 
included! :-(

(Yes, now guessing that, not documenting 'include_ini=' might have been 
some sort of a 'delay for fixes' which never happened.)

Basically, ini files included via this mechanism can have serious 
parsing issues which end up completely ignored in official releases of 
POV-Ray (Linux / Unix versions at least). They are 'somewhat ignored' 
with current releases of the yuqk fork.

The yuqk fork reports the parsing problems with additional text messages 
where official releases usually don't. However, today in released yuqk 
versions up to R13, the parsing still doesn't stop on finding serious 
issues. The bad error return code gets eaten / overwritten due how the 
include_ini= option was originally implemented.


Because it's part of the 'ini' tofix pile and related, I'll toss out 
again that the ini directory ordering, as affected by library paths, is 
glitch-y. We should not be using the library search paths for ini files 
at all, but rather only for include files.

It believe it should always have been another path set up mechanism for 
ini files (perhaps an INIPATH env var similar to PATH?). Or, no path 
searching at all and just include_ini= or +ini usage. This latter 
approach is how I plan to go with yuqk - though I've not yet worked out 
the code changes to disable to sometimes searching of the library path 
for ini files, so we'll see.

Bill P.

Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.