Community
Participate
Working Groups
Defect 182384 has been opened by jcagle. Component wsa.web.oti Severity 3 Prefix p Release Reference Abstract Product won't start if directory contains !%# Remarks: Tested using Eclipse 0.128 build. The product will not start if the install directory contains an exclamation point (!), pound (#), or percent (%). If the directory has a "!", javaw starts and then ends immediately. If the directory contains either "%" or "#", eclipse.exe starts but javaw.exe never starts. This is probably something that we just need to restrict in the install. Also see defect 182383 for problems if install directory contains "^" or "`". NOTES: KH (9/17/2001 12:47:31 PM) Not clear this is a workbench problem. JM (9/17/2001 1:56:12 PM) The doc should be updated to indicate that the platform uses URLs internally. File names with invalid URL chars are likely problematic.
PRODUCT VERSION: R09, Win2000
This seems to be a java limitation. I could not run a hello world program in java when the current directory was called # or %. This failed for both Sun and IBM JRE 1.3, but succeeded for Sun JRE 1.4 Beta 3. We should both document invalid characters, and ideally display some message from eclipse.exe stating that illegal characters are being used. According to the URL spec (Internet RFC 1738), the following characters are definitely not allowed in URLS: :%#<>" I don't know why the exclamation point (!) case is failing. I will investigate. Moving to McQ for consideration of trapping these characters in the current working directory in eclipse.exe. Please move to Platform->Doc afterwards for inclusion in the doc.
We might want to check for these characters in the launcher, in the spirit of giving better error reporting. I'm not sure how hard the problem is though. For example, are there an escape mechanism to allow the problematic characters to be included? Moving to Doc for inclusion.
This is already in the readme. Closing.
*** Bug 60057 has been marked as a duplicate of this bug. ***
*** Bug 73071 has been marked as a duplicate of this bug. ***
*** Bug 85198 has been marked as a duplicate of this bug. ***
*** Bug 85891 has been marked as a duplicate of this bug. ***
*** Bug 91258 has been marked as a duplicate of this bug. ***
Is there really no way to handle this seamingly common error more gracefully (ie. display an error dialog with a meaningful message)? That would improve usability. If we _know_ what the problem is and _know_ what the symptoms are, then it seems that it would only benefit users if this bug were fixed.
*** Bug 87642 has been marked as a duplicate of this bug. ***
*** Bug 262586 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > I don't know why the exclamation point (!) case is failing. I will investigate. With eclipse 3.5m5, the exclamation point (!) seems to work now, see bug 262586 Not sure if the readme should be updated? It currently has :%#<>"! as invalid. Changing resolution to NOT_ECLIPSE
*** Bug 268464 has been marked as a duplicate of this bug. ***
if the install directory, configuration or workspace directory contains arabic characters, does product start ? if yes, What do I have to configure ? eclipse, windows ? Eclipse version : 3.4.2
*** Bug 290667 has been marked as a duplicate of this bug. ***
*** Bug 294068 has been marked as a duplicate of this bug. ***
*** Bug 316660 has been marked as a duplicate of this bug. ***
*** Bug 320732 has been marked as a duplicate of this bug. ***
*** Bug 353231 has been marked as a duplicate of this bug. ***
*** Bug 338181 has been marked as a duplicate of this bug. ***
*** Bug 295531 has been marked as a duplicate of this bug. ***
*** Bug 186244 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > This seems to be a java limitation. I could not run a hello world program in > java when the current directory was called # or %. This is not true any more: C:\e\i\I20120110-0800\w s~!@#$%20^&()_-+,;[]{}a>type p\Test.java package p; import java.io.File; public class Test { public static void main(String[] args) throws Exception { System.out.println("Hello World @ " + new File("file.txt").getCanonicalPath()); } } C:\e\i\I20120110-0800\w s~!@#$%20^&()_-+,;[]{}a>javac -version p\Test.java javac 1.6.0_27 C:\e\i\I20120110-0800\w s~!@#$%20^&()_-+,;[]{}a>java p.Test Hello World @ C:\e\i\I20120110-0800\w s~!@#$%20^&()_-+,;[]{}a\file.txt
*** Bug 397133 has been marked as a duplicate of this bug. ***
Reopening based on comment #24.
There are likely many places in the platform launch sequence where we are not handling these characters. Since Java couldn't handle them in the past, we never bothered to make sure our code paths worked. Now that Java apparently supports them, we would need to go through our code from the launcher up through the boot sequence to make sure these characters are supported. We use URI or URL in many places to represent platform install location so there are likely encoding bugs that need working out.
One problem that shows up frequently is that people deal with "unencoded" URLs. Such URL objects are invalid (toURI() throws an exception), and their string representation is lossy, since it's e.g. not possible to know whether a # in a path is part of a file/folder name or whether it's the fragment separator. Advice: - File#toURL() is broken. DON'T USE IT ever. - Don't use constructors and getters of java.net.URL. Only create URIs and then use toURL() if you have to. - To extract parts of an URI/URL, always use the URI#get*() APIs. Use URL#toURI(), or "new URI(url.toString())" if you're on 1.4. - If there's absolutely no way to avoid dealing with broken ("unencoded") URLs, then org.eclipse.core.runtime.URIUtil could mabye help. But beware: This helper class is not well-specified and its Javadocs are not correct (bug 339422). It usually does more harm than good. If UNC paths still need special treatment, then someone who is affected by this needs to open a new bug and add new helper methods. URLEncoder/URLDecoder is most of the time *not* the right thing: - it is for HTML form encoding and e.g. converts " " into "+" - decoder behavior is *unspecified* for illegal strings!
Lost a day to this bug. We are create a Hudson matrix job where matrix axis have entries like "Kepler SR2". Hudson creates a working folder for each entry by escaping that value as "Kepler%20SR2". That runs smack into this bug, since Eclipse placed in that folder does not start. We are seeing this on Kepler. For the record, when this happens, the log contains the following exception: java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter
It is now more than 4 years we know this is fixed in java. How many more years do we need to make the standard way to get the eclipse installation folder to work with spaces and other special chars? I came here because Platform.getInstallLocation().getURL().toURI(); Throws an URISyntaxException exception when there is a space in the eclipse install path. Are you kidding me??? Windows has been using "program files" for many years. Why would we expect end users to think about not using spaces? I feel very afraid to speak up for eclipse in public because of these obviously buggy bugs not being fixed. Can you imagine the rumour when -after a pro eclipse talk- someone in the room asks: "Eclipse fails to start properly when there is a space in the path. There has been a bug open on eclipse for this since 2001. Which is 15 years by now. If something so fundamentally wrong takes so long to fix, Why would I use a tool delivered by a community; that seems to be incapable to fix core problems?"
(In reply to jan baeyens from comment #30) Hello Jan Baeyens, I just tested launching D:\Eclipse\eclipse 3.8.2\eclipse\eclipse.exe D:\Eclipse\eclipse cpp-mars-2-win64\eclipse\eclipse.exe and both launched fine for me on Windows 7. Also as far as I can remember, space characters have always worked fine for me; it's the percent, hash and exclamation mark that cause issues. If you see an issue related to spaces, I suggest that you please file a new bug and let us know the specifics of your environment (which Eclipse version, which host OS, which exact install path, which Java VM, which commandline args if any). Many thanks !
Hello Martin Oberhuber Thanks for your answer. I don't need to create a bugreport as numerous bugs have been created and are marked as duplicate of this one and the one that has been around since 2006 This seems to be the root cause of "space" bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=145096 Which makes Platform.getInstallLocation().getURL().toURI(); To throw an exception when there is a space in the eclipse install path. FYI a Link to getInstallLocation doc stating this is the way to get the install location http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fruntime%2FPlatform.html As this bug seems to be a "we don't care bug" and the other one is a "they have to fix it" we are in a dead loop. I agree that technically they are different things but the end user doesn't care. So maybe the owners of the 2 bugs should have a talk together and agree on a way out. Because for the end user we already know about a bug for 10 years in the eclipse API not supporting spaces at several locations. And I know about plenty other similar (though not this obviously wrong) issues in eclipse. Best regards Jantje PS I'm not shooting at you or anyone else. I know situations grow and become as they are. But If we stop complaining and stop pointing at the painpoints we can just as well let it die. I prefer eclipse to stay around a lot longer.
(In reply to jan baeyens from comment #32) Hello Jantje, As explained on https://bugs.eclipse.org/bugs/show_bug.cgi?id=145096#c7 , that bug is not so much a "it's their problem" kind of thing, but more of a "how to fix this while staying backward compatible without breaking clients" kind of thing. Since I couldn't reproduce the "doesn't launch from a path with spaces" problem, which I agree is a severe problem, I would still appreciate if you could open a new bug for the specific issue that you see. I suspect that there must be something special about your environment. And maybe bug 145096 is not the root cause of what you see after all. Thanks ! Martin
Martin There really is no need to create another bug. I really do not have a special case Looking through the duplicate bugs of bug 145096 I found this one https://bugs.eclipse.org/bugs/show_bug.cgi?id=214114 reported in 2008 Exactly what I report. Jantje
(In reply to jan baeyens from comment #34) Hello Jantje, the existing bugs that you referenced don't help because they only talk about internal API issues -- they do not talk about any end-to-end problem that a user would face. I assume that's why committers haven't prioritized them so far. You claimed that your Eclipse doesn't start when installed into C:\Program Files, and I couldn't reproduce that issue. I'll again request to please file a new bug that explains the exact conditions under which you see the severe end-to-end problem. Then we can look at it and prioritize it. Let's please stop the discussion on this bug now, which talks about a different problem (!%# characters) while you primarily complained about space characters. If you really want to bring Eclipse forward, it would help if you trusted committer's advice. Why do you resist against filing a bug which describes your exact problem ? It doesn't help if you think you know our processes better than the committers. Thanks! Martin
Found a relevant end user problem (restart fails when install dir has a space), filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=489476 Let's use that bug for now for the "space char issue", but leave this bug focused on #%! issues.
Txs for taking this seriously.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
