TEMP env var is corrupted when running external app

You fail to say how this affects your use of native programs? I.E.: Why are you concerned about D:/Temp instead of D:\Temp?

Consider the following perl script:

$TDIR=$ENV{TEMP};
$fname = "$TDIR\\hello.txt";
open (test, ">$fname");
print test "Hello\n";
close (test);

Running on cmd, NOT running under msys...

What perl are you trying to run, in your example? If it is the MSYS perl, then you should be running it from the MSYS shell, *not* from cmd.exe. Attempting to run *any* MSYS program from cmd.exe is an ID-ten-T user error; such usage is unsupported.

FWIW, your example WJFFM, when correctly run using MSYS perl, invoked from the MSYS shell prompt.

Even so, I have no issue with the sample given with either running in a cmd.exe environment or a MSYS bash environment. I tested both the MSYS dependent perl and the ActiveState version of perl. Therefore I've closed the ticket but feel free to comment if you have more information.

Do you seriously suggest that msys SHOULD manipulate environment variables? I can't see your point.

Even if my small example (I'm using ActivePerl v5.12.3) does work, is this an expected behavior?

Here is a command that won't work as expected when run from msys:
@if %TEMP%==D:\TEMP (echo Hello) else (echo Goodbye)

If %TEMP% is set to D:\TEMP, on cmd it prints Hello, on cmd run from msys it prints Goodbye.

Another example (from command line):
copy file.ext %TEMP%

Works on cmd, doesn't work when cmd is run from msys...

Yes, it is expected behavior.

Your use of %TEMP% in the MSYS shell isn't correct. The MSYS shell will not evaluate %TEMP% to be the value of a variable but as a literal string. You would need to use $TEMP and as Keith has already stated, that while some things may work it isn't expected that you will be using MSYS from cmd.exe but instead using the MSYS shell. It is also expected that while in the MSYS shell you use POSIX semantics instead of Windows semantics.

I'm not talking about running things directly from msys bash prompt. What I'm talking about is running an external application, which expects %TEMP% to have specific form.

In my case, the application I run is cleartool, which runs triggers for some operations. Those triggers don't work because of that manipulation.

I just tried to show the problem using a simple example. I really find it hard to understand why you're trying so hard to justify this kind of manipulation. It really makes no sense to me...

> I really find it hard to understand why you're trying so hard to justify this kind of manipulation.

MSYS has been out for years and no one else has complained.

> In my case, the application I run is cleartool, which runs triggers for some operations. Those triggers don't work because of that manipulation.

Finally!!! What is cleartool and what is it doing with triggers to cause an issue with the value of %TEMP% using a / instead of a \? I assume this is a command line tool that you're using in the MSYS shell. Do you have a link to the product you're using and is it open source?

cleartool is the command-line tool for Rational ClearCase, which is neither open-source nor free. It is a (terrible!) version control system.

One of its capabilities is running 'triggers' when certain operations are executed. In my case, when I run 'mkactivity', it runs a trigger that tests against the DB if the activity I requested is valid. This trigger is a perl script, and it just fails when %TEMP% has / instead of \.

So, the perl script fails? Which perl is it running? Is the error raised by the script itself or by perl?

The perl script runs isqlw, and some of its arguments are "-i D:/TEMP\ForClearCase.sql -o D:/TEMP\SqlOutputQuery.txt" (The D:/Temp is parsed by perl). isqlw fails.

Which perl.exe is being executed?

What, if any, is the error message from isqlw?

Rational perl (part of ClearCase) C:\Program Files\Rational\Common\ratlperl.exe.

The error message is 'A file open failure occured on D:'

From my brief look at this issue, it appears that when Windows' cmd.exe is run from an MSYS environment, it is inheriting the MSYS shell's environment variables (which I would expect). However, it looks like only the PATH environment variable gets its slashes converted to the proper convention (/ for MSYS, \ for Windows).

For example: Spawning cmd.exe from an MSYS bash shell and running "set" shows my TEMP environment variable as C:/Users/Username/AppData/Local/Temp, while the PATH is correctly converted to C:\msys\mingw\bin;C:\msys\bin; et cetera.

That's exactly what I described in the first place. Thank you for elaborating.

A work around may be to edit your $HOME/.profile file and add
export TEMP='D:\TEMP'
as a command in your environment setup.

I did something similar, but I would prefer for it to be fixed.

If you modify the TEMP variable in the MSYS shell to be D:\TEMP it will spawn the native environment with that value instead of D:/TEMP. And MSYS doesn't care either. So you can set the value in your .profile file to be the value with the \.

Like I said, that's what I did and it does work, but this is a workaround, not a solution.

> Like I said, that's what I did and it does work, but this is a workaround,
> not a solution. ... I would prefer for it to be fixed.

So, fix it, and submit a patch; it's open source, and you have an equal right to anyone else, (and perhaps more incentive in this case), to contribute to development and maintenance.

For the record, according to MSDN, and with a few excepted contexts, d:/temp is just as acceptable as a Windows path name as is d:\temp; any application which doesn't accept it as such, other than in the excepted contexts, is simply broken. Unfortunately, there are just so many applications in this broken class that it probably would be preferable if MSYS favoured '\' rather than '/' as the directory separator, when expressing a path name in Windows native format.

Ok, I prepared one. http://pastebin.com/Xm3DD6bq