On Aug 26, 2007, at 10:54 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
Committed to trunk: r565326
We need a decision, in the next 24hrs, so I can roll apr's by later
tomorrow. Is this being backported?
These already are...
It seems rational to me, but we already messed up by
Jim Jagielski wrote:
Committed to trunk: r565326
We need a decision, in the next 24hrs, so I can roll apr's by later
tomorrow. Is this being backported?
It seems rational to me, but we already messed up by not noting this
change in CHANGES (it has significant implications to end users!)
If we
Committed to trunk: r565326
Erik Huelsmann wrote:
- if Darwin has a configurable locale, does *not* set this up by
default
such that nl_langinfo(CODESET) returns UTF-8, but does by policy
require
filenames in UTF-8, regardless of locale, I would agree with changing
apr_filepath_encoding as Erik proposed. That is the
On Aug 6, 2007, at 6:40 PM, Roy T. Fielding wrote:
Er, yeah, did I say that backwards? The man page says that equivalent
characters will use the shortest representation, which would mean
always using the composed form of UTF-8. Right? So the man page
for utf8 (from BSD) should be updated to
(Sorry for the lame reply latency.)
On Jul 18, 2007, at 5:24 PM, Roy T. Fielding wrote:
A system less concerned with backwards compatibility is better off
with a requirement of utf-8, though OS X should have made the filename
encoding a mount option.
I disagree. Having one encoding is
On Aug 6, 2007, at 5:11 PM, Roy T. Fielding wrote:
I agree. But is it the case that non-native mounted filesystems
are name-translated by the kernel? I mean, if OS X did this
consistently
for all mount points, then I would see it as being reasonable for the
OS X applications to reject
On Aug 6, 2007, at 5:39 PM, Wilfredo Sánchez Vega wrote:
On Aug 6, 2007, at 5:11 PM, Roy T. Fielding wrote:
Actually, it also crashes on valid utf-8 in normal form, because OS X
doesn't follow the standard on normalization. See man -s 5 utf8:
If more than a single representation of a
- if Darwin has a configurable locale, does *not* set this up by
default
such that nl_langinfo(CODESET) returns UTF-8, but does by policy
require
filenames in UTF-8, regardless of locale, I would agree with changing
apr_filepath_encoding as Erik proposed. That is the case?
I
On 7/18/07, Roy T. Fielding [EMAIL PROTECTED] wrote:
after unzipping something from China or Switzerland. Subversion
breaks on OS X whenever someone commits a filename with an e-grave,
which is a problem when your main product name is Communiqué.
I wonder if this change in APR would fix that
On 7/17/07, Erik Huelsmann [EMAIL PROTECTED] wrote:
On 7/17/07, Lucian Adrian Grijincu [EMAIL PROTECTED] wrote:
APR holds everything in locale encoding on UNIX and UTF8 on Windows.
As far as I know UNIX system calls must accept *locale* strings, not
an arbitrary encoding (be it UTF8 or
Thanks for the write-up, Fred.
- it is convention on all modern Unixes I'm aware of that filename
charset/encoding follows LC_CTYPE; not just Linux. It may derive from
Solaris, I think that's where the locale APIs originate.
- AFAIK this convention is not standardised anywhere.
-
On Jul 17, 2007, at 3:12 PM, Erik Huelsmann wrote:
Which suggests that apr_filepath_encoding should return
APR_FILEPATH_ENCODING_UTF8, if I'm not mistaken.
I think that's the correct thing to do on Darwin.
But generally applications won't work with these non-UTF8 paths if
they are well
On Jul 18, 2007, at 2:11 AM, Joe Orton wrote:
- it is convention on all modern Unixes I'm aware of that filename
charset/encoding follows LC_CTYPE; not just Linux. It may derive from
Solaris, I think that's where the locale APIs originate.
I guess I don't know how that works in practice.
On Jul 18, 2007, at 9:55 AM, Wilfredo Sánchez Vega wrote:
On Jul 18, 2007, at 2:11 AM, Joe Orton wrote:
- it is convention on all modern Unixes I'm aware of that filename
charset/encoding follows LC_CTYPE; not just Linux. It may derive
from
Solaris, I think that's where the locale APIs
Reading [1], I conclude that applications should pass UTF-8 to BSD
functions such as stat() at all times. This suggests to me that
apr_filepath_encoding() should return APR_FILEPATH_ENCODING_UTF8.
Yet, looking at the sources, on any Unixy system, it returns
APR_FILEPATH_ENCODING_LOCALE.
Is this
On Tue, Jul 17, 2007 at 02:14:25PM +0200, Erik Huelsmann wrote:
Reading [1], I conclude that applications should pass UTF-8 to BSD
functions such as stat() at all times. This suggests to me that
apr_filepath_encoding() should return APR_FILEPATH_ENCODING_UTF8.
Yet, looking at the sources, on
On 7/17/07, Joe Orton [EMAIL PROTECTED] wrote:
On Tue, Jul 17, 2007 at 02:14:25PM +0200, Erik Huelsmann wrote:
Reading [1], I conclude that applications should pass UTF-8 to BSD
functions such as stat() at all times. This suggests to me that
apr_filepath_encoding() should return
On Tue, Jul 17, 2007 at 02:31:27PM +0200, Erik Huelsmann wrote:
On 7/17/07, Joe Orton [EMAIL PROTECTED] wrote:
This is deliberate; on Unix the character set used for filenames is
dictated by the locale settings (e.g. LC_CTYPE), by convention. There
is certainly no Unix standard which dictates
On 7/17/07, Joe Orton [EMAIL PROTECTED] wrote:
On Tue, Jul 17, 2007 at 02:31:27PM +0200, Erik Huelsmann wrote:
On 7/17/07, Joe Orton [EMAIL PROTECTED] wrote:
This is deliberate; on Unix the character set used for filenames is
dictated by the locale settings (e.g. LC_CTYPE), by convention.
On 7/17/07, Erik Huelsmann [EMAIL PROTECTED] wrote:
On 7/17/07, Lucian Adrian Grijincu [EMAIL PROTECTED] wrote:
APR holds everything in locale encoding on UNIX and UTF8 on Windows.
As far as I know UNIX system calls must accept *locale* strings, not
an arbitrary encoding (be it UTF8 or
On 7/17/07, Lucian Adrian Grijincu [EMAIL PROTECTED] wrote:
On 7/17/07, Erik Huelsmann [EMAIL PROTECTED] wrote:
On 7/17/07, Lucian Adrian Grijincu [EMAIL PROTECTED] wrote:
APR holds everything in locale encoding on UNIX and UTF8 on Windows.
As far as I know UNIX system calls must accept
On 7/17/07, Erik Huelsmann [EMAIL PROTECTED] wrote:
No, I can't confirm: I'm trying to find out why Subversion is the only
app complaining there's no locale set when interacting with the
filesystem while the rest of the world seems perfectly fine with
reading UTF-8 filenames. [But I don't own a
On 7/17/07, Lucian Adrian Grijincu [EMAIL PROTECTED] wrote:
On 7/17/07, Erik Huelsmann [EMAIL PROTECTED] wrote:
No, I can't confirm: I'm trying to find out why Subversion is the only
app complaining there's no locale set when interacting with the
filesystem while the rest of the world seems
On Jul 17, 2007, at 5:25 AM, Joe Orton wrote:
On Tue, Jul 17, 2007 at 02:14:25PM +0200, Erik Huelsmann wrote:
Reading [1], I conclude that applications should pass UTF-8 to BSD
functions such as stat() at all times. This suggests to me that
apr_filepath_encoding() should return
On 7/17/07, Wilfredo Sánchez Vega [EMAIL PROTECTED] wrote:
On Jul 17, 2007, at 5:25 AM, Joe Orton wrote:
On Tue, Jul 17, 2007 at 02:14:25PM +0200, Erik Huelsmann wrote:
Reading [1], I conclude that applications should pass UTF-8 to BSD
functions such as stat() at all times. This suggests to
26 matches
Mail list logo
