[MinGW-notify] [ mingw-Bugs-3391275 ] TEMP env var is corrupted when running external app

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #3391275, was opened at 2011-08-13 22:20
Message generated for change (Comment added) made by orgads
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3391275&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: Known Feature
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Orgad Shaneh (orgads)
Assigned to: Cesar Strauss (cstrauss)
Summary: TEMP env var is corrupted when running external app

Initial Comment:
On my machine, TEMP environment variable is defined as 'D:\Temp'.

When I run msys, 'echo $TEMP' gives '/tmp', and 'msysmnt' shows that D:\Temp is mounted on /tmp. That's fine.

When I run an external application from msys, the TEMP variable is modified to 'D:/Temp'.

To reproduce: Run msys, from it, run cmd /c "echo %TEMP%"

----------------------------------------------------------------------

>Comment By: Orgad Shaneh (orgads)
Date: 2012-05-16 02:30

Message:
Ok, that's really strange. Running cmd /c "echo %TEMP%" indeed prints it
with forward slashes, but replacing cmd with cmd.exe does print it with
native slashes (with my patch).

Tried with ActivePerl, it prints forward slashes.

Any ideas?

----------------------------------------------------------------------

Comment By: Cesar Strauss (cstrauss)
Date: 2012-03-15 18:03

Message:
Sorry, your patch doesn't work for me. After applying it, I still get:

$ cmd /c "echo %TEMP%"
C:/Users/cstrauss/AppData/Local/Temp

Earlier, I intended to investigate this further, but ran out of time.

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2012-03-14 00:55

Message:
?

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-19 04:22

Message:
Thanks a lot for your help. I really appreciate it.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-08-19 04:13

Message:
> I couldn't attach the file because the issue was closed...

I thought the ticket originator could do that, or at least reopen the
ticket to progress it.  Maybe I'm wrong on that; as administrator, I have
more extensive privileges.

> Thanks for doing that.

NP.  Thanks also for the tentative ChangeLog.  For future reference:

- There's no need to post the whole file; just the entry to add suffices.

- Your entry should identify each modified file, and function/macro/entity
within it, as appropriate; format is defined by the GNU Coding Standards.

- You may include this within the patch file itself, but NOT as part of the
patch proper, (i.e. not in diff format).

- Normally, the maintainer will adjust the date, to reflect when he applies
the patch; thus, it's permissable to fill the date field with query marks.

I've attached an updated patch, (recreated using 'hg diff -p >> patchfile',
where patchfile initially contains the ChangeLog addendum, having applied
your original patch to a local mercurial repository copy of the pertinent
file, in its correct path from the MSYS CVS), to illustrate the concept.

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-18 04:25

Message:
You're welcome.

I couldn't attach the file because the issue was closed... Thanks for doing
that.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-08-18 04:11

Message:
Thanks for the patch.

Attaching it to the ticket would have been infinitely preferable to posting
it on pastebin.  Never mind: on this occasion only, I've done that for you.
 Please do it yourself for any future patches you may wish to submit.

Adding your own ChangeLog entry would also be appreciated.  If you wait for
us to write it, processing of your patch may be delayed.

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-18 00:26

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

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-08-17 13:27

Message:
> 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.

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 13:09

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

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-08-17 12:48

Message:
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 \.

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 12:43

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

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-08-17 12:41

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

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 12:41

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

----------------------------------------------------------------------

Comment By: Andrew (guln)
Date: 2011-08-17 12:38

Message:
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.

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 06:11

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

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

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-08-17 06:09

Message:
Which perl.exe is being executed?

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

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 05:54

Message:
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.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-08-17 05:52

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

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 05:39

Message:
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 \.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-08-17 05:16

Message:
> 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?

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-16 06:15

Message:
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...

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-08-16 05:34

Message:
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.

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-15 22:03

Message:
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...

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-08-15 10:10

Message:
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.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-08-15 07:49

Message:
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.

----------------------------------------------------------------------

Comment By: Orgad Shaneh (orgads)
Date: 2011-08-15 06:50

Message:
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...

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-08-15 06:33

Message:
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?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3391275&group_id=2435

[MinGW-notify] [ mingw-Bugs-3391275 ] TEMP env var is corrupted when running external app

A native Windows port of the GNU Compiler Collection (GCC)

[MinGW-notify] [ mingw-Bugs-3391275 ] TEMP env var is corrupted when running external app