Hi folks
Some recent discussion on Stack Overflow has revealed another exciting
way for Windows computers to be subtly broken.
For as yet unknown reasons - probably related to security/virus scanner
software, since everything else seems to be - some Windows machines have
an invalid COMSPEC environment variable.
Two variants have been sighted in the wild:
%SystemRoot%\system32\cmd.exe;
(note the trailing semicolon), and:
C:\Windows\System32
Both will produce the delightfully helpful initdb failure:
initdb: could not execute command ""C:/Program
Files/PostgreSQL/9.2/bin/postgres.exe" --boot -x1 -F ": No error
while running:
cscript //NoLogo "C:\Program
Files\PostgreSQL\9.2/installer/server/initcluster.vbs" "NT
AUTHORITY\NetworkService" "postgres" "****" "C:\Program
Files\PostgreSQL\9.2" "C:\Program Files\PostgreSQL\9.2\data" 5432 "DEFAULT"
which will exit with:
Script exit code: 1
In the one I was looking into, fixing COMSPEC in the System control
panel's Environment Variables page by removing the trailing semicolon
corrected the issue. It can be verified as correct by opening a new
command prompt after you've changed the variable (not just re-using an
existing already-open one) and running:
"%COMSPEC%" /C "echo test ok"
which should print:
test ok
not something like:
'"C:\Windows\System32\cmd.exe;"' is not recognized as an internal or
external command,
operable program or batch file."
Since I can find several reports of this spanning over a couple of
years, I'd love to see a test for this integrated into the EDB
installer. Just verify that popen() actually works before running the
initdb script, and if it doesn't, check %COMSPEC% to see if it really
points to cmd.exe .
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services