Community
Participate
Working Groups
Create a remote C/C++ project. In project Properties, Remote Development, Remote Paths and Symbols, Add.. and in the Remote Include Directory Dialog, hit Browse... In Select Directory text field, enter e.g. "/usr/local/o*" The dialog is populated correctly with things that start with 'o' But if you choose one and then hit OK, the Directory field shows: /usr/local/o*/openmpi-1.4.2-intel-11.1 Which is invalid.
is this still a problem?
Yes this is still a problem in PTP 5.0.0
Created attachment 206293 [details] contains modified java file Modified: org.eclipse.ptp.remote.remotetools.core/src/org/eclipse/ptp/remote/remotetools/core/RemoteToolsFileStore.java's RemoteToolsFileStore method. When doing a browse using a "*" in the path, the value does not get properly added to the instanceMap. I removed the unwanted characters from the path prior to it being replaced back into the instanceMap. I tested with a Remote C Project and a Synchronized Project on a 64-bit Linux system.
The trouble with this approach provided by the patch is that globbing (i.e. expanding shell meta-characters like '*') is not supported by EFS. The reason it's working in this case is that the Remote Tools implementation just happens to use a shell to expand the path, but other remote providers may not, so the user would be confused as to why it would work in some cases and not others. Also, a shell uses a number of other characters for expansion (e.g. '?', '[', ']', etc.) which will not work using the supplied patch. Finally, a path such as '/usr/local/o*/openmpi-1.4.2-intel-11.1' may actually be a valid path, since there is nothing disallowing a '*' in a path (try a command like "touch 'a*'"). The patch prevents this path from working as intended. The correct place to implement this is in the RemoteResourceBrowser, which is more analogous to a shell. The browser would need to do something like checking for the presence of shell meta-characters in the supplied path. If the were present, it would need to use the IFileStore#childStores() method to find the names of all the children in the path segment, then match the children against the supplied path using shell expansion rules. The IFileStore objects that match the path would then be displayed. Because the IFileStore objects were obtained via a supported mechanism, their paths should be correct. The current behavior is really a bug in the Remote Tools implementation, and probably should be disabled.
See last comment.
