From: SF/projects/mingw n. l. <min...@li...> - 2012-06-07 22:09:23
|
Bugs item #3391275, was opened at 2011-08-13 22:20 Message generated for change (Comment added) made by cstrauss 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: Cesar Strauss (cstrauss) Date: 2012-06-07 15:09 Message: The test program I used was actually: #include <stdio.h> int main(int argc, char * argv[]) { int i; for (i=0; i<argc;i++) printf("argv[%d]=%s\n",i,argv[i]); return 0; } ---------------------------------------------------------------------- Comment By: Cesar Strauss (cstrauss) Date: 2012-06-07 15:08 Message: Your patch interferes with path translation of the command-line. Consider the following program, that prints its arguments: #include <stdio.h> int main(int argc, char * argv[]) { int i; for (i=1; i<argc;i++) printf("argv[%d]=%s\n",i,argv[i]); return 0; } Compile it with native (MinGW) gcc, and run on the bash shell: ./arg /tmp /c Expected result: argv[0]=c:\rascunho\msys\home\cstrauss\arg.exe argv[1]=C:/Users/cstrauss/AppData/Local/Temp argv[2]=/c After your patch: argv[0]=C:\rascunho\msys\home\cstrauss\arg.exe argv[1]=C:\Users\cstrauss\AppData\Local\Temp argv[2]=\c In particular, the //c -> \c conversion breaks usage of command-line switches, like "cmd //c echo /", which is unacceptable. The conversion to backslashes of file paths on the command line (argv[1] above) might be acceptable, however. What the others think? As I understand it, the issue on this ticket is due to a double path conversion (native->POSIX->native) losing information about the slashes. When entering MSYS, a few variables are converted to POSIX format, like TEMP and PATH. When invoking a native program, all environment variables are converted back to native format, including TEMP and PATH. However the conversion is always done with forward slashes (except path lists, where backslashes are used). A solution is to always convert to backslashes, but this would affect the command line as well, I think. Cesar ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-05-16 11:07 Message: I've just looked at the patch. It appears to be barking at the wrong tree. Have you built MSYS in debug mode? If so, strace should give you a value for 'returning: %s'. ---------------------------------------------------------------------- Comment By: Orgad Shaneh (orgads) Date: 2012-05-16 07:30 Message: Looks better now. Please review. ---------------------------------------------------------------------- Comment By: Orgad Shaneh (orgads) Date: 2012-05-16 07:08 Message: Ok, this patch is still bad. It fixes the TEMP issue, but introduces new problems. Now environment vars that were set during the session are getting a prefix of PWD. grrr... ---------------------------------------------------------------------- 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 |