Running Windows batch files from eclipse using workspace-relative paths

Every now and then even a windows user might feel the urge to run some batch processes.
In eclipse, batch files can be run by right clicking on the file | Open With | System Editor. This runs the batch file in a new console window.
However, the execution of the batch file starts working in the eclipse installation directory. That is, path that are relative to the folder of the batch file are now invalid.
The (seemingly) simplest solution might be to just use absolute file paths. However, this might turn out a bad idea. For example, when sharing the project – as others might store their workspace on a different position within their file systems.

So, basically, there are three ways to avoid this problem.

1. Changing the batch file’s working directory.
2. Using eclipse’s external tools
3. Alternative: Using Ant’s exec task
4. Integrate the shell into eclipse using Wicked Shell Plugin

 

Changing the batch file’s working directory

Add the following line to the beginning of your batch file:

@cd /D %~dp0

This will change the working directory of to the path of the batch file. So every subsequent command in the batch file is relative to the path of the batch file itself.
Note: the /D-switch makes sure the file path is changed even though it resides on a different partition.
You can verify this behavior by executing the current batch file in eclipse:

:: Right now we're in the eclipse working directory
@echo %cd%
@cd /D %~dp0
:: We changed the directory to the script location
@echo %cd%
:: We now can use workspace relative paths!
@pause

This will put out the path to the eclipses installation and then the path to the batch file.
 

Using eclipse’s external tools

This approach offers the advantage that the batch file’s output is shown on the eclipse console view. However, a launch configuration is needed.
The following steps are necessary:

1. In the menu, click Run | External Tools or on the drop down menu next to .
2. Click External Tools configurations….
3. Click Program , then .
4. Choose Location and Working Directory within your workspace.
5. (If you want to persist the launch configuration (e.g. for sharing among your team), go to the Common tab, press the radio button Shared file and enter a path, such as /<project>/launch or whatever suits.)
6. Finally, hit Run and check eclipse’s console view.

 

Using Ant’s exec task

First of all we need an Ant build file:

• Right click on the project | New | File.
• In the upcoming dialog enter a file name ending in “.xml” and press Finish. Note that if you name the file “build.xml”, you will have less trouble running the file later.
• Within the editor paste an Ant-script, such as this:

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE project>
  
  <project name="runBatch" basedir="." default="runBatch">
  
  	<target name="runBatch">
  		<echo>Running batch file directly</echo>
  		<exec executable="test.bat">
  			<!-- <arg value="-p someParam" /> -->
  		</exec>
  
  		<echo>Running batch file using cmd</echo>
  		<exec executable="cmd">
  			<arg value="/c" />
  			<arg value="test.bat" />
  			<!-- <arg value="-p someParam" /> -->
  		</exec>
  	</target>
  </project>
  

  As you can see, there are two ways of running a batch file from ant: Using the exec task directly or using the exec task to run cmd.exe and passing the batch file to this process using the /c-switch (as described in the exec task’s manual). Which one you use, is up to you. Either way, you can pass parameters to the batch file using the <arg> tag.

Now that we have a build file, what will we do with it? If you called it “build.xml” earlier, just right click the file | Run As (or hit Ctrl + F11 from the editor). Then click Ant Build an that’s it!
 
(If you ignored my warning and chose a different file name, you’ll need a run configuration to execute the Ant build. This is pretty much the same as described above for using eclipse’s external tools to execute the batch file directly. Except that you have to click on Ant Build instead of Program.

Using Wicked Shell Plugin

If you’re using the command line a lot, the Wicked Shell might be interesting to you. It allows for using the command line from within eclipse. It also provides a comfortable way of running batch files. See this blog post for more info.
It you’re running eclipse on an OS other than Windows, Wicked Shell works as well. It always runs the system’s default shell, i.e. bash for Linux and OS X.

  
So, if you want to run batch files from eclipse, just choose one of the approaches described above. Personally, I prefer the first approach, because it comes with the least overhead. No additional launch configuration needed, just double click the batch file and that’s it.

For this post I used the eclipse icons published here. As mentioned there, they are part of the Eclipse Project and licensed under the EPL.

Using Unix command-line tools in the Win32 console

Every time when using (or having to use) the command line in Windows, it takes time until your eyes adjust to the darkness. There’s one thing, however, I’ll never get accustomed to: Working without the Unix/Linux/GNU (whatever you wanna call it) command-line tools. Fortunately, I don’t have to get accustomed to that: There’s plenty of solution for solving this problem out there. In this article I’m going to elaborate on these three:

1. The “classic” solutions – Cygwin and virtual machine
2. The lightweight alternative – UnxUtils
3. A surprising alternative – Git

When refering to the Unix/Linux/GNU command-line tools, I’ll stick to to the term Unix tools, as the heading predicts.

• The “classic” solutions

The most popular ways of “getting that Linux feeling on Windows” most likely are Cygwin (a linux-like console, that even provides an X-server) or using a virtual machine like VirtualBox or VMWare and a (small) Linux distribution such as Damn Small Linux.
Of course, not using Windows at all would be a decent solution as well 😉

• The lightweight alternative

There are scenarios, where you might not want to or even can’t install Cygwin or a virtual machine. Maybe you’re just looking for a quick way to access these Unix tools from the windows console and have no use for an X-Sever. For this purpose, I use a collection of tools called UnxUtils. Actually, these tools have been there for a long time. The latest version is five and a half years old! Still, it’s downloaded several hundred times a day – impressive!

Now, the nice thing about these tools is, that they are ports to Windows. That is, they are native Windows applications that can run directly from the Windows command prompt (cmd.exe).
Even better, you don’t need to install anything. Just download, extract to some location on your hard drive (in fact, I even carry the utilities around one my flash drive) and you’re almost there. In order not to type the whole path to the UnxUtils binaries every time you intend to use one of them, this path should be added to the beginning of the PATH environment variable. You can either add it permanently (I did this on my Windows computer) or add it temporarily to a specific instance of cmd.exe. To make the UnxUtils portable, I put this small batch script in the UnxUtils folder on my flash drive:

@set PATH=%~dp0\usr\local\wbin;%PATH%
@cmd

This script opens a console window where you can execute statements like this:

egrep -in "error|exception" c:\parser.log --context=3 > parserLogErrors

Finally, ending the awful task of analyzing logs with Windows “on-board equipment” 🙂

Note that after adding the path to UnxUtil’s binaries to the beginning of PATH, it’s not possible any more to use Windows-tools that have the same name as one of the UnxUtils, such as find and sort. So, if you prefer the windows-style search tool, you better check the contents of the usr\local\wbin in UnxUtils path first and delete the tools you don’t need.

Unfortunately, I ran into a disadvantage of UnxTools. A rather memory intensive operation like this:

find d:\ | xargs grep "someExpression"

yields an error “xargs cannot fork”. The description for this error at GNU says that the system has run out of process slots, “because the system is very busy and the system has reached its maximum process limit, or because you have a resource limit in place and you’ve reached it”. Not enough memory for cmd.exe? Any ideas?
Someone even filed a bug for that problem, but it obviously has never been fixed (as said, the latest version is more than five years old). So, no solution here, unfortunately 😦

• A surprising alternative

More recently I stumbled upon an alternative to UnxTools – Git for Windows. Isn’t that a source code management system? It is, but on Windows, it ships with a console application. When installing Git, you can choose, to either use Git’s console application (Git Bash) or to integrate the Git console’s binaries to Windows’ PATH variable, just as described in the solution above.

Note that neither Git nor UnxUtils contain a native version of vi(m). One way to use it would be the Git Bash. The Git Bash feels very much like Cygwin – so not as lightweight. You can read more about Git Bash and its differences to Cygwin here: A Windows console that does not suck.

To use the Git’s Windows ports of the Unix command-line tools from your flash drive – like described for UnxTools above, without permanently changing the PATH variable – just copy Git’s bin directory and a batch file like the following to the drive:

@set PATH=%~dp0\bin;%PATH%
@cmd

Executing this file will start a console window with the proper PATH set, so you can start finding and greping right away.

Fortunately, the resource error described above doesn’t occur when using the tools provided by Git.
Case closed! 😀