Community
Participate
Working Groups
In Eclipse 3.2, I've been able to specify a workspace as local to my home directory by prefixing it with ~, so when starting, I have been able to select ~/Documents/SomeOtherWorkspace and it resolves to /Users/alex/Documents/SomeOtherWorkspace. However, in Eclipse 3.3M4, if I type the same thing in, it gets resolved to /Path/To/Eclipse.app/Contents/MacOS/~/Documents/SomeOtherWorkspace, in other words, as a relative directory to the currently executing eclipse executable (which is located in the Contents/MacOS subdirectory). If I start it with eclipse -data ~/Documents/SomeOtherWorkspace it seems to work as expected, and correctly resolves to the /Users/alex/Documents/SomeOtherWorkspace prefix. Is something being done to mangle the URL if it's not absolute or something? Has it changed recently if that's the case?
Is there special processing of the text field before being passed to the runtime?
I think this may be a VM issue. I just tried on 3.2.1 and I'm getting the same results. Stepping through the code, if I have a file created with the String "~/workspace", getAbsolutePath() returns "/Applications/Eclipse 3.3 I20061214-14XX/Eclipse.app/Contents/MacOS/~/workspace" I get this result whether or not I use 1.4.2 or 1.5. Can you confirm that there is a version combination where the desired behavior occurs?
Tilde expansion is a Unix shell feature, not a general feature in the OS filesystem calls or in java.io. Andre hacked tilde expansion in the Mac launcher (bug 33148), so perhaps something has gone wrong with that code. Andrew's launcher work is one possible culprit.
That was hacked into the launcher? Looking at the code path I dont see a way that the launcher could've made this work...
See the function expandShell in eclipseCarbon.c
That looks like it handles tilde expansion for command line arguments but this bug is about expanding them in the launcher dialog. According to the original text the -data expansion works but the expansion in the dialog does not. Looking at the code I'm not sure how it ever did.
Sorry, I was confused by comment #0 mentioning expansion when using the -data command line argument. I also don't know how this would have worked in the past, unless someone hacked it into the workspace selection dialog. I'll be quiet now.
I think we could replicate this behavior in the selection dialog. we have access to $user.home ...
It seems like a losing game to get into, in general. There are lots of places where file system paths are supplied by the user in the UI, and performing tilde expansion in only some of them would be inconsistent. I suspect we'd find all sorts of corner cases and inconsistencies trying to mimic this shell behaviour ourselves (consider ~username expansion, and the fact that tilde is a valid character in a unix path). Alex, can you confirm that you believe tilde expansion was working at some point in the workspace selection dialog (as opposed to expansion of the -data command line argument)?
I was relatively sure that this worked in the past. But, if Kim was unable to replicate it on 3.2.1, I may have been wrong. (In which case, closing this as INVALID might be applicable.) Note that it's not only the shell that does the expansion (but it does in this case) -- Finder.app allows you 'go to' folder ~ and other apps may also support it. I also think that if you use the ~ in the Info.plist (e.g. for the keyring) then it might be expected that the user be able to use ~ in the workspace selection dialog as well. I've dropped this level to an 'enhancement' if it can be addressed. Whilst there's obviously workarounds, I don't believe that using workspaces buried inside the Eclipse.app/Contents/MacOS is a sensible plan for Macs under any circumstances; an app is usually uninstalled by dragging the Eclipse.app into the trash, and if a user has unwittingly entered ~/Documents as the workspace when it launches, they'll trash their entire workspace too. I agree with John's point that chasing the ~ will be found in potentially many places; but the workspace selection dialog is probably one of the more important ones.
Changing OS from Mac OS to Mac OS X as per bug 185991
Prakash is now responsible for watching bugs in the [WorkbenchLauncher] component area.
Looks like this might be a dupe of bug 72607, provided that the platform is set to 'all' as it applies cross-unices (and the version number updated, of course)
*** This bug has been marked as a duplicate of bug 72607 ***
