Bug 49 : trouble running sketches when user account contains non-ascii characters
Last modified: 2010-06-06 10:01




Status:
RESOLVED
Resolution:
FIXED -
Priority:
P1
Severity:
normal

 

Reporter:
fry
Assigned To:
fry

Attachment Type Created Size Actions

Description:   Opened: 2005-07-15 14:37
sometimes when a user account on Windows contains non-ascii characters
(umlauts or accents on Roman characters, or any non-Roman text), sketches
won't run.

there's some sort of problem with the temporary folder name being passed to
Processing. this is a very serious bug for our international users, however
i'm stuck because i can't get figure out how to get it to replicate on any
of my own Windows machines.

more followup here:
http://processing.org/discourse/yabb_beta/YaBB.cgi?board=SoftwareBugs;action=display;num=1119560795

workaround: setting "build.path=build" will use a subfolder of the
Processing directory to build sketches, but you just have to make sure that
Processing is installed in a place where you have permissions to write to
files.
Additional Comment #1 From fry 2005-07-15 14:42
*** Bug 50 has been marked as a duplicate of this bug. ***
Additional Comment #2 From fry 2005-07-28 05:50
sometimes results in this error:
"Semantic Error: The input file xxxxx was not found." when trying to run a
sketch

or something like this:
Error: The directory specified in the "-d" option, "C:\Documents and
Settings\?ke\Application Data\Processing\build", is either invalid or it
could not be expanded.
Additional Comment #3 From fry 2005-10-26 08:49
with some help from koo-chul lee, we've tracked down the causes for this
problem.

fundamentally, it's an issue with jikes and dos, which aren't properly
handling non-ascii characters from the command line. javac works just fine,
so we might have to make people install javac and use that. or, just try to
find somewhere safe on the c:\ drive to put their sketchbook and build
folders, but that seems messy.

the reason it was working on english versions of windows is that 8.3 syntax
for non-ascii chars becomes completely ascii. so a korean and french user
name on my own system became straight ascii (from the get temp folder code).
Additional Comment #4 From fry 2005-12-14 09:50
additional information from saito:

yea. i got the same issue.
i tested a japanese user name on a japanese version of Windows Xp.
it seems this problem is commonly found among the japanese Processing community.
actually, application programs often don't run if a user login name is
in Japanese (or non-ascii characters). So, we kind of got used to it
and usually avoid using non-ascii characters in a user name. it is
sort of a convention.
Processing alpha version seems to be working fine even with a username
writting in non-ascii characters.
Additional Comment #5 From fry 2006-03-07 06:39
*** Bug 300 has been marked as a duplicate of this bug. ***
Additional Comment #6 From fry 2010-06-06 10:01
the original cause of this problem between jikes and DOS is now no longer
relevant, so closing bug.