Crunchy does not work from path containing non-ascii characters (Windows only?)

[GoogleCodeExporter]

Have Crunchy installed on a path with non-ascii characters.  It does not
start due to encoding issues in configuration.py.  A simple try/except loop
simply shifts the problem elsewhere.

Original issue reported on code.google.com by andre.ro...@gmail.com on 6 Jan 2008 at 9:20

[GoogleCodeExporter]

The bug is also present under Mac OS.

Original comment by andre.ro...@gmail.com on 11 Jan 2008 at 2:24

[GoogleCodeExporter]

I've already talked about this with Andre, but basically I think this problem 
could
be solved by using the os.getcwdu function as opposed to os.getcwd . This is 
because
the first one returns the current directory as a unicode, which could probably 
handle
special characters a lot better. I'll try it out and report back if it works.

Original comment by crack...@gmail.com on 16 Feb 2008 at 10:49

[GoogleCodeExporter]

Fixed (at least on Mac). The issue was trying to concatenate ascii and non-ascii
strings (from the path) while building the crunchy.help string.

Original comment by andre.ro...@gmail.com on 1 Mar 2008 at 2:47

• Changed state: Fixed

[GoogleCodeExporter]

After testing, I found that it is still a problem on Windows.  (No time to work 
on it
at the moment though...)

Original comment by andre.ro...@gmail.com on 30 May 2008 at 11:16

• Changed state: Started

[GoogleCodeExporter]

Crunchy seems to work well with non-ascii characters in the path under my 
GNU/Linux.
Maybe because it use UTF-8, but not Windows? (ISO-* or windows specific set?)

Original comment by florian....@gmail.com on 3 Jun 2008 at 4:00

[GoogleCodeExporter]

I suggest making  root_path be unicode to resolve this problem.
I attached a patch for security.py. It works on Windows XP and Linux(Debian). 
(but It
will break some print statement for debug purpose)

Original comment by Filia....@gmail.com on 7 Jun 2008 at 8:45

Attachments:

• security.patch

[GoogleCodeExporter]

Fixed in revision 774.

The main problem arose when trying to build the string in configuration.py for
Defaults.help.   Using my home path with "André" in it, I could get it to work 
(sort
of) similar to the way it "worked" in release 0.9.8.6.   However, when typing
"crunchy.help" at an interpreter prompt, a unicode string was printed with 
non-ascii
characters (for the user_dir value and the temp_dir value); this in itself was
strange as unicode strings contain escaped unicode values i.e. they are 
displayed
showing only ascii characters as in Andr\xe.  (the same behaviour was exhibited 
on
release 0.9.8.6)

A really weird problem occurred when typing "print crunchy.help" inside the
interpreter: the interpreter just stopped but was still displayed.  Sometimes, a
weird error message about some uncaught exception would appear on the console (I
should have written it down), something like I have never seen before using 
Python.
On occasion, an empty traceback was printed (i.e. the traceback header was 
printed
but nothing would show.)  I tried to use a debugger (with Komodo IDE) but it 
crashed
the program.

Note that I could not reproduce any behaviour of this type on a Mac.

I will change the label of this issue (hopefully permanently) to "Fixed".

====Recording possibly for future reference:
During the course of attempting to solve this problem, I encountered another 
weird
behaviour on Windows.  When using os.path.join(path1, path2), when path2 was 
obtained
from the browser (thus seemingly encoded using utf-8), an error was found to 
occur
occasionally seemingly caused by the encoding of path2 even though path2 
contained
only ascii characters.

Original comment by andre.ro...@gmail.com on 18 Jun 2008 at 2:45

• Changed state: Fixed

[GoogleCodeExporter]

This has resurfaced in the trunk.  I don't think it was ever truly solved.  
Time to
resurrect it and examine it again at some point.

Original comment by andre.ro...@gmail.com on 17 Aug 2009 at 1:00

• Changed state: Accepted
• Added labels: Milestone-Beyond1.0
• Removed labels: Milestone-Release1.0

[GoogleCodeExporter]

This may be solved... The problems I encountered appear to have been caused by a
faulty repository on my old Windows account.

Changing the milestone, to ensure it is fixed.

If it is, the readme.html file will need to be changed back.

Original comment by andre.ro...@gmail.com on 17 Aug 2009 at 2:27

• Added labels: Milestone-Release1.0
• Removed labels: Milestone-Beyond1.0

[GoogleCodeExporter]

Fixed.

Original comment by andre.ro...@gmail.com on 19 Aug 2009 at 9:53

• Changed state: Fixed