I seem to be getting different path strings returned from very similar commands.
If I start a shell window using the non-rxvt MSYS link and do the following:
$ cd /c/mingw/bin; pwd
$ echo $(cd ..; pwd)
$ echo $(cd "$MGWROOT"; pwd)
I wouldn't have expected the output to be any different. Maybe it's because MGWROOT is in a windows formatted path and when the variable gets expanded something is happening under the hood? But what's really odd is that there have been instances when, for the example above, $(cd ..; pwd) has returned /mingw .
There's a bash file for doing builds that's used on nix systems as well as windows. The user can set some environment variables for cross compiling. On windows, the user is setting the path strings in windows format and we use the following code to do the conversion to an msys formatted string, so no sed required.
# code for checking the OS and other code omitted.
if (ls -d "$BLDROOT" 2>/dev/null); then
BLDROOT =$(cd "$BLDROOT"; pwd)
Then there's a sanity check to see if the build script is being run from the folder where the environment variable was set, e.g.
DIR1=$(cd ..; pwd)
DIR2=$(cd "$BLDROOT"; pwd)
if [ "$DIR1" != "$DIR2" ]; then
echo "$BLDROOT blah, blah blah:
The above path conversion code works great (on windows) as long as the build folder doesn't reside in either the MinGW or MSYS folders. If it does, the DIR1 check against DIR2 fails, even though the build's root folder and the environment variable coincide. The conditional check fails because DIR1=/c/mingw/src isn't the same as DIR2=/mingw/src textually. But it doesn't always fail, on some occasions DIR1 will be set correctly to /mingw/src.