Re: Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt
--- On Tue, 7/13/10, Jon TURNEY wrote: From: Jon TURNEY Subject: Re: Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt To: cygwin-xfree@cygwin.com Date: Tuesday, July 13, 2010, 3:21 PM On 09/07/2010 07:58, Marco Atzeri wrote: Snipped on my Win-XP SP2 under cygwin/X MC with F10 exits in the current directory Peter, as mc is an alias alias mc='. /usr/share/mc/bin/mc-wrapper.sh' I guess that under X this wrapper is working differently than under console Perhaps more likely, the alias isn't setup by the shell init scripts under xterm because of the way the xterm was started (which the OP hasn't said) (but is being setup for cmd.exe or rxvt) Note that it's impossible for mc to change the current directory of the parent shell without this alias. For the record, the xterm I used for this test was the one started from the cygwin-X start menu item. I still have not found the round tuits to compile a debugging version of MC to check this out in more detail, but I hope to do so sometime in the next 30 days (lots of RL intruding). I will reply again when I have more information. Thank you all for your advice and help. Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt
--- On Fri, 7/9/10, Marco Atzeri marco_atz...@yahoo.it wrote: From: Marco Atzeri marco_atz...@yahoo.it Subject: Re: Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt Snipped on my Win-XP SP2 under cygwin/X MC with F10 exits in the current directory Peter, as mc is an alias alias mc='. /usr/share/mc/bin/mc-wrapper.sh' I guess that under X this wrapper is working differently than under console Marco, Thanks, but in my xterm which mc returns /usr/bin/mc, which is an exe and not an alias to the wrapper shell script. Executing /usr/bin/mc from an xterm prompt produces the same result, it exits to the MC invocation directory instead of the current one. Thanks for pointing out that wrapper script though. Most interesting. Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt
--- On Thu, 7/8/10, Larry Hall (Cygwin X) reply-to-list-only-l...@cygwin.com wrote: From: Larry Hall (Cygwin X) reply-to-list-only-l...@cygwin.com Subject: Re: Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt Snipped Sorry, I don't know anything about MC really but isn't there some doc on it that describes what F10 is supposed to do? Yes, there is, from the info mc pages: Quit (F10, Shift-F10) Terminate the Midnight Commander. Shift-F10 is used when you want to quit and you are using the shell wrapper. Shift-F10 will not take you to the last directory you visited with the Midnight Commander, instead it will stay at the directory where you started the Midnight Commander. I am not using the wrapper shell script, as far as I can tell (but I'm still looking hard to see if I am wrong about that). Simple F10 in an xterm though *always* exits to the original directory. Shift-F10 has no effect at all inside of MC from an xterm in the testing I have done (nor do Ctrl-F10 or Alt-F10). I guess it's *possible* that there is a bug that makes MC *think* it sees shift-F10 when only simple F10 was pressed, but that remains to be proven. I will have to run a debugging version of MC with gdb to see the difference between xterm and non-xterm behavior. I will report back when I have done that experiment. It might be a while, but I will report back. Thanks for your help and advice. Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt
I don't know if this is the right place to ask this question, but if it is not please advise me where to send it. Midnight Commander exits with F10, and in a native bash window or rxvt F10 exits to the last directory viewed. In an xterm though, it exits to the original directory from which MC was started. Do you think this a bug in MC or is it WAD? If you think it's a bug in MC I will gladly debug it myself, I just want to know if it's WAD for xterm's first. I am using a fresh cygwin + cygwin/X install on WinXP SP3, and I will supply the usual problem report documentation if needed to answer my question. Regards, Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Background processes with Cygwin
--- On Sat, 4/4/09, Matt Wozniski wrote: From: Matt Wozniski Subject: Re: Background processes with Cygwin To: cygwin-xfree@cygwin.com Date: Saturday, April 4, 2009, 11:02 PM http://www.cygwin.com/acronyms/#PCYMTNQREAIYR On Sat, Apr 4, 2009 at 9:50 PM, Peter Farley wrote: --- On Fri, 4/3/09, Jeff Irwin wrote: Don't quote headers like this. It's not useful to anyone, and it feeds the spammers. From: Jeff Irwin Subject: Background processes with Cygwin To: Date: Friday, April 3, 2009, 2:48 PM Snipped http://www.cygwin.com/acronyms/#PCYMTWLL - Reformatted PMFJI here, but if you log out of Cygwin, then the Cygwin process terminates. Why would you think that a process started under Cygwin could survive the termination of Cygwin? That just doesn't make sense, even to this raw newbie. You're missing something big. Cygwin isn't a process. It's a DLL that provides a UNIX-like environment. You don't terminate cygwin, you terminate a shell that's using the Unix emulation provided by cygwin1.dll. Among other things, the whole *ix environment that Cygwin provides would be gone, so how could your process possibly continue? This isn't real *ix, it's *ix facilities provided under the control of another quite different (and generally more hostile) OS environment. The *ix facilities are provided by a DLL, not by a process, and the applications can continue running after the shell exits, just like in any other *ix - the DLL didn't go away, after all. Maybe I'm missing something crucial in my understanding of how Cygwin and Windows operate. If so, I'd appreciate a cure for my ignorance. Hopefully this clears things up. Unfortunately, I'm not sure why things aren't working for the OP. In any event, switching to the main cygwin list instead of the cygwin-xfree list (which is only for X11 related issues) would probably help get him the help he needs. Apologies for both of those trespasses. I didn't look at what yahoo mail was generating. Serves me right for not looking. Mea maxima culpa, and I will check first and fix it in the future. Unfortunately yahoo's web email isn't very bright. And thank you for those explanations. They do help cure my ignorance. Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Background processes with Cygwin
--- On Fri, 4/3/09, Jeff Irwin jeffrosq...@hotmail.com wrote: From: Jeff Irwin jeffrosq...@hotmail.com Subject: Background processes with Cygwin To: cygwin-xfree@cygwin.com Date: Friday, April 3, 2009, 2:48 PM Snipped The window will stay up for a few minutes and then go away and the script that was running is now dead. I am not an expert by any means so any help regardless of elementary is appreciated. I know I am not the first squirrel to try to crack this nut so I figured I would toss this out in hopes some “big brain” would take notice and pity. PMFJI here, but if you log out of Cygwin, then the Cygwin process terminates. Why would you think that a process started under Cygwin could survive the termination of Cygwin? That just doesn't make sense, even to this raw newbie. Among other things, the whole *ix environment that Cygwin provides would be gone, so how could your process possibly continue? This isn't real *ix, it's *ix facilities provided under the control of another quite different (and generally more hostile) OS environment. Maybe I'm missing something crucial in my understanding of how Cygwin and Windows operate. If so, I'd appreciate a cure for my ignorance. Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: cygwin and cygwin-xfree lists to merge
--- On Fri, 12/12/08, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: Snipped My sympathies are growing milder by the minute. I am only a lurker here just trying to keep track of events in cygwin-X, but I do think your arguments for re-merging the lists are not unreasonable. It will mean change for those who have only been tracking cygwin-X, and that's not always comfortable. I frankly can't come up with any solid reason to oppose the re-merge, so I guess that's a yes vote here. Especially if you have already planned on using Mr. Betts' ideas about maintaining X-threads and links to the X-archives. Regards, Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: slow paints despite fast hardware
PMFJIH, but is the WinXP screen resolution *substantially* different from the ubuntu screen resolution? I do not know if it solves anything, but could a big difference in the screen resolutions explain observably slower paints? Just a thought. Peter --- Phlip [EMAIL PROTECTED] wrote: Snipped My Cygwin's X server generates the slowest GUIs on my workstation. The rest handle simple repaints in user-time. I have observed this problem, off and on, over several different platforms and configurations, for over a year by now, and it has limited my ability to make Cygwin productive. The problem's tenacity makes me think it is commonly reported and easy to fix. My inability to read the various xinitrc-related batch files, and to Google for their documentation and online FAQs, has told me simply that there is something that I don't know how to even ask about. So I ask my question as a metaphor. Because I have experience with GUI systems that ship in a safe configuration, instead of the fast configuration, I ask if this is the case for Cygwin's X server. Things go downhill from there, but I'm not sure if any better metaphor were possible... The question remains: Where do I start the investigate, and what RC files and setting lines might control the situation? -- Phlip __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
login xterm session - /etc/profile script adds duplicates to some *PATH vars
Hi all, I noticed a slight problem with three of the *PATH variables that are set in a login xterm window, such as the one started by the startxwin.sh script. It seems to be caused by the /etc/profile script blindly adding directories to PATH, MANPATH and INFOPATH. In startxwin.sh, the xterm is started with this: xterm -e /usr/bin/bash -l When you run the following command in that xterm window, notice the duplicate directories at the start of the INFOPATH, MANPATH and PATH variables: set | grep PATH Is this a Cygwin-X problem, or is this a base Cygwin problem? I'll gladly report it over on the regular Cygwin list if needed. Regards, Peter __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Question about coreutils common option -
I thought the following would produce ls -l output for the space-separated list of files selected by the find options, but instead I get an error message from ls: $ find a -daystart -type f -mtime 7 -printf %p|ls -l - ls: -: No such file or directory The output from the find looks like this: $ find a -daystart -type f -mtime 7 -printf %p a/list.txt a/list_0002.txt I do not have an *ix system on which to test if this is a Cygwin coreutils problem or a misunderstanding by me of the operation of the - option. Can you please tell me if I am wrong about my use of the - option? cygcheck -svr output pasted below, unfortunately Yahoo mail doesn't seem to allow me to create an attachment to send. TIA for any help/RTFM/info you can provide. Peter Cygwin Configuration Diagnostics Current System Time: Sat Aug 06 14:59:07 2005 Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\ATI Technologies\ATI Control Panel c:\PROGRA~1\COMMON~1\SONICS~1\ c:\Program Files\IBM\Personal Communications\ c:\Program Files\IBM\Trace Facility\ c:\Program Files\Support Tools\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 1007(Peter)GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1007(Peter)GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = `Peter' PWD = `/cygdrive/c/mvs38j/prt' HOME = `/home/Peter' MAKE_MODE = `unix' HOMEPATH = `\Documents and Settings\Peter' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man:/usr/X11R6/man' APPDATA = `C:\Documents and Settings\Peter\Application Data' HOSTNAME = `D2419R51-8400' TERM = `cygwin' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 3 Stepping 4, GenuineIntel' WINDIR = `C:\WINDOWS' TEXDOCVIEW_txt = `cygstart %s' TEXDOCVIEW_dvi = `cygstart %s' OLDPWD = `/cygdrive/c/mvs38j/prt' USERDOMAIN = `D2419R51-8400' OS = `Windows_NT' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' !:: = `::\' TEMP = `/cygdrive/c/DOCUME~1/Peter/LOCALS~1/Temp' COMMONPROGRAMFILES = `C:\Program Files\Common Files' USERNAME = `Peter' TEXDOCVIEW_pdf = `cygstart %s' PROCESSOR_LEVEL = `15' FP_NO_HOST_CHECK = `NO' SYSTEMDRIVE = `C:' TEXDOCVIEW_html = `cygstart %s' USERPROFILE = `C:\Documents and Settings\Peter' CLIENTNAME = `Console' PS1 = `\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = `\\D2419R51-8400' PROCESSOR_ARCHITECTURE = `x86' !C: = `C:\cygwin\bin' SHLVL = `1' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = `C:' PROMPT = `$P$G' COMSPEC = `C:\WINDOWS\system32\cmd.exe' TMP = `/cygdrive/c/DOCUME~1/Peter/LOCALS~1/Temp' SYSTEMROOT = `C:\WINDOWS' PRINTER = `hp photosmart 1218 series' CVS_RSH = `/bin/ssh' PROCESSOR_REVISION = `0304' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' TEXDOCVIEW_ps = `cygstart %s' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' PROGRAMFILES = `C:\Program Files' NUMBER_OF_PROCESSORS = `2' SESSIONNAME = `Console' COMPUTERNAME = `D2419R51-8400' PCOMM_ROOT = `C:\Program Files\IBM\Personal Communications\' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' 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' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS152539Mb 22% CP CS UN PA FC d: cd CDFS 545Mb 100%CS UN CDROM e: cd CDFS 592Mb 100%CS UN Sims2EP1_1 f: hd FAT 1019Mb 2% CPUN g: hd FAT 2039Mb 58% CPUN h: hd FAT 2039Mb 32% CPUN i: hd FAT 2039Mb 78% CPUN j: hd FAT 2039Mb 81% CPUN GNU k: hd FAT376Mb 51% CPUN DJGPP l: hd FAT 1176Mb 94% CPUN DATA m: hd FAT643Mb 87% CPUN WINDOWS n: hd FAT 2039Mb 99% CPUN
Re: Question about coreutils common option -
--- Brian Dessent [EMAIL PROTECTED] wrote: Snipped I've never heard of using '-' to ls this way. The coreutils info page does list it as a common flag, but my interpretation of the language there is that it's only referring to programs that act as input/output filters, not as a general- purpose way of passing filename arguments. That's why xargs exists. How to use xargs is a definite hole in my knowledge. I have read the xargs info a few times, but I don't think I have understood it yet. I will go back to it and try to get it this time. You can get ls-like output from find without any other programs: find a -daystart -type f -mtime 7 -ls If you must use an external program, the usual way to take the output from find and send it as arguments is with xargs: find a -daystart -type f -mtime 7 | xargs ls -l Yes, I saw that in the info for the find -ls option, but in this case I am going to eventually substitute another external program for ls to process the filenames in another way. xargs would seem to be the correct answer for that, as you noted. Note that both this and your '-printf %p' method will not work for filenames that contain spaces or special characters. Therefore the superior way of doing this is: find a -daystart -type f -mtime 7 -print0 | xargs -0 ls -l Not a problem in this case, the filenames to be processed are space-less and without any special characters because of the program that creates them. Thanks anyway for the info, I will remember it. Snipped It doesn't work under linux either. (It's the same coreutils code in either case.) Understood. Many thanks for reducing my level of ignorance. Peter __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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: pwd vs $PWD, bash, cygwin vs Linux
But what if it is *not* your Makefile, but someone else's, e.g. the many GNU source packages that expect bash behavior? Surely you don't intend that ordinary users (well, OK, anyone compiling from a source package isn't really ordinary) should modify every package maintained by GNU in order to make it under cygwin, do you? With respect, Peter P.S. - If there have already been discussions or if there already exists documentation on why ash vs. bash (I gather it is for performance reasons), I'd appreciate (a) pointer(s) so I could better learn the history so I don't re-hash settled issues. --- Christopher Faylor [EMAIL PROTECTED] wrote: Snipped I really don't understand why using CURDIR isn't the ultimate solution here. If you can mess with your mount table or copy bash to sh, then you really should be able to also change your Makefile to use $(CURDIR) rather than $$PWD. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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: pwd vs $PWD, bash, cygwin vs Linux
WHOA there. I think we have a slight failure to communicate. I am NOT the OP, I was just chiming in on the conversation (I should have said PMFJI right up front, apologies for forgetting that). That said, I understand your position better now, especially with Dave's workaround (perfectly acceptable to me, don't know about the OP). I certainly did NOT intend to say or to imply that cygwin maintainers should make any global fix to address this issue. I just did not understand the reason that bash was not the default shell. Now I do. Thank you (and Dave Korn) for straightening me out. Mea maxima culpa for not being clear in my question or my comments. Peter --- Christopher Faylor [EMAIL PROTECTED] wrote: On Wed, May 04, 2005 at 08:05:40AM -0700, Peter Farley wrote: But what if it is *not* your Makefile, I just went back and reread this thread. It isn't exactly clear that this was not your Makefile. You mentioned a test setup which seemed to imply that you were using your own Makefiles. but someone else's, e.g. the many GNU source packages that expect bash behavior? Most GNU packages are interested in being portable. Assuming that every system out there is POSIX compliant is not portable. I have a couple of older systems that I use which would have the same problems as cygwin if you use PWD in a Makefile. Actually, CURDIR would also be a problem for them since they don't use GNU make. Since the workaround is trivial it would make sense to not rely on PWD in any package that is supposed to be disseminated widely. Surely you don't intend that ordinary users (well, OK, anyone compiling from a source package isn't really ordinary) should modify every package maintained by GNU in order to make it under cygwin, do you? I would expect a GNU-maintained package to accept a patch to eliminate a potential problem source. However, I surely don't intend to keep talking about this any further. I get the feeling that you want us (i.e., cygwin maintainers) to do something globally to solve this. We've been using ash for many years and we're not about to change anytime soon. You've been given enough alternatives now that you should be able to get things working. Cygwin is not guaranteed to be 100% POSIX compliant or 100% linux compliant. Sometimes we make tradeoffs because of Windows constraints. Since bash is noticeably slower than ash under Cygwin, we use ash as our /bin/sh. That produces some problems for non-portable shell constructs. cgf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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: read bug in Cygwin 1.5.16?
I tried the 20050501 snapshot today. The bug has been squashed. Both the test program and hercules operate correctly in an xterm window with the snapshot version of cygwin1.dll. Thank you for the fix. I will let the hercules list know that the bug will be resolved in the next release. Regards, Peter --- Peter Farley [EMAIL PROTECTED] wrote: Thanks Chris. I will try to test the snapshot soon, but I may have some RL events interrupting me before I can do so. I'll report back after testing. Peter --- Christopher Faylor [EMAIL PROTECTED] wrote: On Sun, May 01, 2005 at 04:56:13PM -0700, Peter Farley wrote: Hi all, I tried to forward this message to the main cygwin list yesterday, but had a little trouble getting it there, probably because I mentioned xterm in the subject. I'm trying again in case this is NOT an X problem but a base cygwin problem. I have attached the test program xtermbug.c instead of pasting it inline. I hope that is OK for this list. Thanks for the test program. There was a problem with setting VMIN == VTIME == 0 on ttys/ptys. I've just checked in a fix. It will be in today's snapshot, when it shows up: http://cygwin.com/snapshots/ . cgf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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/ __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re: read bug in Cygwin 1.5.16?
I tried the 20050501 snapshot today. The bug has been squashed. Both the test program and hercules operate correctly in an xterm window with the snapshot version of cygwin1.dll. Thank you for the fix. I will let the hercules list know that the bug will be resolved in the next release. Regards, Peter --- Peter Farley [EMAIL PROTECTED] wrote: Thanks Chris. I will try to test the snapshot soon, but I may have some RL events interrupting me before I can do so. I'll report back after testing. Peter --- Christopher Faylor [EMAIL PROTECTED] wrote: On Sun, May 01, 2005 at 04:56:13PM -0700, Peter Farley wrote: Hi all, I tried to forward this message to the main cygwin list yesterday, but had a little trouble getting it there, probably because I mentioned xterm in the subject. I'm trying again in case this is NOT an X problem but a base cygwin problem. I have attached the test program xtermbug.c instead of pasting it inline. I hope that is OK for this list. Thanks for the test program. There was a problem with setting VMIN == VTIME == 0 on ttys/ptys. I've just checked in a fix. It will be in today's snapshot, when it shows up: http://cygwin.com/snapshots/ . cgf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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/ __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ -- 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/
Can I mount an EXT3 partition that WinXP sees as (Unknown partition)?
On a firewire-mounted external hard drive I have an EXT3 partition that used to be the root file system for an RH7.3 linux setup. Is there any way to mount such a partition to cygwin when XP doesn't recognize it with a drive letter? The partition is primary, not extended. Regards, Peter __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ -- 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: Can I mount an EXT3 partition that WinXP sees as (Unknown partition)?
Thanks Larry. I only need read access for my home system and not commercial support, so I'll check out Explore2fs. Peter --- Larry Hall [EMAIL PROTECTED] wrote: At 04:00 PM 5/3/2005, you wrote: On a firewire-mounted external hard drive I have an EXT3 partition that used to be the root file system for an RH7.3 linux setup. Is there any way to mount such a partition to cygwin when XP doesn't recognize it with a drive letter? The partition is primary, not extended. No. You need software that knows the filesystem first. You can check out Paragon if you're looking for commercial support. There is an older free S/W driver for ext2 and NT but I haven't tried it since NT 4 and I can't recommend it. If you're just looking to get read access (and/or very touchy write access) and don't mind the slowness of a user-land utility, check out Explore2fs http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm. I don't know if it works with FireWire but it does work fine with local ext3 partitions. __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ -- 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: Can I mount an EXT3 partition that WinXP sees as (Unknown partition)?
FYI, explore2fs found both my boot and root partitions on the firewire external drive with no trouble. Thanks for the pointer, this is just what I needed, an easy way to copy info over to cygwin. Peter --- Larry Hall [EMAIL PROTECTED] wrote: At 04:00 PM 5/3/2005, you wrote: On a firewire-mounted external hard drive I have an EXT3 partition that used to be the root file system for an RH7.3 linux setup. Is there any way to mount such a partition to cygwin when XP doesn't recognize it with a drive letter? The partition is primary, not extended. No. You need software that knows the filesystem first. You can check out Paragon if you're looking for commercial support. There is an older free S/W driver for ext2 and NT but I haven't tried it since NT 4 and I can't recommend it. If you're just looking to get read access (and/or very touchy write access) and don't mind the slowness of a user-land utility, check out Explore2fs http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm. I don't know if it works with FireWire but it does work fine with local ext3 partitions. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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: read bug in Cygwin 1.5.16?
Thanks Chris. I will try to test the snapshot soon, but I may have some RL events interrupting me before I can do so. I'll report back after testing. Peter --- Christopher Faylor [EMAIL PROTECTED] wrote: On Sun, May 01, 2005 at 04:56:13PM -0700, Peter Farley wrote: Hi all, I tried to forward this message to the main cygwin list yesterday, but had a little trouble getting it there, probably because I mentioned xterm in the subject. I'm trying again in case this is NOT an X problem but a base cygwin problem. I have attached the test program xtermbug.c instead of pasting it inline. I hope that is OK for this list. Thanks for the test program. There was a problem with setting VMIN == VTIME == 0 on ttys/ptys. I've just checked in a fix. It will be in today's snapshot, when it shows up: http://cygwin.com/snapshots/ . cgf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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: read bug in Cygwin 1.5.16?
Thanks Brian, but I don't think support on earlier versions of cygwin is going to be an issue. There's only one other person who tried and found this same bug, so we're somewhat rara avis (rare birds). If the snapshot fix works, I can wait for the release to come out. It isn't that urgent, since my workaround is just to run in a console window instead of an xterm. Thanks again for the help. Peter --- Brian Dessent [EMAIL PROTECTED] wrote: Christopher Faylor wrote: There was a problem with setting VMIN == VTIME == 0 on ttys/ptys. I've just checked in a fix. It will be in today's snapshot, when it shows up: http://cygwin.com/snapshots/ . Peter Farley wrote: kbattr.c_cc[VMIN] = 0; kbattr.c_cc[VTIME] = 0; If you're always using select() to read, you could set VMIN = 1 as a workaround if you need to support versions of Cygwin prior to the above fix. Brian __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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/
read bug in Cygwin 1.5.16?
Hi all,
I tried to forward this message to the main cygwin
list yesterday, but had a little trouble getting it
there, probably because I mentioned xterm in the
subject. I'm trying again in case this is NOT an X
problem but a base cygwin problem.
I have attached the test program xtermbug.c instead
of pasting it inline. I hope that is OK for this
list.
If there is anything I can do to help debug the reason
I am seeing this problem, please just tell me what to
do.
BTW, thanks to all the developers for an awesome
product.
Regards,
Peter Farley
--- Peter Farley [EMAIL PROTECTED] wrote:
Hi all,
The following program demonstrates what looks to me
like a bug in the read function in an xterm (as
opposed to a Cygwin console window). To run the
test, compile with:
gcc -g -o xtermbug.exe xtermbug.c
When you run it in a console window, you can enter
normal keyboard characters, then a return to see
cmdline=what you typed. Press the Esc key to
exit the program.
When run in an xterm window, the first keypress
causes this behavior:
1. Select returns with rc = 0 and readset set to
indicate that a key was received
2. read returns with kblen = 1 and kbbuf[0] = '\0'
3. (1) and (2) repeat forever.
I put in a maxdbg parameter and terminate the
program after 5 occurrences of this loop.
This problem was first detected trying to run a copy
of the hercules IBM mainframe emulator in a Cygwin
xterm window. The code below is extracted and
minimalized as much as possible from the hercules
keyboard input routine.
Peter Farley
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com /*---*/
/* This is a test program to show a cygwin xterm bug, possibly */
/* in the read function. */
/*---*/
/*---*/
/* Definitions for keyboard input sequences */
/*---*/
#define KBD_DELETE \x1B[3~
#include stdio.h
#include unistd.h
#include sys/time.h
#include string.h
#include errno.h
#include termios.h
#define MSG_SIZE80 /* Size of one message */
#define CMD_SIZE 32767 /* Length of command line*/
#define BYTE unsigned char
int ttyreset = 0;
struct termios kbattr; /* Terminal I/O structure*/
/*---*/
/* xterm display subroutine */
/*---*/
void xterm_display (void)
{
int rc; /* Return code */
int i; /* Array subscripts */
charcmdline[CMD_SIZE+1];/* Command line buffer */
int cmdoff = 0; /* Cursor position in cmdline*/
int cmdlen = 0; /* Number of bytes in cmdline*/
//BYTEc; /* Character work area */
FILE *confp; /* Console file pointer */
size_t kbbufsize = CMD_SIZE; /* Size of keyboard buffer */
char *kbbuf = NULL; /* Keyboard input buffer */
int kblen; /* Number of chars in kbbuf */
int keybfd; /* Keyboard file descriptor */
int maxfd; /* Highest file descriptor */
fd_set readset;/* Select file descriptors */
struct timeval tv; /* Select timeout structure */
int maxdbg = 0;
/* Set up the input file descriptors */
confp = stdout;
keybfd = STDIN_FILENO;
fprintf(confp, start kbbuf=%8.8X,kbbuf=%8.8X\n,
kbbuf, kbbuf);
/* Obtain storage for the keyboard buffer */
if (!(kbbuf = (char *)malloc (kbbufsize)))
{
fprintf(stderr, HHCPN002S Cannot obtain keyboard buffer: %s\n,
strerror(errno));
return;
}
fprintf(confp, start kbbuf=%8.8X,kbbuf=%8.8X,*kbbuf=%8.8X\n,
kbbuf, kbbuf, *kbbuf);
/* Set screen output stream to fully buffered */
setvbuf (confp, NULL, _IOFBF, 0);
/* Put the terminal into cbreak mode */
tcgetattr (keybfd, kbattr);
kbattr.c_lflag = ~(ECHO | ICANON);
kbattr.c_cc[VMIN] = 0;
kbattr.c_cc[VTIME] = 0;
tcsetattr (keybfd, TCSANOW, kbattr);
ttyreset = 1;
fprintf(confp, Starting while(1) loop.\n);
fflush(confp);
/* Process messages and commands */
while (1)
{
/* Set the file descriptors for select */
FD_ZERO (readset);
FD_SET (keybfd, readset
read bug in Cygwin xterm window only
Hi all,
The following program demonstrates what looks to me
like a bug in the read function in an xterm (as
opposed to a Cygwin console window). To run the test,
compile with:
gcc -g -o xtermbug.exe xtermbug.c
When you run it in a console window, you can enter
normal keyboard characters, then a return to see
cmdline=what you typed. Press the Esc key to exit
the program.
When run in an xterm window, the first keypress causes
this behavior:
1. Select returns with rc = 0 and readset set to
indicate that a key was received
2. read returns with kblen = 1 and kbbuf[0] = '\0'
3. (1) and (2) repeat forever.
I put in a maxdbg parameter and terminate the
program after 5 occurrences of this loop.
This problem was first detected trying to run a copy
of the hercules IBM mainframe emulator in a Cygwin
xterm window. The code below is extracted and
minimalized as much as possible from the hercules
keyboard input routine.
Peter Farley
xtermbug.c:
/*---*/
/* This is a test program to show a cygwin xterm bug,
possibly */
/* in the read function.
*/
/*---*/
/*---*/
/* Definitions for keyboard input sequences
*/
/*---*/
#define KBD_DELETE \x1B[3~
#include stdio.h
#include unistd.h
#include sys/time.h
#include string.h
#include errno.h
#include termios.h
#define MSG_SIZE80 /* Size of one
message */
#define CMD_SIZE 32767 /* Length of
command line*/
#define BYTE unsigned char
int ttyreset = 0;
struct termios kbattr; /* Terminal I/O
structure*/
/*---*/
/* xterm display subroutine
*/
/*---*/
void xterm_display (void)
{
int rc; /* Return code
*/
int i; /* Array
subscripts */
charcmdline[CMD_SIZE+1];/* Command
line buffer */
int cmdoff = 0; /* Cursor
position in cmdline*/
int cmdlen = 0; /* Number of
bytes in cmdline*/
//BYTEc; /* Character
work area */
FILE *confp; /* Console
file pointer */
size_t kbbufsize = CMD_SIZE; /* Size of
keyboard buffer */
char *kbbuf = NULL; /* Keyboard
input buffer */
int kblen; /* Number of
chars in kbbuf */
int keybfd; /* Keyboard
file descriptor */
int maxfd; /* Highest
file descriptor */
fd_set readset;/* Select file
descriptors */
struct timeval tv; /* Select
timeout structure */
int maxdbg = 0;
/* Set up the input file descriptors */
confp = stdout;
keybfd = STDIN_FILENO;
fprintf(confp, start kbbuf=%8.8X,kbbuf=%8.8X\n,
kbbuf, kbbuf);
/* Obtain storage for the keyboard buffer */
if (!(kbbuf = (char *)malloc (kbbufsize)))
{
fprintf(stderr, HHCPN002S Cannot obtain
keyboard buffer: %s\n,
strerror(errno));
return;
}
fprintf(confp, start
kbbuf=%8.8X,kbbuf=%8.8X,*kbbuf=%8.8X\n,
kbbuf, kbbuf, *kbbuf);
/* Set screen output stream to fully buffered */
setvbuf (confp, NULL, _IOFBF, 0);
/* Put the terminal into cbreak mode */
tcgetattr (keybfd, kbattr);
kbattr.c_lflag = ~(ECHO | ICANON);
kbattr.c_cc[VMIN] = 0;
kbattr.c_cc[VTIME] = 0;
tcsetattr (keybfd, TCSANOW, kbattr);
ttyreset = 1;
fprintf(confp, Starting while(1) loop.\n);
fflush(confp);
/* Process messages and commands */
while (1)
{
/* Set the file descriptors for select */
FD_ZERO (readset);
FD_SET (keybfd, readset);
maxfd = keybfd;
/* Wait for a key to be pressed,
or the inactivity interval to expire */
tv.tv_sec = 1;
tv.tv_usec = 1 % 100;
rc = select (maxfd + 1, readset, NULL, NULL,
tv);
if (rc 0 )
{
if (errno == EINTR) continue;
fprintf (stderr,
HHCPN004E select: %s\n,
strerror(errno));
break;
}
fprintf(confp, rc=%d,readset={%8.8X,%8.8X}\n, rc,
readset.fds_bits[0], readset.fds_bits[1]);
fflush(confp);
/* If keyboard input has arrived then process
it */
if (FD_ISSET(keybfd, readset))
{
/* Read character(s) from the keyboard */
kblen = read (keybfd
