Issue 86251

Summary: Python systemPathToFileUrl does not like national characters - approved
Product: App Dev Reporter: bmarcelly <marcelly>
Component: scriptingAssignee: joergbudi
Status: CLOSED FIXED QA Contact: Unknown <non-migrated>
Severity: Trivial    
Priority: P3 CC: darabos.daniel, frank.schoenheit, issues, joerg.skottke, maison.godard
Version: 3.3.0 or older (OOo)   
Target Milestone: ---   
Hardware: All   
OS: Windows XP   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 88258    
Description Flags
patch for
Patched version for for OOo-2.4.0
Patched version in case you installed OOo to a path with non-ascii charcters for OOo-2.4.0
function "checkForPythonPathBesideComponent" also needs encfile
version with "checkForPythonPathBesideComponent" patched none

Description bmarcelly 2008-02-20 06:22:18 UTC
Python script bug. Works OK for other scripts (Basic, Beanshell, Javascript...)

On Windows XP my userid is "Propriétaire" (was initialized by my PC vendor).
I cannot run any Python user script because character é is in the file path.
Contents of the log.text :

Wed Feb 20 07:03:38 2008 [ERROR] Error while evaluating file:///C:/
Scripts/python/ 'ascii' codec can't encode 
character u'\xe9' in position 32: ordinal not in range(128)
  C:\Program Files\ 2.4\program\ in function 
checkForPythonPathBesideScript() [if 1 == os.access( path, os.F_OK) and not path in 
  C:\Program Files\ 2.4\program\ in function 
getModuleByUrl() [checkForPythonPathBesideScript( url[0:url.rfind('/')] )]
  C:\Program Files\ 2.4\program\ in function 
getChildNodes() [self.module = self.provCtx.getModuleByUrl( self.uri )]
Comment 1 kay.ramme 2008-02-20 07:57:51 UTC
Joerg, please take care of this ...
Comment 2 bmarcelly 2008-03-04 15:11:22 UTC
Here is a correction proposal. Tested only on my WindowsXP computer.

pyuno routines systemPathToFileUrl and fileUrlToSystemPath should not be used.

1) Correction of -> change the existing functions by these versions:

def systemPathToFileUrl( systemPath ):
    "returns a file-url for the given system path"
    sv = 
    ret = sv.getFileURLFromSystemPath("", systemPath)
    return ret

def fileUrlToSystemPath( url ):
    "returns a system path (determined by the system, the python interpreter is 
running on)"
    sv = 
    ret = sv.getSystemPathFromFileURL(url)
    return ret.encode(sys.getfilesystemencoding())

2) Correction of -> change the existing functions by these versions:

def systemPathToFileUrl( systemPath ):
    "returns a file-url for the given system path"
    return uno.systemPathToFileUrl( systemPath )

def fileUrlToSystemPath( url ):
    "returns a system path (determined by the system, the python interpreter is 
running on)"
    return uno.fileUrlToSystemPath( url )

3) Improvement of :
it would be more efficient to call the uno.fileUrlToSystemPath() and 
uno.systemPathToFileUrl instead of the equivalent routines.
Comment 3 joergbudi 2008-03-06 20:00:45 UTC

bug is accepted, but I have to think a little more about it. You can avoid the
Exception by replacing the line 

        if 1 == os.access( path, os.F_OK) and not path in sys.path:


        if 1 == os.access( path.encode(sys.getdefaultencoding()), os.F_OK) and
not path in sys.path:

 (your proposed patch included this already). It helps on my system, can you
check whether this would help on your system as well ? 

I don't want to use a ucb service in, because atm does not depend
on these services and pyuno shall be able to run standalone without an office.

There are more bugs, the encode() must be added at all places, where a path is
passed to a python function (e.g. adding it to sys.path).

Additionally there seem to be problems when manipulating a unicode file url with
python string concatination, when I use non ascii characters as a script file
name, it appears garbled in the ui ...


Comment 4 joergbudi 2008-03-11 22:35:43 UTC

ok, this is a bug/feature in python itself, see

and fixed for python 2.4. The os.access function does not do the correct
conversions for unicode strings. Thus the correct fix is to replace

os.access( path, os.F_OK)


os.access( path.encode(sys.getfilesystemencoding()), os.F_OK))

. Additionally there are problems with the compile function. Attaching a patch
for (still need to verify this on windows though).

Comment 5 joergbudi 2008-03-11 22:36:59 UTC
Created attachment 52039 [details]
patch for
Comment 6 bmarcelly 2008-03-17 16:42:08 UTC
Sorry for the late answer, no time left.

Tested the patch with a user script, OK for me.
Comment 7 joergbudi 2008-04-03 08:04:33 UTC
Created attachment 52484 [details]
Patched version for for OOo-2.4.0
Comment 8 joergbudi 2008-04-03 08:05:37 UTC
Created attachment 52485 [details]
Patched version in case you installed OOo to a path with non-ascii charcters for OOo-2.4.0
Comment 9 joergbudi 2008-04-03 08:07:30 UTC
added patched versions of and to make it easier
for users to update an OO-2.4.0 installation. Simply replace the files in the
program directory of the office installation.

Comment 10 Daniel Darabos 2008-04-06 11:00:35 UTC
Dear Joerg,

Thank you for this quick fix. As developers of several Python extensions, this
bug hit us quite hard :).

However a user has reported that the fix does not work for him, and now that I
took a look at it, it is indeed not complete. Let me attach one more patch
(applying to the already patched version) and a version with this patch.
Comment 11 Daniel Darabos 2008-04-06 11:01:28 UTC
Created attachment 52589 [details]
function "checkForPythonPathBesideComponent" also needs encfile
Comment 12 Daniel Darabos 2008-04-06 11:04:00 UTC
Created attachment 52590 [details]
version with "checkForPythonPathBesideComponent" patched
Comment 13 joergbudi 2008-04-16 18:24:31 UTC
so just to summarize, the following files in source tree need to be patched

* pyuno/source/loader/  (with )

* scripting/source/pyprov/ ( with )

@QA: The patches can be tested this way
- Install office to a path with non-ascii characters
- Start writer
- Tools/Macro.../Run Macro...
- Choose Macros/TableSample
- If in the "Macro name" box appears a createTable(), the test succeeded.
Comment 14 Daniel Darabos 2008-04-21 09:34:19 UTC
jbu: It is not just the path to that matters. QA should also try
installing a Python language extension when their user name have special
characters. I think this exercises a different code-path.
Comment 15 joergbudi 2008-04-21 20:15:54 UTC
@cyhawk: checking the standard sample script will be enough. It both checks the 
changes in (can a python component be loaded ?) and (can the sample script be executed ?). Both files are loaded 
from absolute pathes, so no reason to force the qa people to have a certain 
localized operating system installed. Let me know by mail when u disagree. If 
this works, it will work on a localized os either.
Comment 16 Frank Schönheit 2008-04-23 21:06:51 UTC
fix committed to CWS pyunosystempaths, on behalf of jbu
Comment 17 Frank Schönheit 2008-04-24 10:03:22 UTC
targeting to 2.4.1, subject to the approval of the Release Status Team.

fs->jbu: please verify in CWS pyunosystempaths. Installation sets can be found

If anybody else involved in the issue is willing to verify the issue - by
downloading and installing the CWS build from the above location, and checking
the bug is indeed fixed -, then this would be welcome, too. In this case, please
set the issue to VERIFIED in case you have the permissions to do so. Thanks.
Comment 18 joergbudi 2008-04-24 20:44:56 UTC
installation sets work fine for me on both platforms -> verified. 

Will set the cws to approved for qa on 27th April in case no additional negative
comments are raised.
Comment 19 joerg.skottke 2008-04-29 12:12:26 UTC
CC myself, this issue can be automated
Comment 20 uwe.luebbers 2008-04-29 13:16:05 UTC
added "approved" to the title, because it will be easier to work with the 2.4.1 meta issue 
during release status meetings.
Comment 21 thorsten.ziehm 2009-07-20 14:54:51 UTC
This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
If you want to know more about the handling of fixed/verified issues =>