Last modified: 2010-05-15 15:38:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4755 - Incorrect handing of Windows PATH in config/index.php
Incorrect handing of Windows PATH in config/index.php
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.5.x
PC Windows XP
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: testme
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-26 00:33 UTC by Jason Armistead
Modified: 2010-05-15 15:38 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jason Armistead 2006-01-26 00:33:25 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.
Comment 1 Brion Vibber 2006-01-26 00:41:30 UTC
Well, that bit won't work on Windows anyway will it?

If it did, using the PATH_SEPARATOR constant would be appropriate.
Comment 2 Jason Armistead 2006-01-26 02:13:24 UTC
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.
Comment 3 Brion Vibber 2006-01-26 02:19:46 UTC
The more serious problem would be that Windows doesn't include GNU diff3. ;)
Comment 4 Jason Armistead 2006-01-26 07:10:16 UTC
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 !
Comment 5 Brion Vibber 2006-01-26 08:40:34 UTC
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.
Comment 6 Jason Armistead 2006-02-20 03:54:58 UTC
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.
Comment 7 Brion Vibber 2006-02-20 20:12:25 UTC
Of course the code is Unix-centric. It uses a Unix program.
Comment 8 Jason Armistead 2006-02-21 09:43:44 UTC
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 ?
Comment 9 Brion Vibber 2006-02-21 18:30:40 UTC
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? :)
Comment 10 Brion Vibber 2006-06-04 01:29:44 UTC
Assuming this works at present as mentioned above.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links