MSYS2 is a fork of Cygwin. Many things that are true in Cygwin are also true for MSYS2, but not all. The Goal of Cygwin was to create a Unix-like / Linux-like environment which runs on Windows - as such is tries to do everything in Linux-like way with very few exceptions. MSYS2 has the goal of creating a Unix-like / Linux-like software development environment for developing native windows binary software without having to forgo familiar Linux tools. In my personal experience this boils down to a few concrete differences. MSYS2 provides packages using pacman ported from Arch Linux. Cygwin provides packages with a Windows Executable called setup.exe (or more recently setup-x86.exe AND/OR setup-x86_64.exe). The MSYS2 package manager is meant to be run from the MSYS2 command line and the Cygwin package manager is meant to be run from Windows, and often requires a reboot - or in the very least completely shutting down all Cygwin executable (including daemons like sshd). Python on MSYS2 works well and is both Windows and MSYS2 aware (and has many patches from the MSYS2 team to make sure that it works and keep working). Python under Cygwin is Cygwin awair but not Windows aware - the ctypes packas works only with linux-like libraries and not well with Windows DLLs (and the Python Community like it that way and will not accept any Cygwin specific packages into the main CPython project). The biggest difference is that MSYS2 linux-like binaries are built for use in the MSYS2 environment (using and relying on the MSYS2 DLL which offers all the Linux-like behavior) and also as stand-alone WIndows executables (32 and 64 bit binaries) which use only standard issues Microsoft Windows DLLs. The KDE team as adopted MSYS2 and continues to develop and extend it and uses it to develop the Windows ports of KDE tools, executables and libraries. I recently installed the KDevelop tool for Windows and it works quite well as a stand-alone Windows executable.
Some MSYS2 / Cygwin things to be aware of: Java is available primarily as a "Windows Executable" so, for example, it is not aware of MSYS2 / Cygwin mounts, paths, or line-endings. Java on Windows detects that it is running on Windows and assumes all path names are separated by "\" and not "/" and start with "C:\" and not with "/bin" or "/usr/bin" (etc.) or "/cygdrive/c/" . It assumes that all text files have lines delimited with '\r\n' and no file have lines delimited with '\n'. In mind these are foolish assumption to be made by a language or standard library, but this is the reality of mixing MSYS2 / Cygwin with java. If go-cd agent on Windows is capable of running a binary executable on Windows (from PowerShell or any other way e.g. The java.lang.Runtime.getRuntime() method) then it can run the MSYS2 bash.exe. There are three versions of the MSYS2 bash executable, the one that uses the MSYS2 DLL, and two stand alone windows executables (one a 32bit binary and one a 64bit binary). The full path for the executable should be specified with "DOS-slash" and not with "Unix-slash" such as "C:\MSYS2\bin\bash.exe" , but any arguments given to it may use "Unix-slash" and probably should. Java and/or windows will not honor the Linux she-bang so you cannot simply run a script by name - bash, however will honor it. Command line arguments with quotes, and nested quotes is another hurtle to consider. The easiest solution is to use no quotes as all, and to embed any arguments in the script instead. Windows. If you really want the details: MSYS2 and Java on Windows use the Windows CreateProcessA or CreateProcessW DLL method (the one uses "ascii" which is really Windows-1252 or CP-437 the other uses "Wide Characters" which is called "Unicode" and is actually something close to UTF-16LE). The second argument is called lpCommandLine and is all command-line-arguments combined into one string. The rules of parsing these arguments into more-than-one argument (which is done by each executable and not by the shell) and may be done ad-hoc or may use the windows GetCommandLineA or GetCommandLineW and CommandLineToArgvW DLL methods but may not. You can google them for details. Running the bash executable with a single command line argument of the full path name of your script should result in the bash script running. For Example: C:\msys2\bin\bash.exe /home/jjones/bin/myscript.bash Once you have managed to run a bash script your bash script can use "cygpath" to convert back and forth from DOS/Widows filenames and Unix/Linux stile command lines. (It can also be used from Java, Jython, JRuby, Groovy etc with some effort.) The bash script should have all the "Linux-like" behaviors you associate with MSYS2 / Cygwin. You could also try using the https://github.com/gocd-contrib/script-executor-task plugin and see if it helps at all in your situation. I haven't tried it on Windows+MSYS2 but we use if for Linux tasks. For additional help you should find and use the user support forums for MSYS2 and/or Cygwin. One last thing: Linux executables which start scripts, such as cron or login-deamons set up some basic envronment variables and other environmental features (current working directory and umask). These are then inhereted by any subprocesses which are started so they are easy to assume to be "just there" but may not exist when you are starting processes in an unusualy way - like AutoSys. In my experience even cron on different flavors of Linux / Unix may or may not set these things. I have created the following "template" which I cut-and-paste to the top of scripts to be run from process automation tools - i call it my "CRON SAFE START". Here it is: #!/bin/bash ### https://linux.die.net/man/1/login ### https://linux.die.net/man/5/crontab ### https://unix.stackexchange.com/questions/76354/who-sets-user-and-username-environment-variables PATH_ORIG="$PATH" ; export PATH_ORIG ; echo "PATH_ORIG=$PATH_ORIG" PATH=/usr/local/bin:/bin:/usr/bin ; export PATH ; echo "PATH=$PATH" SCRIPT_USERNAME="$(whoami)" ; export SCRIPT_USERNAME ; echo "SCRIPT_USERNAME=$SCRIPT_USERNAME" SCRIPT_UMASK=0022 ; export SCRIPT_UMASK ; echo "SCRIPT_UMASK=$SCRIPT_UMASK" LOGNAME="$SCRIPT_USERNAME" ; export LOGNAME ; echo "LOGNAME=$LOGNAME" USER="$SCRIPT_USERNAME" ; export USER ; echo "USER=$USER" USERNAME="$SCRIPT_USERNAME" ; export USERNAME ; echo "USERNAME=$USERNAME" HOME="$( /bin/bash --norc --noprofile -c 'echo ~'"$USER" )" ; export HOME ; echo "HOME=$HOME" SHELL=/bin/bash ; export SHELL ; echo "SHELL=$SHELL" TERM=dumb ; export TERM ; echo "TERM=$TERM" #SCRIPT_LANG="C" ; export SCRIPT_LANG ; echo "SCRIPT_LANG=$SCRIPT_LANG" SCRIPT_LANG="en_US.UTF-8" ; export SCRIPT_LANG ; echo "SCRIPT_LANG=$SCRIPT_LANG" LANG="$SCRIPT_LANG" ; export LANG ; echo "LANG=$LANG" LANGUAGE="$SCRIPT_LANG" ; export LANGUAGE ; echo "LANGUAGE=$LANGUAGE" LC_ALL="$SCRIPT_LANG" ; export LC_ALL ; echo "LC_ALL=$LC_ALL" #TZ="UTC0" ; export TZ ; echo "TZ=$TZ" TZ="America/New_York" ; export TZ ; echo "TZ=$TZ" cd "$HOME" umask "$SCRIPT_UMASK" Brian Fennell -- You received this message because you are subscribed to the Google Groups "go-cd" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CAGJwi9iiTuL0un%2BwMAnSJz7B_cWdC3%2B1nvUkYcxGNBxsybyMiQ%40mail.gmail.com.
