Cygwin DLL 1.7.16/17 appears to break SIGWINCH/KEY_RESIZE behaviour
I have observed an issue in vim and mutt as of August 2012, which has persisted to now. From conversations with some other cygwin users, the issue may not be strictly related to ncurses based applications (mined apparently suffers similarly), but my experience is limited to those. In mutt, the (.muttrc) timeout parameter defines how long mutt waits for a keystroke before timing out (at which point it does housekeeping that includes IMAP polling and window redraw (due to the SIGNWINCH). I have not investigated the vim code, but the observed behaviour is that it blocks with the window not redrawn until a new keystroke is detected. When resizing a mintty (apparently also xterm) window, an ncurses application immediately received a SIGWINCH interrupt. This typically occurs while the interactive thread is blocked in a timeout-limited call to getch(). What appears to be happening is that the KEY_RESIZE character that is inserted into the input queue does not immediately cause the getch() call to return. Instead, the timeout expires and then either a) KEY_RESIZE gets returned on the call that timed out b) ERR is returned and a subsequent call immediately returns KEY_RESIZE I'm guessing that with cygwin1.dll 1.7.15, something was causing the blocked getch() to return immediately. Whether it was another signal, some dummy insertion into the input queue, or something else, I don't know. It seems to me that this be considered an ncurses issue, but the problem goes away by downgrading just cygwin1.dll. From a superficial review of the ncurses source, it would seem that getch() is blocked in select(). This suggests that cygwin 1.7.15 was pushing some character into the input file descriptor that cygwin 1.7.16 onward are not doing. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [1.7] bug in chdir
Could it be that a mount point called /home, or //home (if possible), makes a
difference?
- Original Message -
From: cygwin-ow...@cygwin.com cygwin-ow...@cygwin.com
To: cygwin@cygwin.com cygwin@cygwin.com
Sent: Wed Jul 15 04:46:35 2009
Subject: Re: [1.7] bug in chdir
On Jul 14 21:47, Eric Blake wrote:
$ ls //home
ls: reading directory //home: No such file or directory
$ # makes sense; I don't have a remote machine named home
$ cd //home
$ # huh? no error reported?
$ /bin/pwd # avoid shortcuts in bash builtin; /bin/pwd uses getcwd
//home
Sorry Eric, but I can't reproduce this. I tried it on XP and 2K8R2
with identical result.
That's what I get in bash:
cori...@cathi ~
$ ls //home
ls: cannot access //home: No such file or directory
cori...@cathi ~
$ cd //home
bash: cd: //home: No such file or directory
cori...@cathi ~
$
And that's what I get in dash:
$ ls //home
ls: cannot access //home: No such file or directory
$ cd //home
cd: 2: can't cd to //home
$
$ dash -c 'CDPATH=/; cd home'
//home
On my systems this result in:
$ dash -c 'CDPATH=/; cd home'
cd: 1: can't cd to home
I also tried a simple test application which removes the shell
magic from the picture:
#include stdio.h
int
main (int argc, char **argv)
{
int ret = 0;
if (argc 1)
ret = chdir (argv[1]);
if (ret)
perror (chdir);
return 0;
}
$ gcc -g -o chdir chdir.c
$ ./chdir //home
chdir: No such file or directory
$
If you're able to cd to //home, then there must be some crucial
difference in your environment. You should debug this, at least with
strace, so we can find out under what circumstances this occurs.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MinTTY 0.4-alpha1
--confirm-exit-error ? - Original Message - From: cygwin-ow...@cygwin.com cygwin-ow...@cygwin.com To: cygwin@cygwin.com cygwin@cygwin.com Sent: Wed Mar 25 20:50:45 2009 Subject: Re: MinTTY 0.4-alpha1 Frank Fesevur: An minor option I would like is to always close MinTTY, even when bash exits with status code. Now I need to press for instance the enter key to close MinTTY after I pressed Ctrl+D and I have pressed Ctrl+C at least once. Any successfully executed command will clear the exit status, but yep, I see what you mean. This feature was intended for invoking programs such as ssh or telnet, or perhaps a script, where you'd want to see the output if there's an error. Admittedly though, it's little use with the standard case of a shell session. So how about disabling this by default, and having a command line option for activating it might be necessary? Suggestions for the name of such an option welcome. (--keep-open-on-error is the best I could come up with so far, but that's a bit on the unsnappy side.) Andy -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: First Pass at mintty documentation; etc.
Apologies for violating sane quoting convention, but I'm working off a crapberry. Wrt to window titles: change your PS1 prompt to no longer reassign the title with the pwd (assuming you still have the default definition from /etc/profile (or similar)) and use the same escape sequience it uses (a standard vt100 documented one) to explicity assign your own title. The same can be done within a native dos box, but the explicit assignment has to be through a binary that calls SetConsoleTitle() because the native terminal does not support the escape code (as I recall). - Original Message - From: cygwin-ow...@cygwin.com cygwin-ow...@cygwin.com To: cygwin@cygwin.com cygwin@cygwin.com Sent: Thu Jan 15 23:21:31 2009 Subject: Re: First Pass at mintty documentation; etc. Andy Koppe wrote: Lee D. Rothstein wrote: \e[1;5A: history-search-backward \e[1;5B: history-search-forward Perhaps I don't understand this 'bash' feature, but it doesn't seem to work for me. Start typing a command, press Ctrl-Up, and it finds the previous line in the history that started like that. I'll work on that habit. Thanks. I do lots of bash scripting including Windows/DOS commands, and I can think of only one character cell app that ever gave me any trouble from rxvt or xterm (whatever that app is -- I think a Resource Kit app), I found a work-around and never needed it again. 'net' is a troublesome command that's been mentioned, although it seems to be ok for basic stuff. But I guess there might be still be a few DOS fullscreen apps around. Turbo Pascal perhaps? But yeah, I'd sooner implement tabs than worry about DOS apps. ;) rudimentary 'net' works. I didn't know xterm actually had a UI for this. Do people find this useful? I've used it on occasion when I needed to scroll back through two debugging runs of a text-mode (character cell) app (or debugging statements). So your debug print macro or whatever would be switching screens? No. Me at the terminal switches screens, using the options menu, before the second run. What would be better for this and other problems, however, is a feature that I would love: The ability to interactively, on the fly change, the Title Bar/Task Bar Title to be clear on what each Window is doing. Can you explain the interactive bit a bit more. Do you mean clicking on the window title and start typing away at it? Exactly what I had in mine. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Did man break recently?
After a recent upgrade of what appears to be tetex and x11 stuff, I see the following generated on stderr prior to any normal response from a man query: Unrecognized line in config file (ignored) JNROFF LANG=ja_JP.UTF-8 /usr/bin/groff -Tnippon -mandocj Unrecognized line in config file (ignored) KNROFF /usr/bin/groff -Tkorean -mandoc Unrecognized line in config file (ignored) JNEQN /usr/bin/eqn -Tnippon Unrecognized line in config file (ignored) KNEQN /usr/bin/eqn -Tkorean Is there a setup dependancy issue perhaps? I know it is not an issue with the mks toolkit stuff also instaled (as seen below) because I renamed the directory to get it out of the path and there was no change in behaviour. Cygcheck -s reports: Cygwin Configuration Diagnostics Current System Time: Wed Oct 06 08:24:12 2004 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: D:\cygwin\usr\local\bin D:\cygwin\bin D:\cygwin\bin D:\cygwin\usr\X11R6\bin .\ D:\cygwin\bin D:\mks\mksnt D:\mks\mkssi C:\PROGRAM FILES\THINKPAD\UTILITIES C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\ATI Technologies\ATI Control Panel C:\Program Files\PC-Doctor for Windows\services Output from D:\cygwin\bin\id.exe (nontsec) UID: 1004(avadekar) GID: 513(None) 513(None) Output from D:\cygwin\bin\id.exe (ntsec) UID: 1004(avadekar) GID: 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS HOME = `E:\' MAKE_MODE = `UNIX' PWD = `/home/avadekar' USER = `avadekar' Use `-r' to scan registry c: hd NTFS 2Mb 34% CP CS UN PA FC IBM_PRELOAD d: hd NTFS 10003Mb 89% CP CS UN PA FC DEVELOPMENT e: hd NTFS8002Mb 51% CP CS UN PA FC WORK f: cd N/AN/A p: hd NTFS 12004Mb 46% CP CS UN PA FC PACKAGES t: hd NTFS3861Mb 28% CP CS UN PA FC Temp D:\cygwin / system binmode C: /csystem binmode D: /dsystem binmode E: /esystem binmode F: /fsystem binmode G: /gsystem binmode d:\sdks\eracom\fm-sdk /gcc system textmode P: /packages system binmode T: /tsystem binmode D:\cygwin/bin /usr/bin system binmode D:\cygwin/lib /usr/lib system binmode D:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode V: /vsystem binmode . /cygdrive system binmode,cygdrive Found: D:\mks\mksnt\awk.exe Found: D:\cygwin\bin\bash.exe Found: D:\cygwin\bin\cat.exe Found: D:\mks\mksnt\cat.exe Found: D:\cygwin\bin\cp.exe Found: D:\mks\mksnt\cp.exe Found: D:\cygwin\bin\cpp.exe Found: D:\cygwin\bin\find.exe Found: D:\mks\mksnt\find.exe Found: D:\cygwin\bin\gcc.exe Found: D:\cygwin\bin\gdb.exe Found: D:\cygwin\bin\grep.exe Found: D:\mks\mksnt\grep.exe Found: D:\cygwin\bin\ld.exe Found: D:\cygwin\bin\ls.exe Found: D:\mks\mksnt\ls.exe Found: D:\cygwin\bin\make.exe Found: D:\mks\mksnt\make.exe Found: D:\cygwin\bin\mv.exe Found: D:\mks\mksnt\mv.exe Found: D:\cygwin\bin\rm.exe Found: D:\mks\mksnt\rm.exe Found: D:\cygwin\bin\sed.exe Found: D:\mks\mksnt\sed.exe Found: D:\cygwin\bin\sh.exe Found: D:\mks\mksnt\sh.exe Found: D:\cygwin\bin\tar.exe Found: D:\mks\mksnt\tar.exe 55k 2004/09/14 D:\cygwin\bin\cygbz2-1.dll 18k 2004/07/06 D:\cygwin\bin\cygcharset-1.dll 7k 2003/10/19 D:\cygwin\bin\cygcrypt-0.dll 839k 2004/09/27 D:\cygwin\bin\cygcrypto-0.9.7.dll 22k 2004/02/10 D:\cygwin\bin\cygcygipc-2.dll 831k 2003/09/20 D:\cygwin\bin\cygdb-4.1.dll 895k 2004/04/28 D:\cygwin\bin\cygdb-4.2.dll 1080k 2003/09/20 D:\cygwin\bin\cygdb_cxx-4.1.dll 1156k 2004/04/28 D:\cygwin\bin\cygdb_cxx-4.2.dll 155k 2004/01/07 D:\cygwin\bin\cygexpat-0.dll 129k 2004/03/11 D:\cygwin\bin\cygfontconfig-1.dll 45k 2001/04/25 D:\cygwin\bin\cygform5.dll 35k 2002/01/09 D:\cygwin\bin\cygform6.dll 48k 2003/08/09 D:\cygwin\bin\cygform7.dll 361k 2003/10/25 D:\cygwin\bin\cygfreetype-6.dll 28k 2003/07/20 D:\cygwin\bin\cyggdbm-3.dll 30k 2003/08/11 D:\cygwin\bin\cyggdbm-4.dll 19k 2003/03/22 D:\cygwin\bin\cyggdbm.dll 15k 2003/07/20 D:\cygwin\bin\cyggdbm_compat-3.dll 15k 2003/08/11 D:\cygwin\bin\cyggdbm_compat-4.dll 107k 2004/07/06 D:\cygwin\bin\cyggettextlib-0-14-1.dll 17k 2004/07/06
Recent change in redirection handling?
I have a bash script that ran cleanly under 1.5.9x, that now exhibits some disturbing behaviour under a recent upgrade. The gist of the problem is that the execution of compact /c file.exe NUL which used to run and produce no output (due to the redirect) now actually puts the output into a file called NUL So, I can deal with the fact that the script needs to either use NUL: (which I did not test) or maybe more appropriately /dev/null (which works), but I now have the NUL files polluting my disk that cannot be removed! Under a real unix shell, I've had occasion to drop down to a bourne shell to delete filenames with wilrdcard characters that a (t)csh would have trouble with, but I have not found a similar was to deal with this. Using rm NUL in bash does not work; rem NUL in a dos box doesn't work, and the windows explorer doesn't either. Any suggestions? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Recent change in redirection handling?
On Fri, Jun 04, 2004 at 12:32:46PM -0400, Igor Pechtchanski wrote: On Fri, 4 Jun 2004, Ashok Vadekar wrote: I have a bash script that ran cleanly under 1.5.9x, that now exhibits some disturbing behaviour under a recent upgrade. The gist of the problem is that the execution of compact /c file.exe NUL which used to run and produce no output (due to the redirect) now actually puts the output into a file called NUL So, I can deal with the fact that the script needs to either use NUL: (which I did not test) or maybe more appropriately /dev/null (which works), but I now have the NUL files polluting my disk that cannot be removed! Under a real unix shell, I've had occasion to drop down to a bourne shell to delete filenames with wilrdcard characters that a (t)csh would have trouble with, but I have not found a similar was to deal with this. Using rm NUL in bash does not work; rem NUL in a dos box doesn't work, and the windows explorer doesn't either. Any suggestions? Known problem. See http://cygwin.com/ml/cygwin/2004-05/msg00905.html and http://cygwin.com/ml/cygwin/2004-06/msg00144.html. In particular, the thread referenced in the first message should tell you how to remove the file. Thanks for the pointer. Incidentally, why do you redirect to NUL rather than to /dev/null? I usually end up having trouble when I try to use native windows excutables in bash scripts. Redmond and I don't seem to see eye-to-eye on parameter passing etal. So I end up testing the use of the executables in a DOS box first. As a result, I used NUL. When I put the functionality into the bash script, I just neglected to use the (unix) cannonical method. In this particular case, in addition to the compact call, I was trying to set up environment variables through the use of REG, and was having trouble with the quotes and slashes getting handled differently by bash and CMD. Worse yet, the registry manipulation was going into a sprintf/system() call so that a binary was calling REG, so it was somewhat obscured. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Line breaks in bash
I get the behaviour even if I comment out all the complex PS1 definitions in /etc/profile. To see it, open a bash (windows console, I don't know about rxvt) and resize it to be larger than the 80x25 (mode.com con lines=50 cols=120). Then type away (at a prompt) and see that the text will wrap at ~80 characters. Now, export COLUMNS=120. Same problem. Now, launch another bash from this console, and resize it to 120 wide. Finally, it does the right thing. So, it seems that COLUMNS needs to match the width of the screen, AND something else that only happens (by default anyways) when a new bash is started. Maybe someone else knows what that might be? On Thu, Apr 22, 2004 at 05:37:18PM -0700, AJ Reins wrote: --- Andrew DeFaria wrote: When I type a long line in the bash shell it seems to get confused when it passes the first 80 character barrier and does a newline. Below is an example. C09-272-A:# why is it in bash that when I get close to typing 80 characters bash does som ething like this? Now set my prompt to the hostname as \[\e]0;\w\a\e[01;33mC09-272-A:\e[0m. Could this be causing the problem? Yes. You have a \[ to indicate non-printing characters without the closing \]. -- I don't suffer from insanity. I enjoy every minute of it. Me too! (sorry about that! (acutally I'm not, but lets not quibble over tribbles!)) __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25ยข http://photos.yahoo.com/ph/print_splash -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Line breaks in bash
It was XP in my case. The stty -a followed by a kill -WINCH my-bash-pid works (even with a mode.com based resize). Thanks for the insight. I hope the original poster gets something out of this too. On Fri, Apr 23, 2004 at 11:13:05AM -0400, Igor Pechtchanski wrote: Which OS? Win9x console is pretty much braindead. Cygwin's programs (notably bash) have code for processing a SIGWINCH, which they should receive whenever a window (console or otherwise) that they're running in gets resized. However, the code for sending this signal will only detect a *window* resize -- I don't know whether the one via mode.com will also be detected[*]. Try killing bash with SIGWINCH. Also, bash doesn't use the COLUMNS/ROWS variables, it looks at the same info that stty gets -- run stty -a and see if it picks up the window size. Igor [*] It is on Win2k, FWIW. On Fri, 23 Apr 2004, Ashok Vadekar wrote: I get the behaviour even if I comment out all the complex PS1 definitions in /etc/profile. To see it, open a bash (windows console, I don't know about rxvt) and resize it to be larger than the 80x25 (mode.com con lines=50 cols=120). Then type away (at a prompt) and see that the text will wrap at ~80 characters. Now, export COLUMNS=120. Same problem. Now, launch another bash from this console, and resize it to 120 wide. Finally, it does the right thing. So, it seems that COLUMNS needs to match the width of the screen, AND something else that only happens (by default anyways) when a new bash is started. Maybe someone else knows what that might be? On Thu, Apr 22, 2004 at 05:37:18PM -0700, AJ Reins wrote: --- Andrew DeFaria wrote: When I type a long line in the bash shell it seems to get confused when it passes the first 80 character barrier and does a newline. Below is an example. C09-272-A:# why is it in bash that when I get close to typing 80 characters bash does som ething like this? Now set my prompt to the hostname as \[\e]0;\w\a\e[01;33mC09-272-A:\e[0m. Could this be causing the problem? Yes. You have a \[ to indicate non-printing characters without the closing \]. -- I don't suffer from insanity. I enjoy every minute of it. Me too! (sorry about that! (acutally I'm not, but lets not quibble over tribbles!)) -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Should setup work when /tmp is a mount?
With a recent new system, I found that setup was aborting, generating neither error message nor /var/log/setup.log* output. After a little messing around, I found that my mount point for /tmp was cuasing the problem. After umount(ing) /tmp, setup worked again. Should this (/tmp being a mounted directory causing problems) be expected behaviour? If so is it reasonable that the log was not generated? cygcheck attached. Cygwin Package Information Last downloaded files to: D:\Cygwin\install Last downloaded files from: http://mirrors.rcn.net/pub/sourceware/cygwin Package VersionStatus _update-info-dir 00225-1OK a2ps 4.13-1 OK antiword 0.34-2 OK ash 20031007-1 OK base-files 2.6-1 OK base-passwd 1.1-1 OK bash 2.05b-16 OK bc 1.06-1 OK binutils 20030901-1 OK bzip21.0.2-5OK clear1.0-1 OK crypt1.1-1 OK cvs 1.11.6-3 OK cygutils 1.2.2-1OK cygwin 1.5.5-1OK cygwin-doc 1.3-6 OK diffutils2.8.4-1OK ed 0.2-1 OK editrights 1.01-1 OK fileutils4.1-2 OK findutils4.1.7-4OK gawk 3.1.3-4OK gcc 3.3.1-3OK gcc-g++ 3.3.1-3OK Empty package gcc-mingw gcc-mingw20030911-4 OK gcc-mingw-core 20031020-1 OK gcc-mingw-g++20031020-1 OK gdb 20030919-1 OK gdbm 1.8.3-7OK grep 2.5-1 OK groff1.18.1-2 OK gzip 1.3.5-1OK indent 2.2.8-1OK inetutils1.3.2-25 OK less 381-1 OK libbz2_1 1.0.2-5OK libdb4.1 4.1.25-1 OK libgdbm 1.8.0-5OK libgdbm-devel1.8.3-7OK libgdbm3 1.8.3-3OK libgdbm4 1.8.3-7OK libgettextpo00.12.1-3 OK libiconv21.9.1-3OK libintl1 0.10.40-1 OK libintl2 0.12.1-3 OK libjpeg626b-11 OK libjpeg6b6b-8 OK libkpathsea3 2.0.2-13 OK libkpathsea3abi132.0.2-2OK libncurses5 5.2-1 OK libncurses6 5.2-8 OK libncurses7 5.3-4 OK libpcre 4.1-1 OK libpcre0 4.5-1 OK libpng12 1.2.5-4OK libpopt0 1.6.4-4OK libreadline4 4.1-2 OK libreadline5 4.3-5 OK libtiff3 3.6.0-2OK libtiff4 3.6.0-5OK login1.9-7 OK make 3.80-1 OK man 1.5k-1 OK mingw-runtime3.2-1 OK mktemp 1.5-3 OK more 2.11o-1OK ncftp3.1.4-1OK ncurses 5.3-4 OK openssh 3.7.1p2-2 OK openssl 0.9.7c-1 OK perl 5.8.2-1OK psutils 1.17-1 OK rcs 5.7-3 OK readline 4.3-5 OK sed 4.0.8-1OK sh-utils 2.0.15-4 OK shutdown 1.4-1 OK splint 3.1.1-1OK tar 1.13.25-5 OK tcltk20030901-1 OK termcap 20021106-2 OK terminfo 5.3_20030726-1 OK Empty package tetex tetex2.0.2-13 OK tetex-bin2.0.2-13 OK tetex-tiny 2.0.2-13 OK texinfo 4.2-4 OK textutils2.0.21-1 OK unzip5.50-5 OK vim 6.2.098-1 OK w32api 2.4-1 OK which1.5-2 OK zip 2.3-5 OK zlib 1.1.4-4OK Cygwin Win95/NT Configuration Diagnostics Current System Time: Tue Dec 16 04:29:31 2003 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: D:\cygwin\usr\local\bin D:\cygwin\bin D:\cygwin\bin D:\cygwin\usr\X11R6\bin C:\PROGRAM FILES\THINKPAD\UTILITIES C:\WINDOWS\system32
Weird top bug?
I've stumbled across some peculiar behaviour for top. I've got the following script (vping) that I use to keep a VPN connection alive: #!/bin/sh while true; do ping -n 1 remoteMachine /dev/null sleep 60 done I typically run this as a background task (vping ), then telnet to remoteMachine. Now when I quit telnet, then exit the shell (vping was run from), the shell stays around. My script has a stdout handle, I suppose. That's OK, I can close the window with the mouse, and then vping dies. Seems normal. But if I leave the shell open after typing exit, then run top in another shell, it clears the screen, shows exactly one line of output (in this specific case): 15:23:03 up 8:00, 2 users, load average: 0.00, 0.00, 0.00 and locks up. Control C does not regain shell control. If I open another shell and use ps to find the process number for top, I can kill it (kill pid, no explicit signal type). It doesn't seem to me that my specific script should have anything to do with how top is behaving, but I supose it is possible. Seems more like top is having trouble because the parent process of my script is no longer valid. Maybe the parent process is gone, but top uses a windows thing to enumerate processes, and the open shell still has an entry in that list? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Weird top bug?
cygcheck output attached, two ways. I noticed that one tool I recently installed has some cygwin-ish-ness to it that I had not expected. It's shown in the output, but I thought I'd highlight it. Flexgdb has some dlls that cygcheck found. I renamed the directory to hide it from PATH, rebooted, and tried again. Same thing happens; cygcheck.out.2 shows the slightly different setup. However, I just saw something else this time. When top is sitting there stuck, and you kill the window that vping still has the console locked, THEN top sits for a few more seconds, then comes up as one would expect. Seems like top is actually blocked trying to get at some windows resource that the closing shell has locked. On Fri, Jun 06, 2003 at 03:40:24PM -0400, Ashok Vadekar wrote: I've stumbled across some peculiar behaviour for top. I've got the following script (vping) that I use to keep a VPN connection alive: #!/bin/sh while true; do ping -n 1 remoteMachine /dev/null sleep 60 done I typically run this as a background task (vping ), then telnet to remoteMachine. Now when I quit telnet, then exit the shell (vping was run from), the shell stays around. My script has a stdout handle, I suppose. That's OK, I can close the window with the mouse, and then vping dies. Seems normal. But if I leave the shell open after typing exit, then run top in another shell, it clears the screen, shows exactly one line of output (in this specific case): 15:23:03 up 8:00, 2 users, load average: 0.00, 0.00, 0.00 and locks up. Control C does not regain shell control. If I open another shell and use ps to find the process number for top, I can kill it (kill pid, no explicit signal type). It doesn't seem to me that my specific script should have anything to do with how top is behaving, but I supose it is possible. Seems more like top is having trouble because the parent process of my script is no longer valid. Maybe the parent process is gone, but top uses a windows thing to enumerate processes, and the open shell still has an entry in that list? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ Cygwin Win95/NT Configuration Diagnostics Current System Time: Fri Jun 06 19:09:24 2003 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: . D:\Cygwin\usr\local\bin D:\Cygwin\bin D:\Cygwin\bin D:\Cygwin\usr\X11R6\bin d:\mks\mkssi d:\mks\mkssam c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\system32\WBEM d:\SDKs\mmdsptools\FlexGDB\bin D:\Cygwin\bin\id.exe output (nontsec) UID: 1000(avadekar) GID: 513(None) 513(None) D:\Cygwin\bin\id.exe output (ntsec) UID: 1000(avadekar) GID: 513(None) 513(None) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS CYGWIN = `binmode tty ntea nontsec notitle' HOME = `e:\' MAKE_MODE = `UNIX' PWD = `/e' USER = `avadekar' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\avadekar\Application Data' CALCPATH = `.:/usr/share/calc' CLASSPATH = `.;D:\Cygwin\usr\share\java;D:\Cygwin\usr\share\java\kjc.jar' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `CE001855' COMSPEC = `C:\WINDOWS\system32\cmd.exe' D = `d' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\avadekar' LOGONSERVER = `\\CE001855' MANPATH = `:/usr/ssl/man' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/e' OS = `Windows_NT' PAGER = `less -X -F -is' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0806' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' PS1 = `\[\033[32m\]\h:\[\033[33m\w\033[0m\] $ ' ROOTDIR = `d:/mks' ROOTPROJECT = `sandbox.pj' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `D:\Cygwin\tmp' TERM = `cygwin' TEXINPUTS = `.:/usr/share/texmf.local:' TK_NTSECURITYINFO_OFF = `' USERDOMAIN = `CE001855' USERNAME = `avadekar' USERPROFILE = `C:\Documents and Settings\avadekar' VSCOMNTOOLS = `D:\SDKs\Vc7\Common7\Tools\' WINDIR = `C:\WINDOWS' _ = `/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/' cygdrive flags = 0x002a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `D:\Cygwin' flags = 0x000a
Re: Case insensitivity
It would seem to me that this should be easily accomplished by wrapping open()/fopen() with code that does some sort of glyph recoding for uppercase characters. Getting the library code to access your wrapper would be a minor macro issue. While this may not be the answer you were originally looking for, it should allow you to leave the original code alone, allowing easier rebuilds from source changes on the original build platforms. On Thu, Apr 25, 2002 at 10:27:39AM -0400, Larry Hall (RFK Partners, Inc) wrote: At 09:25 PM 4/24/2002, B. Joshua Rosen wrote: I'm in the process of porting my CAE tool (hdlmaker) to Cygwin and I've run into a problem with case sensitivity, or to be precise the lack of case sensitivity in the file system. I have a number of files that are paired as upper and lower case versions, i.e. FD.v and fd.v. In the Unix world this is no problem but in the Cygwin environment the files conflict. I noticed the problem when doing a CVS checkout. I'm aware that NTFS is not case sensitive, does Cygwin provide a layer that provides case sensitivity or do I have to go through the huge effort of converting my library to make it case independent. While I agree with both Chris's and Rob's response to this thread, in the interest of keeping misinformation out of the email archive, I'll make the following statements: 1. NTFS *is* case-sensitive. Windows forces case-insensitivity on it. 2. It is possible to create files with the same name differing only by case under Windows using it's API. There was a patch floating around for Cygwin years ago that did this. However, it was never incorporated because native Windows tools couldn't deal with the resulting files and the concept couldn't be extended to incorporate directories (as I recall - of course I'll defer to the email list archives if it states otherwise! ;-) ) I think you're really pretty much stuck converting your library. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- 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/ -- 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/
Re: reboot problem
I noticed recently that shutdown from a bash causes a End program now dialogue to pop up (for the bash console which is still running shutdow). Perhaps some other application is not closing and you can't see it (if it's a remote connection). On Tue, Mar 12, 2002 at 10:38:50AM +0100, Corinna Vinschen wrote: On Tue, Mar 12, 2002 at 01:44:16PM +0800, iman lee wrote: (sorry for my poor english level) and also sorry if this question is too simple. I use reboot -r now command to reboot my win2k machine, it's ok. but this is when I login through console. when I use ssh to logon and no console user, the same command give a reboot warning but do nothing. That's weird. I know it doesn't help you that much but I'm using this on a W2K machine multiple times per day due to hardware tests and it works fine. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- 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/ -- 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/
