pathtools - Project Hosting on Google Code

Older Oct 20, 2009 issue 8 (Troubles with quoting connecting with Cygwin executables) commented on by davidmichaelkarr - Yes, I've been using the console view. It would have been harder to diagnose without that. Using that, it's easy to tell when it's only taking the first word of the argument. The harder part is getting it to not do that. At least what I have works. Yes, that nested quoting on that command line was somewhat surprising. I tried both variations before I found that worked. Yes, I've been using the console view. It would have been harder to diagnose without that. Using that, it's easy to tell when it's only taking the first word of the argument. The harder part is getting it to not do that. At least what I have works. Yes, that nested quoting on that command line was somewhat surprising. I tried both variations before I found that worked. Oct 20, 2009 issue 8 (Troubles with quoting connecting with Cygwin executables) Status changed by sandipchitale - Glad that you found a solution. And yes...with quoting one has to always work it out carefully at every stage what is going on. Path Tools itself some quote processing. Have you looked at the command that was displayed in the Path Tools console in the Console view? That may help you understand some of quoting issues. Lastly you could use ps -aef (not sure if cygwin supports these options) o r Process Explorer from Sysinternal.com to see what command was ultimately used to launch the successive steps. In fact I am curious how this emacsclient -n -a textpad "$(cygpath -u "$path")" works. I would expect to see \" for the second and third quote in the line. But may be $() can handle embedded quotes like that. Status: WontFix Glad that you found a solution. And yes...with quoting one has to always work it out carefully at every stage what is going on. Path Tools itself some quote processing. Have you looked at the command that was displayed in the Path Tools console in the Console view? That may help you understand some of quoting issues. Lastly you could use ps -aef (not sure if cygwin supports these options) o r Process Explorer from Sysinternal.com to see what command was ultimately used to launch the successive steps. In fact I am curious how this emacsclient -n -a textpad "$(cygpath -u "$path")" works. I would expect to see \" for the second and third quote in the line. But may be $() can handle embedded quotes like that. Status: WontFix Oct 19, 2009 issue 8 (Troubles with quoting connecting with Cygwin executables) commented on by davidmichaelkarr - Actually, I've managed to construct a bizarre solution that appears to work, although it required both a BAT script and a Bash script. Weird. With "emacsclientbat.bat": -------------- @echo off c:\cygwin\bin\bash -l -c "emacsclienttocyg "%1"" -------------- And "emacsclienttocyg": -------------- #! /bin/bash path="$@" emacsclient -n -a textpad "$(cygpath -u "$path")" ------------- And the resulting command line: c:\cygwin\home\<myuid>\bin\emacsclientbat.bat "{path-slashes}" I wouldn't mind finding a "cleaner" solution, but if not, this will work. Actually, I've managed to construct a bizarre solution that appears to work, although it required both a BAT script and a Bash script. Weird. With "emacsclientbat.bat": -------------- @echo off c:\cygwin\bin\bash -l -c "emacsclienttocyg "%1"" -------------- And "emacsclienttocyg": -------------- #! /bin/bash path="$@" emacsclient -n -a textpad "$(cygpath -u "$path")" ------------- And the resulting command line: c:\cygwin\home\<myuid>\bin\emacsclientbat.bat "{path-slashes}" I wouldn't mind finding a "cleaner" solution, but if not, this will work. Oct 19, 2009 issue 8 (Troubles with quoting connecting with Cygwin executables) commented on by sandipchitale - Probably some quote escaping will do the trick. I will have a look once I am on a windows machine and see if I can help you. Probably some quote escaping will do the trick. I will have a look once I am on a windows machine and see if I can help you. Oct 19, 2009 issue 8 (Troubles with quoting connecting with Cygwin executables) reported by davidmichaelkarr - This would be better discussed in a forum or mailing list, but there doesn't appear to be anything like that for this plugin. I'm on WinXP with Eclipse 3.5.1, along with Cygwin 1.5.25. I've had no trouble setting "Textpad" as my external editor, but I've had no luck trying to get PathTools to connect to an editor built with Cygwin, like "emacsclient" (for emacs). The problem is quoting, but I don't know if there's really a bug here, or whether I just haven't figured out the correct arrangement to get this to work. What I have so far is this command line: c:\cygwin\bin\bash -l -c "c:/cygwin/home/<myuid>/bin/emacsclienttocyg "{path-slashes}"" Where "emacsclienttocyg" is this: ------------- #! /bin/bash set -x path="$@" emacsclient -n -a textpad "$(cygpath -u "$path")" ------------- When I click the "Open in External Editor" button, I see this in the Eclipse console: --------------- c:\cygwin\bin\bash -l -c "c:/cygwin/home/<myuid>/bin/emacsclienttocyg "C:/Documents and Settings/<myuid>/<restofpathtofile>"" + path=C:/Documents ++ cygpath -u C:/Documents + emacsclient -n -a textpad /c/Documents --------------- As you can see, only the first word of the path got through. I've tried numerous variations of quoting (which is why i tried the intermediate Bash script), but nothing resolves this particular issue. This would be better discussed in a forum or mailing list, but there doesn't appear to be anything like that for this plugin. I'm on WinXP with Eclipse 3.5.1, along with Cygwin 1.5.25. I've had no trouble setting "Textpad" as my external editor, but I've had no luck trying to get PathTools to connect to an editor built with Cygwin, like "emacsclient" (for emacs). The problem is quoting, but I don't know if there's really a bug here, or whether I just haven't figured out the correct arrangement to get this to work. What I have so far is this command line: c:\cygwin\bin\bash -l -c "c:/cygwin/home/<myuid>/bin/emacsclienttocyg "{path-slashes}"" Where "emacsclienttocyg" is this: ------------- #! /bin/bash set -x path="$@" emacsclient -n -a textpad "$(cygpath -u "$path")" ------------- When I click the "Open in External Editor" button, I see this in the Eclipse console: --------------- c:\cygwin\bin\bash -l -c "c:/cygwin/home/<myuid>/bin/emacsclienttocyg "C:/Documents and Settings/<myuid>/<restofpathtofile>"" + path=C:/Documents ++ cygpath -u C:/Documents + emacsclient -n -a textpad /c/Documents --------------- As you can see, only the first word of the path got through. I've tried numerous variations of quoting (which is why i tried the intermediate Bash script), but nothing resolves this particular issue. Sep 15, 2009 r85 (Add return statement.) committed by sandipchitale - Add return statement. Add return statement. Sep 07, 2009 r84 (Fix imports. Fix the action for Shell menu on toolbar.) committed by sandipchitale - Fix imports. Fix the action for Shell menu on toolbar. Fix imports. Fix the action for Shell menu on toolbar. Aug 29, 2009 r83 (Better Command Line Shelll at menu.) committed by sandipchitale - Better Command Line Shelll at menu. Better Command Line Shelll at menu. Aug 28, 2009 PathToolsToolbar3.png (Path Tools Toolbar) file uploaded by sandipchitale Aug 27, 2009 r82 (Make Command Line Shell action a pull down action.) committed by sandipchitale - Make Command Line Shell action a pull down action. Make Command Line Shell action a pull down action. May 11, 2009 issue 7 (UI enhancement proposals) Labels changed by sandipchitale - Labels: −tg Labels: −tg May 11, 2009 issue 7 (UI enhancement proposals) commented on by sandipchitale - Added a download for the plugin: http://pathtools.googlecode.com/files/PathTools_1.0.47.jar Added a download for the plugin: http://pathtools.googlecode.com/files/PathTools_1.0.47.jar May 11, 2009 PathTools_1.0.47.jar (PathTools 1.0.47 for Eclipse 3.4+) file uploaded by sandipchitale May 07, 2009 issue 7 (UI enhancement proposals) commented on by peter.waldispuehl - I saw that there is a new version provided via Eclipse Update site. Can you please also provide a separate download for new versions? 1. To easily try plugins, I use the new 'drop-ins' folder in Eclipse /install/deinstall plugins. I think this is a much better approach than via update site .. 2. If you happen to site behind a firewall that does not allow direct outside connections, you can't use Eclipse update sites at all. You then need to download and install plugins manually. I saw that there is a new version provided via Eclipse Update site. Can you please also provide a separate download for new versions? 1. To easily try plugins, I use the new 'drop-ins' folder in Eclipse /install/deinstall plugins. I think this is a much better approach than via update site .. 2. If you happen to site behind a firewall that does not allow direct outside connections, you can't use Eclipse update sites at all. You then need to download and install plugins manually. Apr 12, 2009 issue 7 (UI enhancement proposals) Labels changed by sandipchitale - :) I have not yet gotten a chance to generalize/unify the notion of folders and file command. Another idea I have in mind is to further classify the file commands based on the file extension or type and also somehow import OS level registered programs. And also support - org.eclipse.swt.program.Program. Labels: tg :) I have not yet gotten a chance to generalize/unify the notion of folders and file command. Another idea I have in mind is to further classify the file commands based on the file extension or type and also somehow import OS level registered programs. And also support - org.eclipse.swt.program.Program. Labels: tg Apr 12, 2009 issue 7 (UI enhancement proposals) commented on by peter.waldispuehl - Another feedback: I was positively surprised that you support MacOSX. Another feedback: I was positively surprised that you support MacOSX. Apr 11, 2009 r81 (Cleanup.) committed by sandipchitale - Cleanup. Cleanup. Apr 11, 2009 r80 (Remove warning.) committed by sandipchitale - Remove warning. Remove warning. Apr 11, 2009 r79 (Use Eclipse 3.4 reccommended preferences initializer.) committed by sandipchitale - Use Eclipse 3.4 reccommended preferences initializer. Use Eclipse 3.4 reccommended preferences initializer. Apr 09, 2009 r78 (Handle UNC paths on windows. ) committed by sandipchitale - Handle UNC paths on windows. Handle UNC paths on windows. Apr 02, 2009 r77 ([No log message]) committed by sandipchitale - [No log message] [No log message] Apr 02, 2009 r76 (Make Explore and CopyPath sub menus in object constribution ...) committed by sandipchitale - Make Explore and CopyPath sub menus in object constribution pop-up menus. Make Explore and CopyPath sub menus in object constribution pop-up menus. Mar 30, 2009 r75 (Use DirectoryDialog to choose Go to directory.) committed by sandipchitale - Use DirectoryDialog to choose Go to directory. Use DirectoryDialog to choose Go to directory. Mar 29, 2009 issue 7 (UI enhancement proposals) commented on by peter.waldispuehl - Cool! Thanks. Cool! Thanks. Mar 28, 2009 issue 1 (Windows: Command is put in quotes before execution) Status changed by sandipchitale - As there is a workaround to insert a space I am not planning to fix this. Status: WontFix As there is a workaround to insert a space I am not planning to fix this. Status: WontFix Mar 28, 2009 issue 2 (Enhancement: Hide menu entries if command is empty) Status changed by sandipchitale - All actions have been moved to Path Tools sub menu. See if this works for you or not. Status: WontFix All actions have been moved to Path Tools sub menu. See if this works for you or not. Status: WontFix Mar 28, 2009 issue 4 (Copy qualified name feature) Status changed by sandipchitale - Added the Copy FQN (Java) action to the Copy Paths drop down menus. Status: Fixed Added the Copy FQN (Java) action to the Copy Paths drop down menus. Status: Fixed Mar 28, 2009 r74 (Add Copy FQN (Java) Action to the Copy Paths menu.) committed by sandipchitale - Add Copy FQN (Java) Action to the Copy Paths menu. Add Copy FQN (Java) Action to the Copy Paths menu. Mar 28, 2009 issue 7 (UI enhancement proposals) Status changed by sandipchitale - I have implemented your suggestion 1 and 2. Your third suggestion has been on my mind for a while now. The current state is the way it is because initially I had not implemented Custom commands. Status: Started I have implemented your suggestion 1 and 2. Your third suggestion has been on my mind for a while now. The current state is the way it is because initially I had not implemented Custom commands. Status: Started Mar 28, 2009 r73 (Set the menu creator on the action only once.) committed by sandipchitale - Set the menu creator on the action only once. Set the menu creator on the action only once. Mar 28, 2009 r72 ([No log message]) committed by sandipchitale - [No log message] [No log message] Mar 28, 2009 r71 (Mostly implement issue 7. Group all the Path Tools actions ...) committed by sandipchitale - Mostly implement issue 7. Group all the Path Tools actions in a Path Tools sub menu in context and top level menus. Mostly implement issue 7. Group all the Path Tools actions in a Path Tools sub menu in context and top level menus. Mar 27, 2009 r70 (Fix the Windows Open Command Line Shell command to correctly...) committed by sandipchitale - Fix the Windows Open Command Line Shell command to correctly track the drive in the path. Fix the Windows Open Command Line Shell command to correctly track the drive in the path. Mar 27, 2009 issue 7 (UI enhancement proposals) changed by sandipchitale - Thanks for your excellent suggestions. I will look into it. Status: Accepted Labels: Type-Enhancement −Type-Defect Thanks for your excellent suggestions. I will look into it. Status: Accepted Labels: Type-Enhancement −Type-Defect Mar 27, 2009 issue 7 (UI enhancement proposals) commented on by peter.waldispuehl - This should actually be an entry of type 'Enhancement' not 'Defect'. How do a change that? This should actually be an entry of type 'Enhancement' not 'Defect'. How do a change that? Mar 27, 2009 issue 7 (UI enhancement proposals) reported by peter.waldispuehl - Thanks for your plugin. Some proposals which should IMHO increase user performance and hence acceptance: 1. Using a sub-menue for all path tools entries (instead of several menue entries) in the context menu would be a good idea, since: * the context menu is often too crowded anyway and * it slowes down the opening of the context menu. 2. Adding the 'custom folder command' and 'custom file commands' entries in this sub-menue would be appreciated, too. This feature is IMHO the most valueable addition your plungin provides over similar plugins like Ease Shell, ExploreFS, etc. Having the custom entries only in the button bar is too inflexible: Users normally search / use either the button bar or the context menue and don't like to "operate in a mixed mode". 3. Adding a short, descriptive name for 'custom folder commands' and 'custom file commands' which is used in the menues would be a greate idea, too. Shell command tend to be unreadable. E. g. I use the following two entires, which differ only in a version number in the middle of the string. * cmd.exe /C start /D "{path}" cmd.exe /C "D:\data\cvs_pws_clps\buildrules- 1.6.0\bin\shell.cmd clps342" * cmd.exe /C start /D "{path}" cmd.exe /C "D:\data\cvs_pws_clps\buildrules- 1.5.2\bin\shell.cmd clps342" Having something like * Buildrules V1.6.0 * Buildrules V1.5.2 which executes those to entries would be much more readable. In fact reducing the preferences to only 'folder commands' and 'file commands' would be way more flexible than the current distinction between hard coded commands like "Explore .." "Shell at .." and Custom commands. You could instead enhanced the 'Custom ..' part having entries with a 'description' (used as name in sub-menue) and a 'command' (is executed) and with default entries for the current "Explore .." "Shell at .." etc. part. Thanks for your plugin. Some proposals which should IMHO increase user performance and hence acceptance: 1. Using a sub-menue for all path tools entries (instead of several menue entries) in the context menu would be a good idea, since: * the context menu is often too crowded anyway and * it slowes down the opening of the context menu. 2. Adding the 'custom folder command' and 'custom file commands' entries in this sub-menue would be appreciated, too. This feature is IMHO the most valueable addition your plungin provides over similar plugins like Ease Shell, ExploreFS, etc. Having the custom entries only in the button bar is too inflexible: Users normally search / use either the button bar or the context menue and don't like to "operate in a mixed mode". 3. Adding a short, descriptive name for 'custom folder commands' and 'custom file commands' which is used in the menues would be a greate idea, too. Shell command tend to be unreadable. E. g. I use the following two entires, which differ only in a version number in the middle of the string. * cmd.exe /C start /D "{path}" cmd.exe /C "D:\data\cvs_pws_clps\buildrules- 1.6.0\bin\shell.cmd clps342" * cmd.exe /C start /D "{path}" cmd.exe /C "D:\data\cvs_pws_clps\buildrules- 1.5.2\bin\shell.cmd clps342" Having something like * Buildrules V1.6.0 * Buildrules V1.5.2 which executes those to entries would be much more readable. In fact reducing the preferences to only 'folder commands' and 'file commands' would be way more flexible than the current distinction between hard coded commands like "Explore .." "Shell at .." and Custom commands. You could instead enhanced the 'Custom ..' part having entries with a 'description' (used as name in sub-menue) and a 'command' (is executed) and with default entries for the current "Explore .." "Shell at .." etc. part. Mar 24, 2009 r69 (Add Custom commands... menu item to the drop down.) committed by sandipchitale - Add Custom commands... menu item to the drop down. Add Custom commands... menu item to the drop down. Mar 24, 2009 PathToolsToolbar110x80.3.png (PathTools Toolbar) file uploaded by sandipchitale Mar 24, 2009 PathToolsToolbar110x80.2.png (PathTools Toolbar) file uploaded by sandipchitale Mar 24, 2009 PathToolsToolbar3.png (PathTools Toolbar) file uploaded by sandipchitale Mar 24, 2009 PathTools_1.0.36.jar (PathTools Plug-in for Eclipse 3.4) file uploaded by sandipchitale Mar 23, 2009 r68 (Fix Mac OSX shell launch command) committed by sandipchitale - Fix Mac OSX shell launch command Fix Mac OSX shell launch command Mar 22, 2009 PathToolsPreferences2.png (PathTools Preferences Page) file uploaded by sandipchitale Mar 22, 2009 PathToolsPreferences1.png (PathTools Preferences Page) file uploaded by sandipchitale Mar 22, 2009 PathToolsToolbar2.png (PathTools Toolbar) file uploaded by sandipchitale Mar 22, 2009 r67 (Fix text in preferences page.) committed by sandipchitale - Fix text in preferences page. Fix text in preferences page. Mar 22, 2009 r66 ([No log message]) committed by sandipchitale - [No log message] [No log message] Mar 22, 2009 r65 ([No log message]) committed by sandipchitale - [No log message] [No log message] Mar 21, 2009 r64 (Allow exploring of all parent folders.) committed by sandipchitale - Allow exploring of all parent folders. Allow exploring of all parent folders. Mar 19, 2009 r63 ([No log message]) committed by sandipchitale - [No log message] [No log message]

issue 7 (UI enhancement proposals) reported by peter.waldispuehl - Thanks for your plugin. Some proposals which should IMHO increase user performance and hence acceptance: 1. Using a sub-menue for all path tools entries (instead of several menue entries) in the context menu would be a good idea, since: * the context menu is often too crowded anyway and * it slowes down the opening of the context menu. 2. Adding the 'custom folder command' and 'custom file commands' entries in this sub-menue would be appreciated, too. This feature is IMHO the most valueable addition your plungin provides over similar plugins like Ease Shell, ExploreFS, etc. Having the custom entries only in the button bar is too inflexible: Users normally search / use either the button bar or the context menue and don't like to "operate in a mixed mode". 3. Adding a short, descriptive name for 'custom folder commands' and 'custom file commands' which is used in the menues would be a greate idea, too. Shell command tend to be unreadable. E. g. I use the following two entires, which differ only in a version number in the middle of the string. * cmd.exe /C start /D "{path}" cmd.exe /C "D:\data\cvs_pws_clps\buildrules- 1.6.0\bin\shell.cmd clps342" * cmd.exe /C start /D "{path}" cmd.exe /C "D:\data\cvs_pws_clps\buildrules- 1.5.2\bin\shell.cmd clps342" Having something like * Buildrules V1.6.0 * Buildrules V1.5.2 which executes those to entries would be much more readable. In fact reducing the preferences to only 'folder commands' and 'file commands' would be way more flexible than the current distinction between hard coded commands like "Explore .." "Shell at .." and Custom commands. You could instead enhanced the 'Custom ..' part having entries with a 'description' (used as name in sub-menue) and a 'command' (is executed) and with default entries for the current "Explore .." "Shell at .." etc. part.

Thanks for your plugin. Some proposals which should IMHO increase user performance and hence acceptance: 1. Using a sub-menue for all path tools entries (instead of several menue entries) in the context menu would be a good idea, since: * the context menu is often too crowded anyway and * it slowes down the opening of the context menu. 2. Adding the 'custom folder command' and 'custom file commands' entries in this sub-menue would be appreciated, too. This feature is IMHO the most valueable addition your plungin provides over similar plugins like Ease Shell, ExploreFS, etc. Having the custom entries only in the button bar is too inflexible: Users normally search / use either the button bar or the context menue and don't like to "operate in a mixed mode". 3. Adding a short, descriptive name for 'custom folder commands' and 'custom file commands' which is used in the menues would be a greate idea, too. Shell command tend to be unreadable. E. g. I use the following two entires, which differ only in a version number in the middle of the string. * cmd.exe /C start /D "{path}" cmd.exe /C "D:\data\cvs_pws_clps\buildrules- 1.6.0\bin\shell.cmd clps342" * cmd.exe /C start /D "{path}" cmd.exe /C "D:\data\cvs_pws_clps\buildrules- 1.5.2\bin\shell.cmd clps342" Having something like * Buildrules V1.6.0 * Buildrules V1.5.2 which executes those to entries would be much more readable. In fact reducing the preferences to only 'folder commands' and 'file commands' would be way more flexible than the current distinction between hard coded commands like "Explore .." "Shell at .." and Custom commands. You could instead enhanced the 'Custom ..' part having entries with a 'description' (used as name in sub-menue) and a 'command' (is executed) and with default entries for the current "Explore .." "Shell at .." etc. part.

Older