#1572 TEMP env var is corrupted when running external app

MSYS
pending
Cesar Strauss
None
Bug
rejected
Unknown
False
2013-02-08
2011-08-14
Orgad Shaneh
No

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%"

Discussion

1 2 > >> (Page 1 of 2)
  • Earnie Boyd
    Earnie Boyd
    2011-08-15

    • milestone: --> 456516
    • status: open --> pending
     
  • Earnie Boyd
    Earnie Boyd
    2011-08-15

    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?

     
  • Orgad Shaneh
    Orgad Shaneh
    2011-08-15

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

     
  • Orgad Shaneh
    Orgad Shaneh
    2011-08-15

    • status: pending --> open
     
  • Keith Marshall
    Keith Marshall
    2011-08-15

    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.

     
  • Keith Marshall
    Keith Marshall
    2011-08-15

    • status: open --> pending
     
  • Earnie Boyd
    Earnie Boyd
    2011-08-15

    • status: pending --> closed-works-for-me
     
  • Earnie Boyd
    Earnie Boyd
    2011-08-15

    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.

     
  • Orgad Shaneh
    Orgad Shaneh
    2011-08-16

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

     
  • Earnie Boyd
    Earnie Boyd
    2011-08-16

    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.

     
  • Orgad Shaneh
    Orgad Shaneh
    2011-08-16

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

     
  • Earnie Boyd
    Earnie Boyd
    2011-08-17

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

     
  • Orgad Shaneh
    Orgad Shaneh
    2011-08-17

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

     
  • Earnie Boyd
    Earnie Boyd
    2011-08-17

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

     
  • Orgad Shaneh
    Orgad Shaneh
    2011-08-17

    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.

     
  • Earnie Boyd
    Earnie Boyd
    2011-08-17

    Which perl.exe is being executed?

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

     
  • Orgad Shaneh
    Orgad Shaneh
    2011-08-17

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

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

     
  • Andrew
    Andrew
    2011-08-17

    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.

     
  • Orgad Shaneh
    Orgad Shaneh
    2011-08-17

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

     
  • Earnie Boyd
    Earnie Boyd
    2011-08-17

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

     
  • Orgad Shaneh
    Orgad Shaneh
    2011-08-17

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

     
  • Earnie Boyd
    Earnie Boyd
    2011-08-17

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

     
  • Orgad Shaneh
    Orgad Shaneh
    2011-08-17

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

     
  • Keith Marshall
    Keith Marshall
    2011-08-17

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

     
1 2 > >> (Page 1 of 2)