Last modified: 2010-05-15 15:38:08 UTC
When config/index.php is trying to find what $conf->diff3 should be set to, it does not handle Windows PATH correctly. The original code says $diff3locations = array("/usr/bin", "/opt/csw/bin", "/usr/gnu/bin", "/usr/sfw/bin") + explode (":", getenv("PATH")); but on Windows, the separator between the drive specifier and the path is a colon. And multiple items in the PATH variable are separated by semi-colons. So, that line of code, for Windows, should read $diff3locations = array("/usr/bin", "/opt/csw/bin", "/usr/gnu/bin", "/usr/sfw/bin") + explode (";", getenv("PATH")); Obviously the right answer is to make the separator string in the explode paramater list be dependent upon the operating system that PHP is running on. Maybe by calling getcwd and testing for the presence of a colon you would know that it's Windows and not a Unix variant.
Well, that bit won't work on Windows anyway will it? If it did, using the PATH_SEPARATOR constant would be appropriate.
OK, OK Brion You've got a point. The Unix-style path items in the $diff3locations array construct are of course not going to be Windows compatible. The PHP script seems to just skip over these. So maybe the solution is to look at PATH_SEPARATOR, and if it's a colon, look at a series of Unix paths, and if it's a semi-colon, look only at the Windows PATH environment variable. You could also look at PHP_OS to control this.
The more serious problem would be that Windows doesn't include GNU diff3. ;)
We could get it from MingW or similar GNU environment. Unix doesn't include Apache, MySQL or PHP, and that hasn't stopped people running Mediawiki on it either !
Those aren't in standard paths, and usually aren't in the system %PATH% either. (They install a little shortcut for starting a shell with the environment set right for running Cygwin/MinGW bits.) Of course you may manually enable it with your own path, and it might or might not even work. Note that most Unix/Linux distributions available today *do* include, either by default or as optional installs, such tools as diff, Apache, MySQL, and PHP.
Regardless of how Windows gets its diff3 command, Mediawiki needs some way of detecting its existence out-of-the-box. At present this code is Unix-centric. Can we at least agree on a platform-neutral way of handling this, so that Windows administrators don't need to do their own hacks to make it work cleanly ? We just need something that's documented and saves the poor old administrator, who may not be 100% au-fait with PHP programming having to dig into the internals of Mediawiki's configuration script to get it working. The user should only need to be told where to get diff3 for Windows and where to install it, possibly with some details on how to set the PATH accordingly.
Of course the code is Unix-centric. It uses a Unix program.
You miss the point entirely Brion. Mediawiki works fairly well on Windows. There is documentation for Mediawiki which explains how to get it running on Windows, both under Apache and IIS. So why not make it even BETTER and "fill in the gaps" so that it runs more smoothly on Windows using the available Win32 ports of Unix-centric tools like GNU diff3, just like the developers of Apache, PHP and MySQL have all done ? If I were demanding that Mediawiki support Microsoft's SQL Server instead of MySQL as the backend database, then I'd expect to be howled down because of the amount of re- writing that might be required. But my request is a perfectly reasonable, and none-too- complicated one. Yes, we can all stick our heads in the sand and pretend that Mediawiki only runs under Unix-style OSes, but that isn't the case and we all know it. Maybe if we adopt the same attitude, we should get rid of the English version of Wikipedia because more people on the planet speak Chinese than English ?
We're talking about one line of the configuration file for an optional, non- required feature to use an external program which is not installed by default on Windows, isn't in a standard location on Windows, and won't be in the PATH anyway unless the user goes through even *more* effort to change the system- wide configuration (which may not be desirable) and reboot? Anyway, it's already using PATH_SEPARATOR in CVS HEAD. Would you mind testing to see if it works the way you expect before we continue the bugwar? :)
Assuming this works at present as mentioned above.
