Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

Plugin Information

View Cygpath on the plugin site for more information.

This plugin performs Cygwin path conversion before forking new processes

Applicable situations

One of the challenge in Hudson is how to cope with a heterogeneous cluster (that includes Windows and Unix.) Often you need such a cluster so that you have all the testing environments for your supported platforms, but it makes it harder for jobs to utilize the cluster effectively, because your shell script that run on Unix doesn't run on Windows, and your batch files for Windows won't run on Unix.

One way to cope with this problem is to use Cygwin. This creates a Unix like environment on Windows, so that your build/test scripts can always be written as Unix shell scripts, even when they run on Windows.

This also allows you to mostly use Unix paths on specifying your tool locations (such as JDKs, Ant, CVS, etc.), except it doesn't quite work with Cygwin. You say your shell is in "/bin/bash", and indeed as far as Cygwin is concerned, it's there, but when Hudson forks a new shell, it's somewhere like "c:\cygwin\bin\bash" — you'd need a Cygwin path conversion to be able to successfully fork a process!

This plugin does just that; With this plugin, Hudson converts the executable path to Windows style via cygpath.

To recap,

  • You install Cygwin on all the Windows slaves
  • Jobs on Hudson that assume Unix environment can now run on all the slaves (including Windows ones)
  • In the system configuration, you use Unix paths for all your tools.


Version 1.5 (Nov 7, 2011)
  • Updated to work correctly on 64bit Windows JVMs.
Version 1.4 (Nov 7, 2011)
  • Updated to work with Cygwin 1.7
Version 1.3 (Dec 30 2009)
  • Locate cygpath on the slave node instead of master
  • Fix for when cygpath is found in PATH instead of registry
Version 1.2 (Aug 20 2009)
  • The plugin now locates cygpath.exe from registry entry, so that it works even if cygpath is not in PATH. (JENKINS-4275)
  • Update code for more recent Hudson
Version 1.1 (Aug 18 2009)
  • Fixed an AbstractMethodError with recent versions of Hudson.
Version 1.0 (2009/04/17)
  • Initial release


  1. Unknown User (ochedru)

    This plugin would be even more useful if it could invoke sh (or bash or whatever the shell defined in Jenkins) with the -l option in order to have the proper path set up.

    Otherwise most commands are not found and some others are Windows command (find, sort, etc).

    Also, setting CYGWIN=nodosfilewarning in the shell environment would get rid of cygwin warnings in the log.

  2. Unknown User (ilya_be)

    The plugin apparently assumes that there is only one 32-bit Cygwin installed on each host, and its root directory is recorded in [HKLM\SOFTWARE\Cygwin\setup] in the 32-bit registry.

    Cygwin64 installer stores its data under the same key but in 64-bit registry, which makes it pretty confusing. There seems to be no direct way to force the plugin to choose Cygwin64 on another specific installation.

    Contrary to the description above, adding C:\cygwin64\bin to Windows PATH does not help: the registry entry takes the precedence anyway. So the only workaround I see is setting [HKLM\SOFTWARE\Wow6432Node\Cygwin\setup] rootdir="C:\cygwin64" (and keeping in mind that setup-x86 would use this value as its default destination, if you are unlucky to need both versions up-to-date on the same computer)