There is no easy way how the user can invoke
external tools (executables) from the IDE, a
functionality which is present in most competitor IDEs
The user needs to invoke some external tool
(executable, script) either as such or
parametrised by a context in the IDE (selected
Add ability to configure external tools and invoke
Passing to core/execution, please reassign further if I'm wrong. Maybe obsoleted now?
I also think the ability to configure and invoke external tools is a very useful feature which I am unfortunately still
missing in NetBeans IDE. That's the main reason why we use Eclipse instead of NetBeans.
Perhaps, if the feature will be implemented, the behavior coud be similar to the external tools feature in Eclipse
Platform because the behavior of that implementation is very good.
The description of this issue describes the requirements of the feature exactly.
This is still a relevant feature, most recently requested here: http://www.netbeans.org/issues/show_bug.cgi?id=89894#desc31
Also, the design was already suggested in wiki:
Some more discussion about this request: http://forums.netbeans.org/topic17636.html
Another request for this feature in a NB vs. Eclipse discussion:
"What ive found is that Eclipse ... just has more useful avialable plugins and even built in functionality. For example the "External Tools" system. I cant live with out it. its so nice being able to execute something right from within Eclipse without have to switch back to my term."
ugh, every editor, IDE, which I know, has this future, netbeans no, I was very surprised when I found out this bug.
The guy who wrote this article would also presumably benefit from this enhancement:
E.g.: "But actually, on my side there's not only Vim: within its environment I can take advantage of many command line tools, so it's more a comparison between Unix command line tools and NetBeans as an Integrated Development Environment. I will use Vim as an umbrella term for the use of the command line and the terminal over the IDE.
In general, command line tools can be used quickly without exiting Vim simply by prefixing the commands with the ! character (which can be used to call any external binary)."
*** Bug 209158 has been marked as a duplicate of this bug. ***
When resolving this issue please take into account comments from issue 209158, especially:
Have a look at the "quick opener" plugin.
This allows you to run arbitrary external commands.
Quite good, but it does not setup application working directory.
Started executable cannot locate it's resources (In reply to comment #10)
> Have a look at the "quick opener" plugin.
> This allows you to run arbitrary external commands.
(In reply to comment #11)
> Quite good, but it does not setup application working directory.
> Started executable cannot locate it's resources (In reply to comment #10)
> > Have a look at the "quick opener" plugin.
> > http://plugins.netbeans.org/plugin/43217/quickopener
> > This allows you to run arbitrary external commands.
So please create a ticket for the plugin owner @ https://github.com/kinkadzs/QuickOpener-NetBeans/issues to support the manual setting of the working directory
Well, it's been 11 years since this bug was opened, and there is still no valid solution.
Echoing an existing comment, most IDEs and editors out there have this feature since it extends core functionality much more significantly than say, direct integration with a particular tool (which is where Netbeans team has been heading to for quite some time).
Regarding this https://github.com/dzsessona/QuickOpener-NetBeans/issues/44 a workaround could be to run a command as:
(cd /whatever/folder; cmd)
If the problem is just the folder where the command will run. I will add it to the configuration as soon as i get a bit of time.
Created attachment 146364 [details]
Example for UI to run external tools (in ConTEXT editor)
This image should help understand how others solved the problem.
First: I'm afraid it is not that easy.
Second: we have had 11 years of "workarounds". What we need is a solution!
How it SHOULD (!) work:
The user wants to define a set of commands to run on the command line by either pressing a button, a key-combo or selecting it from a drop-down.
Each "command" must be bound to a named "command set".
Each "command set" must be bound to a MIME-type.
The "command set" has the following properties:
- Name (for GUI)
The "command" has the following properties:
- Name (for GUI)
- Command to execute
- Directory to execute the command in (Default: same as command)
- Capture console output? (yes/no)
Command parameters MUST allow for dynamic parts (if they don't, the whole show is useless!)
We must be able to pass:
- current file name
- current file path including file name
- current file path excluding file name
- current file extension
- current line number
- current column number
- word under cursor
The command(s) composed might look something like this:
/path/file.ext -f %filepath% -w %word_at_cursor%
Where the parameters are replaced before sending them to the console, of course!
/path/tools/create_sceleton -f /my_project/ -w MyFooClass
These are the minimum requirements. Anything less is not helpful.
Additional features that would be nice to have:
- be able to run the command window minimized
- be able to define a list of arbitrary custom-parameters for each "command" like %p1%, %p2% and have Netbeans prompt the user to enter them in a dialog when the command is invoked.
- have Netbeans auto-safe the open file before executing the command
- being able to run the command for all selected files
Why we need it:
- batch execution/conversion
- easy per-user integration of external tools without need for programming
- to integrate arbitrary command line tools (Skeleton generators, third-party interpreters, custom batch-scripts)
- run scripts in arbitrary languages that Netbeans doesn't support out of the box
- workflow integration with external software programs
- because it's always good to be able to automate a task!
- because it looks cool to have the magic power of "The Batch-Script" at your fingertips.
- other reasons...
You get the picture!
This is what other editors and IDEs have since more than 15 years. And it's really, really about time!