Invalid Configuration Directive

[taskmeister]

I think I have installed PEAR on a 64-bit Vista Installation. However when I perform any of the pear command line activities I receive a warning "Invalid Configuration Directive" which I click an OK button on.

The command line operations seem to function just fine otherwise.

The config-show indicates that I should probably have a pear.ini and pearsys.ini files in my C:\windows directory. However a search of my machine indicates that no pear.ini or pearsys.ini files exist.

I attempted to create a blank set of ini files into the directory and found it required administrative authorization. When I copied files in to that location the command line operations failed with a bad or corrupted configuration file.

Well I guess a blank file isn't what was expected so I am thinking that the installation creates the .ini files and it was unable to because it did not have administrative authority.

Is there a way to build the .ini files or are they not absolutely necessary?

I have a Windows XP machine that built it's own pear.ini so not being certain of the format I am hesitant to attempt an edit build for this machine using that old formatted pear.ini.

[miketux]

I'm in a windows 2003 x64 and the same thing is happening, all the commands works fine, but I recieve that diturbing message.
_________________
Making the web a better place to live.

[mobstergeek]

Fixed, on my system (2003 Server R2 x64 Service Pack 2) with a new install of PHP (5.2.9-1) and the associated PEAR (freshly reinstalled, Mar 30, 2009). While digging into this, I found a few issues:

1. the "pear" folder is actually .\PEAR and not .\pear as everything appears to specify. While I don't believe this contributed to the error, PHP/PEAR on Windows (which doesn't care about case) has a history of inconsistently enforcing proper case. I really think a diligent update should be done for this niggling little issue; in the meantime, I made changes where I found it to be "incorrect." This includes the system registry, php.ini, environment variables set by the batchjob, etc.
   
2. The path information for one of the variables includes an unnecessary "\.\" (current folder) in the path. Again, I don't believe this contributed to the error--it should work without change--but it's redundant, so I removed it where I found it.
   
3. Finally, the message is output by php5ts.dll. While it seems a strangely lazy choice not to indicate WHAT directive is the error, I eventually tracked it down to the :RUN section of pear.bat. To resolve the error, I modified the line with the PHP directive "-d include_path":
   
   • Prepend ".;" before "%PHP_PEAR_INSTALL_DIR%" and don't include my quotes. N.B.: While it seems more efficient, don't change the environment variable itself (%PHP_PEAR_INSTALL_DIR%)--set earlier in the script--it's used in installation detection and will fail if changed.
     
   
   

N.B. I have a tendency to change the installation path of pear.ini; I don't like things living in the Windows folder (php.ini isn't there, so why should pear.ini go there?) so I change it to live under the the same location as php.ini. In the past, this was:

C:\Program Files (x86)\PHP\

but under Vista, you are silently failed (or in some cases redirected) when accessing protected folders, such as "Program Files", "Program Files (x86)", "Windows" etc, unless you've turned off UAC. This will appear to be pseudo-enforced, i.e., you may experience SOME programs can write there but others cannot...so on Vista and later operating systems, it's probably best not to depend on access to these folders. A specific application where this is a problem is the typical WAMP setup.

Good luck.

[randymiller]

I had exactly the same annoying problem, and mobstergeek's solution seems to have resolved it.

I'm running Windows 7 Home Premium 64-bit.
_________________
Thanks! Have a great day!
-Randy

[Pomax]

[mobstergeek]

Agreed; nobody should interpret disabling UAC as an appropriate response. I hope it was clear I was simply highlighting its odd enforcement behavior. IIRC, I had it enabled and--while I could get it installed with my elevated privileges--when I returned from the elevation to my unprivileged account (and, for example, tried to run Apache...which places "htdocs" in--you guessed it--"Program Files") UAC _silently_ stomps all over me. In this case, I might choose/configure different folders, perhaps off the drive's root, rather that turning off security...but first we have to know that's what's happening.

If you, the reader, are still tempted to turn off UAC, consider that I have 25 years of experience, so I'd know how to secure a system without it. If you're tempted to turn off UAC to "solve" the problem...please reconsider. For the record, Windows 7 has it much better implemented than it was on Vista, and ideally, the open software we're using would (by now) have adjusted to the new Windows security model.

Aside: I also came back to this post because I'm scratching my head for running Explorer as admin, since Explorer is the default shell, it prevents dup instances, and that shell would have to be running to provide the right-click interface. Noting that replacing the shell with, e.g., Total Commander might be the ticket, I don't use it (and d/k if it provides Explorer's "Run As User..." interface), and perhaps a console "runas" would get it done, but I wouldn't necessarily recommend all this for the average user.

A best practice in this case might be to logout temporarily, login as (an) admin, install your programs, then re-login as an unprivileged user and continue working, with any "conf" file updates required for those pesky UAC-protected folders. Those of us who use Unix/Linux are quite used to this as a secure way to use our systems, and it's a process I encourage. Alternatively, we can give ourselves explicit privileges to the exact offending files, but that can be an advanced discovery process (interested readers should look into Microsoft's SysInternals suite, e.g., Process Monitor).

Finally, Window's Explorer's context item "Run As Administrator" will NOT function properly if you disable UAC, which (for many) may just be another reason to simply leave UAC alone. The only reason I've ever had for disabling UAC was to use RealVNC...and UltraVNC negates that need.

For what it's worth, this is only intended as a discussion of the environment for the benefit of readers--even this much later--rather than deliberate disagreement with any responses. Cheers!