[MERGE][1.14][355273] Fix OSX test failures

[Vincent Ladeuil]

>>>>> "jfroy" == Jean-Francois Roy <bahamut at macstorm.org> writes:

    jfroy> On Apr 7, 2009, at 01:10, Vincent Ladeuil wrote:

    >>>>>>> "jfroy" == Jean-Francois Roy <bahamut at macstorm.org> writes:
    >> 
    jfroy> Mac OS X 10.5's Terminal can optionally set LANG.
    >> 
    >> Wow, shiny preferences or Terminal ! Never noticed it (I still
    >> use 10.4 most of the time though).
    >> 
    jfroy> I am not sure what the default setting is, however (it
    jfroy> may very well be disabled by default).
    >> 
    >> Seems checked by default, yet, LANG is not set with UTF-8
    >> selected as 'Character encoding'.

    jfroy> It definitely should be.

Then we have a bug in OSX :-)

    jfroy> It certainly is on all of my machines (it gets set to
    jfroy> en_US.UTF-8). 

Definitely not here :)

    jfroy> That being said, the feature does interact with the
    jfroy> system's locale database, and if none can be found
    jfroy> that matches the selected encoding, I believe Terminal
    jfroy> will not set LANG.

Hmm, let me see, I try to keep as close as possible to default
settings, (en_US I presume).

The only exceptions are in the International preferences where I
chose Region: France (English) in the Formats tab.

I get a warning there: 'The region is incompatible with some
older applications...blah blah blah'

Setting the region to United States (not United States
(computer)', I get LANG set to en_US.UTF-8 in terminal... pfew,
who would have thought...

<snip/>

    jfroy> tty issues aside, special care must indeed be taken on Mac OS X
    jfroy> w/r to  unicode decomposition when sending and receiving file
    jfroy> paths.

That's exactly where we have problems (some may be due to python
itself) and John Meinel has summarized that to the list at
numerous occasions.

That's the part I don't intend to fix right now but instead try
to get back to the point we were excluding these issues as a
*first* step. But even that may well be outside of this bug
scope.

    jfroy> The encoding will always be UTF-8 for all filesystems
    jfroy> at the API level however (it's a POSIX compliance
    jfroy> requirement and an implementation
    jfroy> detail).

I seem to remember that part of the problem was indeed that OSX
didn't use the same decomposition (NKD or NKFD ? instead of NKC
NKFC ?) as other systems which led to specific problems (but John
knows better, see the archive for details).

    jfroy> Decomposition is something Subversion does wrong and
    jfroy> it has bitten be in the past when accented characters.

And AFAIR we don't intend to do better (yet) as that will require
special handling for OSX anyway (again, based on John's remarks,
I seem to recall that OSX use a normalization that is more
expensive than the others and we didn't want to make all OSes
incur that cost).

    jfroy> In addition, the one other quirk I am aware of are "Icon\r"
    jfroy> files,  which have an empty data fork but some data in the
    jfroy> resource fork. Most  tools can't deal with the Mac line break
    jfroy> (CR) in the file name,  including bzr's .bzrignore mechanism. I'm
    jfroy> pretty sure Bazaar doesn't  support multiple file forks or
    jfroy> extended attributes either, but that's  a different matter.

Geee, I thought that OSX was getting rid of the fork madness for
good, Apple is pretty good at making my old macs unsupported (I
still have a G3 and a G4 running there), it may be time for them
to obsolete the fork mechanism given that all Apple applications
seems to do well without it (AFAICS).

And where is that "Icon\r" used ? And how does the Finder
displays it ? Can I issue 'ls -al Icon\r' ?

    Vincent