-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I've set up an Apache instance on wolfsbane for testing. Please have a look at https://wiki.toolserver.org/view/Apache_testing and then test your tools (note the caveat about PHP, in particular).
We're not in any rush to move off ZWS, so this is mostly just preliminary testing. Nonetheless, it would be useful to know about any problems now rather than later.
- river.
I've set up an Apache instance on wolfsbane for testing. Please have a look at https://wiki.toolserver.org/view/Apache_testing and then test your tools (note the caveat about PHP, in particular).
Much better than zws. No issues with database strings encoding, compare:
http://wolfsbane.toolserver.org:81/~lvova/cgi-bin/go.sh?language=ru&inte... http://toolserver.org/~lvova/cgi-bin/go.sh?language=ru&interface=en&...
mashiah
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mashiah Davidson:
Much better than zws. No issues with database strings encoding, compare:
http://wolfsbane.toolserver.org:81/~lvova/cgi-bin/go.sh?language=ru&inte... http://toolserver.org/~lvova/cgi-bin/go.sh?language=ru&interface=en&...
This is not an innate difference between the two, but some kind of configuration difference. I was looking at your encoding problem earlier; the most likely possibility seemed to be that after the MySQL 5.5 upgrade, the default client character set changed to UTF-8, which broke some tools. I've changed that back to latin1 to restore the old behaviour, but it didn't fix your problem.
Looking at the difference in environment between the two:
http://wolfsbane.toolserver.org:81/~river/env.cgi http://toolserver.org/~river/env.cgi
... the most obvious difference is that Apache doesn't set LANG=en_US.UTF-8. This doesn't seem to affect the MySQL client, though:
river@wolfsbane:~$ LANG= sql enwiki_p ... Server characterset: latin1 Db characterset: latin1 Client characterset: latin1 Conn. characterset: latin1
river@wolfsbane:~$ LANG=en_US.UTF-8 sql enwiki_p ... Server characterset: latin1 Db characterset: latin1 Client characterset: latin1 Conn. characterset: latin1
If you could add the output of SHOW VARIABLES LIKE '%character_set%'; to the script, and see if there's a difference between them, it would help track down the problem.
- river.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
River Tarnell:
I was looking at your encoding problem earlier; the most likely possibility seemed to be that after the MySQL 5.5 upgrade, the default client character set changed to UTF-8, which broke some tools. I've changed that back to latin1 to restore the old behaviour, but it didn't fix your problem.
It looks like the problem is that you override --defaults-file in ~lvova/public_html/cgi-bin/ts. This prevents the client from reading /etc/my.cnf, so you don't get the correct default character set.
If you do this instead:
HOME=$(getent passwd $(id -u)|cut -f6 -d:) export HOME
... then you don't need to use --defaults-file and your script will probably work correct.
(Example: http://toolserver.org/~river/sql.cgi.)
- river.
toolserver-l@lists.wikimedia.org