I've had the same problem for a couple of months (since 1.3.13 anyway); certain long command lines just fail to work for me. I've updated to the most recent (1.30.20-1 as of march 11) and I find the problem just got worse for me.
If I cd to a directory with many files, I issue "ls *" and the terminal ends up hanging, or "ls" returns with no output. I can issue "ls" without the star; that works just fine. I did an experiment back in november and found that command lines longer than 900 bytes or so would cause the command line to hang. My previous experiments are here: http://sources.redhat.com/ml/cygwin/2002-11/msg01133.html http://sources.redhat.com/ml/cygwin/2002-11/msg00316.html http://sources.redhat.com/ml/cygwin/2002-11/msg00372.html When I first installed g++-3.exe last year, it never worked for me. Its command lines (g++-3.exe --verbose) were longer than the magic number "900" or so bytes, and compilation would fail when cc1plus.exe was called. I could manually type a subportion of the cc1plus command; that would work. The g++-2.exe command worked most of the time, unless you had a makefile with many object files. (Theory: intermediary command lines were shorter with g++-2.exe?). I could work around the too-many-object-files issue in my makefile by using "ar rv" to create libs, one object file at a time. Since I updated to 1.3.20-1, I find the "magic" number of characters has dropped to 730. More importantly, g++-2 doesn't work any more. This seems to be similarly true for any external command with more than 730 characters. Contrast the following: $ echo ${PATH}${PATH} /cygdrive/c/texmf/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/texmf/miktex/ bin: /cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/FpAddin:/cygdrive/c /FpA ddinLon:/cygdrive/c/win32app/Sybase/DLL:/cygdrive/c/win32app/Sybase/BIN:/cyg driv e/c/FpAddin:/cygdrive/c/OptexNT/vendordll:/cygdrive/c/OptexNT/dll:/cygdrive/ c/Pr ogram Files/Microsoft Visual Studio/Common/Tools/WinNT:/cygdrive/c/Program Files /Microsoft Visual Studio/Common/MSDev98/Bin:/cygdrive/c/Program Files/Microsoft Visual Studio/Common/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio/VC9 8/bin:/usr/X11R6/bin/cygdrive/c/texmf/bin:/usr/local/bin:/usr/bin:/bin:/cygd rive /c/texmf/miktex/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c /FpA ddin:/cygdrive/c/FpAddinLon:/cygdrive/c/win32app/Sybase/DLL:/cygdrive/c/win3 2app /Sybase/BIN:/cygdrive/c/FpAddin:/cygdrive/c/OptexNT/vendordll:/cygdrive/c/Op texN T/dll:/cygdrive/c/Program Files/Microsoft Visual Studio/Common/Tools/WinNT:/cygd rive/c/Program Files/Microsoft Visual Studio/Common/MSDev98/Bin:/cygdrive/c/Prog ram Files/Microsoft Visual Studio/Common/Tools:/cygdrive/c/Program Files/Microso ft Visual Studio/VC98/bin:/usr/X11R6/bin $ /usr/bin/echo ${PATH}${PATH} <In the second case, nothing happens. In the past, I have also had to manually kill a process sucking back huge cycles.> It doesn't appear to make a difference whether I use "bash", "tcsh" or even "cmd" as my shell. I could probably work around this problem by manually invoking cc1plus.exe, but this is getting less and less convenient. I would appreciate any advice, before I wipe my installation and try installing an old version. Could this be a clash with some non-cygwin software, e.g. virus checkers? Has anyone else ever seen this behavior? Can a more experienced eye have a look at my cygcheck -s -v -r output for obvious errors? Thank you, - Matt Willis
cygcheck.out
Description: Binary data
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/