Page MenuHomePhabricator

Incorrect handing of Windows PATH in config/index.php
Closed, ResolvedPublic


Author: JArmistead

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.

Version: 1.5.x
Severity: normal
OS: Windows XP
Platform: PC



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:03 PM
bzimport set Reference to bz4755.
bzimport added a subscriber: Unknown Object (MLST).

Well, that bit won't work on Windows anyway will it?

If it did, using the PATH_SEPARATOR constant would be appropriate.

JArmistead wrote:

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. ;)

JArmistead wrote:

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.

JArmistead wrote:

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.

JArmistead wrote:

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.