Community
Participate
Working Groups
As far as I can tell, no command variables are being passed to the external program. I tried both current project location and selected resource location. I set up an external program with both c:\windows\write.exe and c:\windows\command.com and neither seems to be passed the variable contents. Although if I type a specific non-variable parameter into the "Tool Arguments" field, that works.
Build was 0530 integration build.
Need to ensure that all the variables we claim to support are working for F2.
Please verify.
Checked build 0609, using NT and Win98. As far as I can tell this is *not* working. I configured an external tool definition for wordpad.exe (write.exe on win98). I tried both the following variables: selected resource location selected resource full path It appears that no parameters are being passed to the program. If I type a constant parameter into the dialog then it works.
i wrote a program, c:\args.cmd, which looks like this: echo [0] %0 echo [1] %1 echo [2] %2 echo [3] %3 echo [4] %4 echo [5] %5 echo [6] %6 echo [7] %7 echo [8] %8 echo [9] %9 a created ten tools from this program, one for each of the first ten variables as the tool's single argument. from my workspace (built from importing the plugins), i selected in navigator a file resource: "plugin.xml" under "org.junit". i ran each tool on this selection with the following results (as displayed in the log console; irrelevant details omitted): args ${workspace_loc} [0] c:\args.cmd [1] C:/eclipse-SDK-20020607-win32/eclipse/workspace args ${project_loc} [0] c:\args.cmd [1] C:/eclipse-SDK-20020607-win32/eclipse/workspace/org.junit args ${container_loc} [0] c:\args.cmd [1] C:/eclipse-SDK-20020607-win32/eclipse/workspace/org.junit args ${resource_loc} [0] c:\args.cmd [1] C:/eclipse-SDK-20020607-win32/eclipse/workspace/org.junit/plugin.xml args ${project_path} [0] c:\args.cmd [1] /org.junit args ${container_path} [0] c:\args.cmd [1] /org.junit args ${resource_path} [0] c:\args.cmd [1] /org.junit/plugin.xml args ${project_name} [0] c:\args.cmd [1] org.junit args ${container_name} [0] c:\args.cmd [1] org.junit args ${resource_name} [0] c:\args.cmd [1] plugin.xml wordpad: now i created two tools using wordpad (C:\Program Files\Windows NT\Accessories\wordpad.exe), the first using ${resource_loc} as its argument. with the same selection as above, wordpad launches the file correctly. i am not able to repeat your problem for this case. the second, using ${resource_path} as its argument, causes wordpad to launch, but wordpad is unable to launch the file so it starts with a blank document. this is also correct behavior according to the above tests. wordpad cannot find "/org.junit/plugin.xml" (note: it is unfortunate that the full path variables always have a leading slash, otherwise i could have been able to launch in this case by specifying ${workspace_loc} as the working directory.) there are a two areas where you may have had problems (i stumbled on both of them myself): potential issue #1: paths with spaces eclipse has no problem executing applications with spaces in the path. quotes are not required. interpretation of arguments, of course, is up to the tool itself, and occasionally a tool will fail on a filename containing spaces unless it is explicitly quoted. eclipse does not seem to quote arguments with spaces, and i feel that this is correct behavior. wordpad will fail on filenames containing spaces unless explicitely quoted. this may have happened in your case. potential issue #2: selection bug try the args ${resource_loc} example above again. make sure to select a resource first. notice that the current view (probably navigator if you just selected a resource) deactivates when the tool is run. when the tool finishes, the view doesn't reactivate. notice the resource is still selected, but colored gray. try running the tool again. the argument expands to an empty string as the view does not return a selected resource. try this with the wordpad ${resource_loc} example and you will get a blank document. finally, a note about the variable terminology: as a regular user, my first thought is that "full path" and "location" should be swapped. "full path" intuitively means an absolute path on a file system, while "location" is a more abstract notion - more useful a term to describe a relative position within a domain-specific semantic construct like 'workspace' external tools is not to blame: during variable expansion it correctly delegates to IResource.getFullPath() and IResource.getLocation() respectively, and i think the ui is correct to match its terminology to core resources public api. i do find it curious why core resources didn't swap these terms. summary: 1. i will log the leading slash comment and the selection bug to platform ui. 2. i will log the comment regarding confusing terminology to core resources. 3. i will log a note to platform docs requesting special attention to explaining variable names and the issue with filenames containing spaces.
Quoting the argument fixed the problem. However users are going to run into trouble for the reasons you outline: 1) Without quotes some apps don't work and you have no clue why. I wonder why we don't just insert the quotes into the text area for the arguments by default? The user can always remove them. 2) The terminology for the arguments is confusing and conterintuitive - we need a better way to indicate what exactly will be passed as the argument - perhaps we could show what would be passed given the current selection, or provide a test area so you can click on something and see what happens.
Actually, it only worked the first time. After some experimentation I discovered I had to re-click on the item in the list to make it work again. I am reopening the report because there is still a real problem here.
Ryan was looking at quoting the arguments being passed (both for location and path variables). It was not part of friday's build. I agree, we exposed the core terminology in the UI - coming up with better names for these would help. The lost of focus may come from the use of a progress monitor. This problem may go away if we can run without a progress monitor.
The variables are now working. The selection problem and the terminology will have to wait until post 2.0.
Post 2.0.
Reopened for investigation
This is fixed in the new external tool support. Note: new external tool work is not yet released to the head stream and won't for a while yet.
