Menu
▾
▴
#770 "file" protocol does not work in turkish locale
[pterjan@plop tmp]$ curl file:///usr/share/hot-babe/hb01/descr
5
hb01_4.png
hb01_3.png
hb01_2.png
hb01_1.png
hb01_0.png
[pterjan@plop tmp]$ LC_ALL=tr curl file:///usr/share/hot-babe/hb01/descr
curl: (1) Protocol file not supported or disabled in libcurl
Discussion
$ LC_ALL=tr curl file://`pwd`/README
... works fine for me when in the curl source tree root. On Debian Linux.
Is your problem related to exactly what URL you use or does it never work with file?
It fails on any file URL (curl 7.19.0 on Mandriva)
Do you have turkish locale ?
Without it I get :
$ LC_ALL=tr curl file:///tmp/plop
curl: (37) Couldn't open file /tmp/plop
After installing the locale I get :
$ LC_ALL=tr curl file:///tmp/plop
curl: (1) Protocol file not supported or disabled in libcurl
What is the output of:
LC_ALL=C curl --version
and
LC_ALL=tr curl --version
There should be no protocol differences between locales in curl.
[pterjan@plop ~]$ LC_ALL=C curl --version
curl 7.19.0 (i586-mandriva-linux-gnu) libcurl/7.19.0 OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10 libssh2/0.18
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
[pterjan@plop ~]$ LC_ALL=tr curl --version
curl 7.19.0 (i586-mandriva-linux-gnu) libcurl/7.19.0 OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10 libssh2/0.18
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Very strange. The "file" protocol is obviously available in both cases, so it must be that somehow the string comparison with strcasecmp is failing, which would be very odd because "file" is plain ASCII, and it's working for Daniel. What is the output of "locale" and "locale charmap"?
That's not really surprising that it fails as in Turkish "i" is not lowercase "I" (there is a i without dot and one with dot, the lowercase of I being ı and the uppercase of i being İ)
but the word "file" is not turkish, it is english and consists of the ascii letters (in decimal):
102 105 108 101 (lowercase)
or
70 73 76 69
What do you pass in to curl?
I call it with the ascii file:// url.
I did not look at the code, but strcasecmp in turkish locale will tell that FILE and file are different because i and I are not the same letter in turkish alphabet while they are in all other locales.
That makes sense. The following program proves it:
// Shows a bug in the 'tr' locale on Mandriva 2008.0
//
#include <stdio.h>
#include <string.h>
#include <locale.h>
int main(void)
{
setlocale(LC_ALL, "tr");
if (strcasecmp("i","I"))
printf("Buggy locale!\n");
return 0;
}
Are you saying that this is expected and desired behaviour in the Turkish locale? I assumed at least the ASCII alphanumerics would be untouched by locale-specific behaviour.
Yes as far as I know this is expected behavior
Google give me some bugs in a lot of software related to this (pgsql, apt-get, bison, ...)
For example :
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/80248/comments/32
http://www.nabble.com/dircolors-patch-for-locales-like-Turkish-td8977524.html
See also http://gambasdoc.org/help/api/name/gb.strcasecmp
Funny problem! :-/
I guess that there's simply no C or POSIX function we can use to safely compare strings case insensitively for all locales. It does seem a bit weird since this string is english and then 'i' and 'I' are in fact the same letter with different case.
Some programs seem to refer to a c_strcasecmp() function for this functionality but I've found no actual implementation to look at yet. I'm a bit disturbed that we more or less are forced to provide our own implementation of strcasecmp() due to this mess.
OK, I've committed a fix for this that replaces a lot of strcasecmp() calls to instead use the new internal function that doesn't care about locales and only does a-z case insensitive checks.
It would be great if you could check the current CVS code or tomorrow's daily snapshot to see if it works as we want even using Turkish!
This fix works for me. But it's going to fail on EBCDIC machines--the character sequence 'a' through 'z' contains discontinuities.
Good call! I modified the function, renamed it and committed a version I believe may work even for ebcdic now...
The new version works for me in LC_ALL=tr as well.
Just for info, I backported the patch to Mandriva Cooker and have sent it as a candidate update for 2009.0.
This would have been a lot easier if you used a modern RCS :)
Note that several other patches to fix other problems with the tr locale went in after the first--all the changes to support Curl_raw_nequal. Don't miss those as long as you're back porting this all.
Yes, via cvsps I found three relevant patchsets and combined them into one big patch. I don't *think* there were any other changes that I missed, and the patched curl passes all internal tests and does in fact work in the original failure case (displaying icons in the Mandriva Control Center in Turkish locales). So it looks good.
But, if you like, you can check. This is the patch:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/curl/current/SOURCES/curl-7.19.0-turkish.patch?view=markup
Remember it's against 7.19.0, so there are some files that used the functions in question in current CVS but didn't in 7.19.0 that are left untouched by the patch. I left out the changes to documentation and file headers (copyright dates and file revision numbers) because they obviously wouldn't apply clean to 7.19.0 (this is another annoying thing about CVS).
If you see anything wrong or missing, please do let me know. Thanks!
1) Why we stick with CVS:
http://daniel.haxx.se/blog/2008/04/14/why-curl-sticks-with-cvs/
2) I don't think Mandriva is in a position to complain about that our work, given away for free, may be tricky to backport for you.
I didn't complain, merely stated a fact. It would have been easier with a more modern RCS. It's of course your prerogative to use whatever damn RCS you choose. :)