Menu
▾
▴
[MinGW-notify] [ mingw-Support Requests-3524851 ] msys env.exe stops short with environment print
|
From: SF/projects/mingw n. l. <min...@li...> - 2012-05-09 19:20:46
|
Support Requests item #3524851, was opened at 2012-05-08 12:45 Message generated for change (Comment added) made by xmnboy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=202435&aid=3524851&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: None Status: Closed Priority: 4 Private: No Submitted By: Paul Fischer (xmnboy) Assigned to: Cesar Strauss (cstrauss) Summary: msys env.exe stops short with environment print Initial Comment: Note that I am using env.exe as my sample case for this issue. I'm seeing very bizzare behavior from many of the MSYS utilities. It feels like some libraries are either not right or are being usurped or ??? In any event, I'll use env.exe as the test case since my guess is if this problem can be resolved for env it will point to the resolution for other bad behaviors. I am using a Windows 7 64-bit machine. There are no spaces in the directories that contain the MinGW and MSYS files. The problem only happens when I run env.exe from the CMD.EXE prompt, not from the BASH prompt. Here's an example of what happens: C:\Users\xmnboy ( ) > >>C:\Users\xmnboy\tools\MinGW\msys\1.0\bin\env.EXE !C:=C:\Users\xmnboy !EXITCODE=00000000 ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\xmnboy\AppData\Roaming CLASSPATH=.;C:\Program Files (x86)\Java\jre6\lib\ext\QTJava.zip COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files COMMONPROGRAMFILES(X86)=C:\ C:\Users\xmnboy ( ) > >> And a truncation of the proper result when ENV.EXE is trun from within bash: C:\Users\xmnboy ( ) > >>bash bash-3.1$ env HOMEPATH=\ INTELLOGS=C:\Intel\Logs APPDATA=C:\Users\xmnboy\AppData\Roaming PROGRAMW6432=C:\Program Files PROCDIRLOG="C:\MININT\SMSOSD\OSDLOGS" TERM=cygwin PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel WINDIR=C:\Windows DIRCMD=/c/ogne COMMONPROGRAMW6432=C:\Program Files\Common Files PUBLIC=C:\Users\Public PROGRAMDATA=C:\ProgramData HTML5-LAB-VM-UB-1004-32=spdlvmx054.jf.intel.com USERDOMAIN=AMR COMMONPROGRAMFILES(X86)=C:\Program Files (x86)\Common Files UATDATA=C:\Windows\SysWOW64\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77 OS=Windows_NT ALLUSERSPROFILE=C:\ProgramData VBOX_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\ COPYCMD=/y TEMP=/tmp etc... Several other apps fail to run, but the failures are more difficult to describe. Some will only display a portion of their help message (they stop short) or just "don't work." Others appear to work fine. I might be albe to make at least a partial list of those that I believe are working and those that are not to see if there is some common thread (such as a common library file?). A few more that don't work: tar and tr Has anyone seen this before? Everything was working fine with an older version of MinGW and MSYS, I tried to reinstate that version but it made no difference. This has been compounded by trouble getting the mingw-get to work off sourceforge (see a previous bug report), so the process of installing other versions or trying to reinstall an existing version is extremely slow. ---------------------------------------------------------------------- Comment By: Paul Fischer (xmnboy) Date: 2012-05-09 12:20 Message: Thanks again. Further testing and it is working like it used to. Very grateful for your help in uncovering the culprit. As an aside, is it possible that this issue was also impacting the mingw-get failures I was having (separate bug posting -- ID: 3524614)? I just tried doing a mingw-get update followed by a mingw-get upgrade and it worked perfectly. Real test would be to use the GUI install like I was doing before. Seems odd that something like a CYGWIN=tty could cause this... ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-05-09 10:39 Message: [QUOTE]Should the MSYS utilities be paying attention to a CYGWIN env variable?[/QUOTE] Probably not, but ... When I forked Cygwin into MSYS I had tried to take each possibility and assign a suitable value that would just work based on my knowledge of how most people were using it. This problem has always existed and when encountered we have always given the same answer, remove the environment variable. ---------------------------------------------------------------------- Comment By: Paul Fischer (xmnboy) Date: 2012-05-09 10:02 Message: > So this isn't MSYS related but a user environment issue. Do you have a > CYGWIN enviroment variable created in Windows land? If so remove it to see > if it improves MSYS. There was a CYGWIN environment variable (CYGWIN=tty) hanging around and removing it seems to have fixed things! THANK YOU VERY MUCH!! Should the MSYS utilities be paying attention to a CYGWIN env variable? The variable, on its own, does nothing, an application (and its libraries) has to look for the variable and take actions based on what it finds. > It be interesting to see the rest of what was printed. It will be > interesting to see what the bash built-in command ``set'' outputs as well. When I compare the output of set inside the MSYS bash to that from the CMD prompt there are definite differences, but nothing that I would consider material. Mostly looks like the "standard stuff" one might expect to find in a typical Linux environment, plus all the stuff that was already defined in the Windows environment. > BTW, I just tested env myself on Windows XP 32bit. It is quite different > from ``set''. But should it be? From a CMD box the two (SET vs ENV) are similar, but not identical. Mostly in capitalization and a few additional variables that seem to get added by the MSYS apps, but I don't see anything in my comparisons that indicates a material difference. Thanks again for the suggestion regarding the CYGWIN variable, that appears to be the solution. I'll repost if there are, indeed further problems, but so far things look very good! ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-05-09 06:20 Message: [QUOTE]When it was working it was working on a 64-bit system.[/QUOTE] [QUOTE]This all started when I tried working with an older Cygwin based SSH (I was testing some things that needed an alternate SSH) -- but I can't find anything like a system DLL that might have been replaced by that install, so it doesn't make sense.[/QUOTE] So this isn't MSYS related but a user environment issue. Do you have a CYGWIN enviroment variable created in Windows land? If so remove it to see if it improves MSYS. [QUOTE]etc...[/QUOTE] It be interesting to see the rest of what was printed. It will be interesting to see what the bash built-in command ``set'' outputs as well. BTW, I just tested env myself on Windows XP 32bit. It is quite different from ``set''. But should it be? ---------------------------------------------------------------------- Comment By: Paul Fischer (xmnboy) Date: 2012-05-08 14:09 Message: I don't think this is a 64-bit vs. 32-bit Windows issue. When it was working it was working on a 64-bit system. If I open a 32-bit CMD.EXE window I get the same results -- I've got some 32-bit Windows VMs I will try out as well, to see if I get the same results there. This all started when I tried working with an older Cygwin based SSH (I was testing some things that needed an alternate SSH) -- but I can't find anything like a system DLL that might have been replaced by that install, so it doesn't make sense. The key bits I need are working good enough, so this is not urgent, but as I have more time to provide additional data points I'll add them to this issue. It's frustrating because MSYS is so useful... p.s. grep appears to also be affected, here's an example of a failure: C:\Users\xmnboy ( ) > >>set | grep -i programfile CommonProgramFiles=C:\Progra C:\Users\xmnboy ( ) > which should have produced this: C:\Users\xmnboy ( ) > >>set | C:\Users\xmnboy\tools\GnuWin32\bin\grep.EXE -i programfile CommonProgramFiles=C:\Program Files (x86)\Common Files CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files ProgramFiles=C:\Program Files (x86) ProgramFiles(x86)=C:\Program Files (x86) C:\Users\xmnboy ( ) > (The above was taken from a 32-bit CMD on a 64-bit Windows machine, they play games with the ProgramFiles env variables, that's why it looks wrong.) ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-05-08 13:08 Message: I doubt that this will be resolved until we are able to provide a 64 bit version of MSYS. I gather that some of the environment space is in 64 bit address space while some are in 32 bit address space. I have seen similar issues with current versions of Cygwin as related via the cygwin mail list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=202435&aid=3524851&group_id=2435 |