Re: [ITP] bind-9.6.0-1
On Jan 21 17:11, Yaakov (Cygwin/X) wrote: Corinna Vinschen wrote: I'm not asking to use the resolver lib. I'm asking that the resolver code in bind's libs uses the same method to fetch nameserver and domain information as Cygwin's default resolver does. You could just as easily make the same argument on Linux: glibc already includes a resolver lib, so why shouldn't BIND use it? I have yet to see a Linux distribution patch bind to use libresolv, and I see little difference between using libresolv and copying (part of) minires into BIND. Is my English really so bad? I'm not (NOT) asking that bind uses the minires/Cygwin resolver. I'm just talking about the methods used to fetch resolver information. On Linux, the resolver in glibc and the resolver code in BIND are using the same technique. Which is, fetch the information from /etc/resolv.conf. That file is the only source of information on Linux anyway. On Cygwin, the resolver code in minires/Cygwin is right now using a different technique than the resolver code in BIND. Minires/Cygwin uses the Win32 function GetNetworkParam() if /etc/resolv.conf does not exist. The idea is that you enhance the BIND resolver code to do the same: Use /etc/resolv.conf if it exists. But if not, use GetNetworkParam() to fetch the same information. And that's a big difference since the user doesn't have to duplicate this information, especially if it changes. And using GetNetworkParam is really simple. An #ifdef __CYGWIN__ with about 30 lines of code. Which is basically - use /etc/resolv.conf if available - otherwise, use Windows' GetNetworkParam() function. You asked originally if it was feasible to do so. There is a Windows version of BIND, so perhaps it is possible, but AFAICS accomodating both would be difficult to maintain. If we're going to expect every Cygwin user to maintain an /etc/fstab, I really don't see why we can't expect those few who want to use BIND to maintain an /etc/resolv.conf. Apples/Oranges. POSIX mount points don't exist anywhere in Windows, resolver information does. Yes, /etc/passwd and /etc/group also contain redundant information and I'm not happy with it. But in contrast to /etc/resolv.conf the information in this files also contains information not available on the system by default. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] lftp
On Jan 21 15:29, Andrew Schulman wrote: # 1.5 # Please leave 3.7.3-2 as previous, delete others I left 3.7.3-1 as previous ;) wget \ http://home.comcast.net/~andrex2/cygwin-1.5/lftp/lftp-3.7.6-3.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin-1.5/lftp/lftp-3.7.6-3-src.tar.bz2 # 1.7 # Please leave 3.7.3-2 as previous, delete others wget \ http://home.comcast.net/~andrex2/cygwin-1.7/lftp/lftp-3.7.6-4.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin-1.7/lftp/lftp-3.7.6-4-src.tar.bz2 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
XWin with rootless option crashes on Vista
Hello All, I had been using Cygwin with ICEWM on my XP box for sometime. I moved to (asked to move to) Vista recently and I installed Cygwin and compiled ICEWM on my box. My problem is that, I am able to run startxwin.bat with the multiwindow option, but not with the rootless or fullscreen option since XWin just crashes. I understand that files have been modified in the new Cygwin, so I stuck to making changes in the .bat file only. I tried running startx too, but not with much avail. In short, running startxwin.bat with XWin-multiwindow starts the X Server and I am able to launch newer xterms. If I remove the multiwindow option altogether or change it with rootless (ideal for me since I want to run a different window manager) or fullscreen, XWin crashes. I understand that there are a few applications that cause strange issues with cygwin and I seem to have one such on my box (Logitech's webcam package). I would be glad with any advice on this issue. I looked through the forums, but I haven't been able to find a thread that matches my problem. Thanks for your time. Regards, Rincewind -- View this message in context: http://www.nabble.com/XWin-with-%22rootless%22-option-crashes-on-Vista-tp21617618p21617618.html Sent from the cygwin-xfree mailing list archive at Nabble.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/
Re: XWin with rootless option crashes on Vista
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 rincewind wrote: I had been using Cygwin with ICEWM on my XP box for sometime. I moved to (asked to move to) Vista recently and I installed Cygwin and compiled ICEWM on my box. My problem is that, I am able to run startxwin.bat with the multiwindow option, but not with the rootless or fullscreen option since XWin just crashes. I understand that files have been modified in the new Cygwin, so I stuck to making changes in the .bat file only. I tried running startx too, but not with much avail. In short, running startxwin.bat with XWin-multiwindow starts the X Server and I am able to launch newer xterms. If I remove the multiwindow option altogether or change it with rootless (ideal for me since I want to run a different window manager) or fullscreen, XWin crashes. I understand that there are a few applications that cause strange issues with cygwin and I seem to have one such on my box (Logitech's webcam package). I would be glad with any advice on this issue. I looked through the forums, but I haven't been able to find a thread that matches my problem. http://cygwin.com/faq/faq.using.html#faq.using.bloda Please try completely uninstalling the Logitech software, make sure you're running the current versions of Cygwin and X11, and try again. If that does not help: http://cygwin.com/problems.html In addition to *attaching* the output of cygcheck -s -r -v, please also attach the /var/log/XWin.0.log from the failed attempt. Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkl5Lg0ACgkQpiWmPGlmQSOtnwCgzXV6zM46MHKEYzvB2ff5qQWv nDoAnj0GS6Oj9T/j6eDqA9bVk5Ps4Dp3 =aq8F -END PGP SIGNATURE- -- 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/
winsup/cygwin ChangeLog select.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2009-01-22 16:00:58 Modified files: cygwin : ChangeLog select.cc Log message: * select.cc (peek_serial): Add hack to allow proper operation with com0com driver. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4360r2=1.4361 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/select.cc.diff?cvsroot=uberbaumr1=1.144r2=1.145
chere and mintty patch
Hi, Hereby a patch for chere to add support for MinTTY as well. Regards, Frank chere-mintty.diff Description: Binary data -- 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/
WG: Re: SSH V.5.1 with Cygwin1.dll 1.7.0(0.189/5/3) 2008-12-09: Very large logon times...
Hello Corinna, my name is Markus Bauer. I'm a colleague from Carsten Porzler and I tried to figure out where the time is wasted. I put some debugging statements in sec_auth.cc and syscalls.cc. The strange is, that I only see the statements from syscalls.cc but not the many I put in sec_auth.cc. Maybe you have an idea? Thank you very much. Markus Bauer Carsten Porzler/sdv schrieb am 16.01.2009 12:59:03: WG: Re: SSH V.5.1 with Cygwin1.dll 1.7.0(0.189/5/3) 2008-12-09: Very large logon times... Carsten Porzler an: Markus Bauer 16.01.2009 12:59 FYI - Weitergeleitet von Carsten Porzler/sdv am 16.01.2009 12:58 - Von: Corinna Vinschen corinna-cyg...@cygwin.com An: cygwin@cygwin.com Datum: 09.01.2009 13:49 Betreff: Re: SSH V.5.1 with Cygwin1.dll 1.7.0(0.189/5/3) 2008-12-09: Very large logon times... Gesendet von: cygwin-ow...@cygwin.com On Jan 7 11:02, carsten.porz...@spb.de wrote: I just compiled the cygwin sources from the latest snapshot for testing. It seems to be working... So, please tell me the debugging statements I have to insert into the source code to figure out where the logon process takes the time. The idea is to add statements along these lines debug_printf (CHECKPOINT 1); debug_printf (CHECKPOINT 2); debug_printf (CHECKPOINT 3); [...] liberally across the functions in the winsup/cygwin/sec_auth.cc file, with the starting point being the function lsaauth(), line 912 in recent sources, so that we can track down where exactly the time is wasted. After you added these statements all over the place, stop sshd, install this new DLL and then, before starting sshd again, tweak the following registry entries: HKLM\SYSTEM\CurrentControlSet\Services\sshd\Parameters AppPath == /bin/strace AppArgs == -o C:/sshd-strace.out /usr/sbin/sshd -d Note the old entries before so you can restore them afterwards. Now log in exactly once and log out again. Afterwards, the sshd process will have stopped automatically (that's what the lowercase -d does). Note that it takes *much* longer to login when running under strace. Be (even more) patient. After each run, examine the CHECKPOINTs in the C:/sshd-strace.out file. The left two columns show times in milliseconds which denotes the time it took to get to this statement, relative to the last debug output and relative to the process start. At one point you will see that these numbers between two CHECKPOINTs are unusual high. That means, the culprit of the delay is somewhere between these two CHECKPOINTs. Now let's play stepwise refinement and add more of these CHECKPOINTs between the other two and reiterate the steps above, until you think you nailed it down to a certain part of the DLL, or even a single Windows function call. For a start, add these, relative to the current code in CVS: syscalls.cc, line 2616: debug_printf (CHECKPOINT ); sec_auth.cc, line 945: debug_printf (CHECKPOINT 0); sec_auth.cc, line 1177: debug_printf (CHECKPOINT 9998); I assume the delay occurs either when trying to get the logon server information (function get_logon_server, line 180), or when connecting the logon server to fetch group information (function get_user_groups, line 225 and function get_user_local_groups, line 313), so it might be a good idea to add more CHECKPOINTs there. When you think you found it, I'll take another look into it and hopefully this can be fixed easily. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: 1.5 / 1.7 setup.exe entanglement?
On Jan 21 15:01, Warren Young wrote: I got a new machine at work a few weeks ago, and decided to install Cygwin 1.7 on it, and not even mess with 1.5. Can't test what you don't use, right? For reasons that aren't important here, today I decided I needed a copy of 1.5 as well. This means I have the reverse of the recommended setup, which is having 1.5 installed in c:\cygwin, and 1.7 elsewhere. 1.7 on my machine is in c:\cygwin, and 1.5 is in c:\cygwin-1.5. The installation of 1.5 failed in several ways. The way it failed makes me wonder if some part of the setup process was erroneously referring to stuff in c:\cygwin instead of c:\cygwin-1.5. Yes, the reason is that setup looks into c:\cygwin by default and if it finds setup files there, it will use them, even when you change the path. That doesn't occur in the new setup-1.7.exe, but that doesn't help with installing 1.5 after 1.7, of course. What you should do in this case, basically: - Stop all 1.7 processes. - Rename C:\cygwin to C:\cygwin-foo - Start setup for 1.5 - change the installation path to c:\cygwin-1.5 - After the installation, rename C:\cygwin-foo back to C:\cygwin Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: mtr under cygwin
On Jan 21 17:55, David Arnstein wrote: I am able to compile mtr 0.75 under Cygwin, see http://www.bitwizard.nl/mtr/. But mtr is not working. Using ddd, I see that the call getsockname (recvsock, name, len); does not seem to be filling in name correctly, when recvsock=3. It fills in name-sa_family = 0. Any suggestions? Debugging might help. getsockname usually works fine. If you're not using AF_LOCAL sockets, it's a more or less thin shim for the Winsock getsockname function. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: ???????? owner and group
On Jan 21 16:52, Warren Young wrote: I'm breaking in a new machine, and just noticed that when I ls -l a Samba share I have mounted, I get in place of the user and group instead of myname None as I normally expect, for all files. If I say ls -ln, the values are (u_long(-1)). If I list something on the local filesystem that I own, it's fine. Some system files show similar question mark symptoms, though, like regedit.exe: -rwxrwx---+ 2 4294967295 4294967295 134656 Jan 20 2008 regedit.exe Following advice about in the user guide, I checked that /etc/passwd exists, and it does. I added 'acl' to my cygdrive mount line in /etc/fstab for 1.7, but that didn't change anything. Exactly. 'acl' is the default anyway. The problem is this: Have a look into the ACL by using Windows Explorer properties/security dialog. What you see is thatthe user and group for a file on the share is Unix User\yourunixuser and Unix Group\yourunixgroup. These accounts are missing in your /etc/passwd and /etc/group files. What you can do: - Add the Unix accounts to /etc/passwd and /etc/group, for instance: $ mkpasswd -L sambaserver,2 -U yourunixuser Unix User\yourunixuser:unused:21000:9:,S-1-22-1-1000:: $ mkgroup -L sambaserver -U yourunixgroup Unix Group\yourunixgroup:S-1-22-2-101:20101: - Change the cygdrive flags in /etc/fstab to noacl, which is equivalent to the old CYGWIN=nosmbntsec. I haven't noticed any permission failures, so maybe this is just a display issue, not some credential issue. Right. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: WG: Re: SSH V.5.1 with Cygwin1.dll 1.7.0(0.189/5/3) 2008-12-09: Very ?large logon times...
On Jan 22 09:44, Markus.Bauer wrote: Hello Corinna, I already told your collegue Carsten: Please, don't http://cygwin.com/acronyms/#TOFU I hope you're aware that cygwin@cygwin.com is a public mailing list? I'm just asking because you're addressing me personally... my name is Markus Bauer. I'm a colleague from Carsten Porzler and I tried to figure out where the time is wasted. I put some debugging statements in sec_auth.cc and syscalls.cc. The strange is, that I only see the statements from syscalls.cc but not the many I put in sec_auth.cc. Maybe you have an idea? No. Not really. The only reason could be that the code isn't called. Only further debugging will help. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: 1.5 / 1.7 setup.exe entanglement?
On Jan 22 12:12, Corinna Vinschen wrote: On Jan 21 15:01, Warren Young wrote: The installation of 1.5 failed in several ways. The way it failed makes me wonder if some part of the setup process was erroneously referring to stuff in c:\cygwin instead of c:\cygwin-1.5. Yes, the reason is that setup looks into c:\cygwin by default and if it finds setup files there, it will use them, even when you change the path. That doesn't occur in the new setup-1.7.exe, but that doesn't help with installing 1.5 after 1.7, of course. What you should do in this case, basically: - Stop all 1.7 processes. - Rename C:\cygwin to C:\cygwin-foo I forgot an important point here: - Remove the entire 1.5 installation and remove the registry keys HKCU\Software\Cygnus Solutions and HKLM\SOFTWARE\Cygnus Solutions. - Start setup for 1.5 - change the installation path to c:\cygwin-1.5 - After the installation, rename C:\cygwin-foo back to C:\cygwin Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
1.5.18-1: undefined reference to `ffs' in mno-cygwin mode
Hi, I'm experiencing some problem with building QEMU with -O0 -mno-cygwin options. I was successfully built QEMU with -mno-cygwin and -O2 (default debug option). But -O0 gives me the following: make -C arm-softmmu all make[1]: Entering directory `/cygdrive/d/Dvs/Project/qemu-0.9.1/arm-softmmu' gcc -mno-cygwin -g -mno-cygwin -o qemu-system-arm.exe vl.o osdep.o monitor.o pci.o loader.o isa_mmio.o block-raw-win32.o lsi53c895a.o usb-ohci.o eeprom93xx.o eepro100.o ne2000.o pcnet.o rtl8139.o integratorcp.o versatilepb.o ps2.o smc91c111.o arm_pic.o arm_timer.o arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o versatile_pci.o ptimer.o realview_gic.o realview.o arm_sysctl.o mpcore.o armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o pl061.o arm-semi.o pxa2xx.o pxa2xx_pic.o pxa2xx_gpio.o pxa2xx_timer.o pxa2xx_dma.o pxa2xx_lcd.o pxa2xx_mmci.o pxa2xx_pcmcia.o pxa2xx_keypad.o pflash_cfi01.o gumstix.o spitz.o ide.o serial.o nand.o ecc.o omap.o omap_lcdc.o omap1_clk.o omap_mmc.o omap_i2c.o palm.o tsc210x.o mst_fpga.o mainstone.o gdbstub.o ../libqemu_common.a libqemu.a -lm -lz -lwinmm -lws2_32 -liphlpapi -L/usr/lib -lmingw32 -lSDLmain -lSDL -mconsole pxa2xx_gpio.o: In function `pxa2xx_gpio_handler_update': /cygdrive/d/Dvs/Project/qemu-0.9.1/hw/pxa2xx_gpio.c:129: undefined reference to `ffs' spitz.o: In function `scoop_writeb': /cygdrive/d/Dvs/Project/qemu-0.9.1/hw/spitz.c:561: undefined reference to `ffs' /cygdrive/d/Dvs/Project/qemu-0.9.1/hw/spitz.c:561: undefined reference to `ffs' omap.o: In function `omap_inth_sir_update': /cygdrive/d/Dvs/Project/qemu-0.9.1/hw/omap.c:118: undefined reference to `ffs' /cygdrive/d/Dvs/Project/qemu-0.9.1/hw/omap.c:125: undefined reference to `ffs' omap.o:/cygdrive/d/Dvs/Project/qemu-0.9.1/hw/omap.c:3650: more undefined references to `ffs' follow make[1]: Leaving directory `/cygdrive/d/Dvs/Project/qemu-0.9.1/arm-softmmu' make: Leaving directory `/cygdrive/d/Dvs/Project/qemu-0.9.1' make[1]: *** [qemu-system-arm.exe] Error 1 With the help of disassembler I found that with -O2 option, ffs was replaced with some inline code. Most likely, with -O0 gcc tries to link it with some function, but CRT for -mno-cygwin mode seems does not contain such a function. Is there any way to fix this problem? -- 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: 1.5.18-1: undefined reference to `ffs' in mno-cygwin mode
On 2009-01-22 14:32Z, Dmitry Smirnov wrote: I was successfully built QEMU with -mno-cygwin and -O2 (default debug option). But -O0 gives me the following: [...] /cygdrive/d/Dvs/Project/qemu-0.9.1/hw/omap.c:125: undefined reference to `ffs' omap.o:/cygdrive/d/Dvs/Project/qemu-0.9.1/hw/omap.c:3650: more undefined references to `ffs' follow While this isn't a Cygwin issue (you're using '-mno-cygwin'), it seems that with the '-O2' optimization option you're getting a gcc builtin (also called intrinsic) function: With the help of disassembler I found that with -O2 option, ffs was replaced with some inline code. Most likely, with -O0 gcc tries to link it with some function, but CRT for -mno-cygwin mode seems does not contain such a function. ...but with '-O0' the intrinsic isn't used. Is there any way to fix this problem? Maybe one of gcc's builtin flags would help. Also see: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Other-Builtins.html#Other-Builtins Or you could implement your own ffs() and offer it to the qemu developers so they can make their code more portable. This search: http://www.google.com/search?q=ffs+qemu leads to some links that look promising. -- 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/
Status of Compatibility with Windows Server 2008 (2k8)
Hello, I am considering upgrading my 2k3 installation to 2k8. I currently use cygwin for basic utilities: mainly lighthttpd, sshd and rsync (and the relative pleasure of using bash instead of cmd). Could someone on this list give me an idea of what kind of issues to expect in the transition? I read through the archives and there are a few issues but those seem to be dated from 2007 and earlier. -Oren PS. The compiled answer could perhaps go into the FAQ for future use. Keywords: Windows Server 2008, Windows Server 2k8 -- 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/
Problem using select() with com0com virtual serial ports
I'm using Cygwin with com0com, and I find that every other time I read
a character from the virtual serial port, select() continues to
believe the serial port is ready, but then read() will block until a
character actually comes in. This does not happen with a real serial
port.
Attached below is a test program which exhibits the symptoms when used
with com0com virtual serial ports.
I worked around the problem by performing a second select()
immediately after the first one returns with ready file descriptors.
That second select determines which of these really are ready.
Using strace and the source code for Cygwin, I worked with the author
of com0com, Vyacheslav Frolov, to find a potential problem and
solution. That thread is here:
http://sourceforge.net/forum/forum.php?thread_id=2885701forum_id=440108
Vyacheslav suggests that initially peek_serial() returns because
st.cbInQue is nonzero. However, since we didn't wait for a comm event,
EV_RXCHAR is still set on the comm handle. The next time into
select(), st.cbInQue is zero but WaitCommEvent succeeds immediately
due to the previously set event.
By clearing the comm event mask (and therefore the comm event) before
setting it to EV_RXCHAR:
select.cc function peek_serial():
...
SetCommMask (h, 0); // === added
SetCommMask (h, EV_RXCHAR);
...
we were able to build a custom cygwin1.dll that eliminates the
problem. I'm not a Win32 coder so I'm not comfortable submitting this
as a patch, but hopefully someone with the big picture view of how
this is supposed to work can take a look.
(I've redacted the cygcheck output because of the data it reveals
about my employer)
#include stdio.h
#include stdbool.h
#include termios.h
#include unistd.h
#include fcntl.h
#include sys/time.h
void setup_port(int fd) {
struct termios options;
fcntl(fd, F_SETFL, 0);
tcgetattr(fd, options);
cfsetispeed(options, B9600);
cfsetospeed(options, B9600);
options.c_cflag |= (CLOCAL | CREAD);
tcsetattr(fd, TCSANOW, options);
}
int main(int argc, char *argv[]) {
int port;
if( argc != 2 ) {
printf(%s commport\n, argv[0]);
return -1;
}
port = open(argv[1], O_RDWR | O_NOCTTY | O_NONBLOCK);
if(port 0) {
printf(Port could not be opened.\n);
return -3;
}
setup_port(port);
write(port, hi, 2);
while(1) {
fd_set monitored_files;
struct timeval timeout;
FD_ZERO( monitored_files);
FD_SET(port, monitored_files);
timeout.tv_sec = 0;
timeout.tv_usec = 290;
//printf(Waiting\n);
if( select(port+1, monitored_files, NULL, NULL, timeout) = 0 ) {
continue;
}
printf(Got something 1!\n);
if( FD_ISSET(port, monitored_files) ) {
unsigned char inch;
printf(Performing read.\n);
read(port, inch, 1);
printf(Got %02x\n, inch);
}
}
close(port);
}
cygcheck.redacted.out
Description: Binary data
--
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: 1.5.18-1: undefined reference to `ffs' in mno-cygwin mode
While this isn't a Cygwin issue (you're using '-mno-cygwin'), Well, I never installed mingw separately. Is was a part of Cygwin installation, so I supposed it has some relation. :-) I'll try to ask mingw guys. This search: http://www.google.com/search?q=ffs+qemu leads to some links that look promising. First one (http://qemu-forum.ipi.fi/viewtopic.php?f=5t=4802) is mine. No replies yet. Some others were read before these posts. I did not find remedy. Thanks for bultin link, I'll investigate it... Dmitry -- 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/
Connecting to other PC's on a network using cygwin
Hi Im currently running cygwin on a windows pc on our company network. In windows to connect to a machine I can do \\pcname\c$ from the run command to view someone elses c: I am very new to cygwin and unix, is there a similair command that can be run from cygwin to view other pc's on the network in the same way? Thanks -- View this message in context: http://www.nabble.com/Connecting-to-other-PC%27s-on-a-network-using-cygwin-tp21606837p21606837.html Sent from the Cygwin list mailing list archive at Nabble.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: paste into vim
Dave Steenburgh wrote: On Wed, Jan 21, 2009 at 10:35 AM, Andrew DeFaria and...@defaria.com wrote: Dave Steenburgh wrote: On Tue, Jan 20, 2009 at 4:54 AM, Morche Matthias matthias.mor...@p7s1produktion.de wrote: or press Shift-Insert ... What about keyboards that don't have an insert key? (Unfortunately all too common these days.) I have yet to meet a keyboard that lacks one. Can you name a model? Well I see them all the time, including the one right in front of me: Logitech Y-SZ49. If you didn't get an insert key then you got ripped off however I think you may just be looking in the wrong place, By Logitiech Y-SZ49 did you mean this one: http://cafe.mobil.hr/showthread.php?t=49534 ? Because if you did I see an insert key there, right below prt scrn. -- Andrew DeFaria http://defaria.com I used up all my sick days, so now I'm calling in dead. -- 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: Problem using select() with com0com virtual serial ports
On Thu, Jan 22, 2009 at 10:25:32AM -0500, Paul Ingemi wrote: I'm using Cygwin with com0com, and I find that every other time I read a character from the virtual serial port, select() continues to believe the serial port is ready, but then read() will block until a character actually comes in. This does not happen with a real serial port. Attached below is a test program which exhibits the symptoms when used with com0com virtual serial ports. I worked around the problem by performing a second select() immediately after the first one returns with ready file descriptors. That second select determines which of these really are ready. Using strace and the source code for Cygwin, I worked with the author of com0com, Vyacheslav Frolov, to find a potential problem and solution. That thread is here: http://sourceforge.net/forum/forum.php?thread_id=2885701forum_id=440108 Vyacheslav suggests that initially peek_serial() returns because st.cbInQue is nonzero. However, since we didn't wait for a comm event, EV_RXCHAR is still set on the comm handle. The next time into select(), st.cbInQue is zero but WaitCommEvent succeeds immediately due to the previously set event. By clearing the comm event mask (and therefore the comm event) before setting it to EV_RXCHAR: select.cc function peek_serial(): ... SetCommMask (h, 0); // === added SetCommMask (h, EV_RXCHAR); ... This seems like a hack to me. I don't see anything in the MSDN documentation which would imply that SetCommMask (h, 0) should cause this type of behavior. Wouldn't the fact that this works for a regular serial driver imply that there is a problem with the com0com driver? It is a simple enough hack that I don't mind adding it, if it fixes your problem but I am not convinced that your driver is operating correctly. cgf -- 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: Connecting to other PC's on a network using cygwin
foulis wrote: Hi Im currently running cygwin on a windows pc on our company network. In windows to connect to a machine I can do \\pcname\c$ from the run command to view someone elses c: Cygwin uses //host/share syntax to do the same thing. I am very new to cygwin and unix, is there a similair command that can be run from cygwin to view other pc's on the network in the same way? I'd recommend reading through the Cygwin User's Guide: http://cygwin.com/cygwin-ug-net/ It will help answer allot of questions you will likely have. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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/
Problem accessing GRASS setup.ini file
Hi Mark Hello I am trying to download GRASS GIS software onto a windows laptop and am having some problems with downloading the setup file required from http://geni.ath.cx. I wonder if you can help me. When I come to the I need to select 2 sites - 1) any mirror site and 2) http://geni.ath.cx. The mirror site seems fine but I receive an error message 'unable to get setup.ini from http://geni.ath.cx/grass/setup.ini'. Therefore there seems to be a problem with my getting the correct access to the http://geni.ath.cx site. I would really appreciate any advice on how I would be able to resolve this. Many thanks Karen Weston University College London -- 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/
environment problems mixing mintty and xterm
I find mintty very useful. I can bring it up as a standalone window or I can run run additional windows from xterm running under X. If I do the latter then mintty inherits the environment from the xterm window I'm running, e.g., including additional path entries set in ~/.tcshrc, etc. However, if I run mintty from my xterm window I have some problems. For example, say I have open xterm (from startxwin.csh) with xterm +tb -j -sb -geometry 80x84-6+0 this sets LINES set to 84. If I have set up .minttyrc with Rows=100 then after I go to my mintty window and back to my xterm, my xterm window is messed up, e.g., top rows under `less` are off the screen. There is no such problem, when running xterm, if I open an additional mintty window as a Windows shortcut since it seems to open independently -- without taking on the environment variables in my xterm window. I guess it probably would increase the minimal nature of mintty to restore such environment variables when leaving a mintty window? Thanks. Lester -- 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: Problem accessing GRASS setup.ini file
Karen M Weston wrote: Hi Mark Hello I am trying to download GRASS GIS software onto a windows laptop and am having some problems with downloading the setup file required from http://geni.ath.cx. I wonder if you can help me. When I come to the I need to select 2 sites - 1) any mirror site and 2) http://geni.ath.cx. The mirror site seems fine but I receive an error message 'unable to get setup.ini from http://geni.ath.cx/grass/setup.ini'. Therefore there seems to be a problem with my getting the correct access to the http://geni.ath.cx site. I would really appreciate any advice on how I would be able to resolve this. If you're sure the problem is with a particular site, then contacting that site's owner is likely to be a more expedient solution. However, in this case, I suspect the problem is on your end since I was able to call up the file in my browser by clicking on its link. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: 1.5 / 1.7 setup.exe entanglement?
Corinna Vinschen wrote: Yes, the reason is that setup looks into c:\cygwin by default and if it finds setup files there, it will use them Thought so. A wishlist item, then: add something to 1.5's setup.exe to detect that c:\cygwin is from a later version, and refuse to use information found there. It should behave no differently in this case than installing Cygwin 1.5 on a fresh machine. On detecting this, it could also modify the default install location to c:\cygwin-1.5 or similar, on the theory that you probably don't want to overwrite the newer installation. Again, the reason to do this is that after 1.7 gets released, we'll probably still see a fair number of people having to install 1.5 alongside it, and you can't count on them to install 1.5 first, or go through the procedure you outlined to keep the installs disentangled. -- 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: Problem accessing GRASS setup.ini file
Larry Hall (Cygwin) wrote: Karen M Weston wrote: Hi Mark Hello I am trying to download GRASS GIS software onto a windows laptop and am having some problems with downloading the setup file required from http://geni.ath.cx. I wonder if you can help me. When I come to the I need to select 2 sites - 1) any mirror site and 2) http://geni.ath.cx. The mirror site seems fine but I receive an error message 'unable to get setup.ini from http://geni.ath.cx/grass/setup.ini'. Therefore there seems to be a problem with my getting the correct access to the http://geni.ath.cx site. I would really appreciate any advice on how I would be able to resolve this. If you're sure the problem is with a particular site, then contacting that site's owner is likely to be a more expedient solution. However, in this case, I suspect the problem is on your end since I was able to call up the file in my browser by clicking on its link. Yep, sounds like probably network/firewall/proxy problems at Karen's site to me. The GRASS mirror, of course, does not have a setup.ini.sig file, so if you're using a recent setup.exe, don't forget to add the -X command-line option to setup when installing from it. (Turns off signature verification, see ref [*] for full info). cheers, DaveK -- [*] - http://www.cygwin.com/ml/cygwin-announce/2008-08/msg1.html -- 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: 1.5 / 1.7 setup.exe entanglement?
On Jan 22 09:48, Warren Young wrote: Corinna Vinschen wrote: Yes, the reason is that setup looks into c:\cygwin by default and if it finds setup files there, it will use them Thought so. A wishlist item, then: add something to 1.5's setup.exe to detect that c:\cygwin is from a later version, and refuse to use information found there. That is an unsupported scenario. When 1.7 goes release, 1.5 will be left only as a courtesy to 9x users. There will be only one setup.exe binary. That setup.exe will install 1.7 on NT-based machines and 1.5 on 9x-based machines. You won't have the choice unless you use an old setup.exe... which is unsupported. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: paste into vim
Andrew DeFaria wrote: Dave Steenburgh wrote: On Wed, Jan 21, 2009 at 10:35 AM, Andrew DeFaria wrote: Dave Steenburgh wrote: On Tue, Jan 20, 2009 at 4:54 AM, Morche Matthias wrote: or press Shift-Insert ... What about keyboards that don't have an insert key? (Unfortunately all too common these days.) I have yet to meet a keyboard that lacks one. Can you name a model? Well I see them all the time, including the one right in front of me: Logitech Y-SZ49. If you didn't get an insert key then you got ripped off however I think you may just be looking in the wrong place, By Logitiech Y-SZ49 did you mean this one: http://cafe.mobil.hr/showthread.php?t=49534 ? Because if you did I see an insert key there, right below prt scrn. Nah, there's a different model where for some completely nutso reason they decided to get rid of the Ins. key so they could have a double-height Del. instead! http://www.mf-daten.de/catalog/images/b177.jpg OP will have to use the numpad Ins., I guess. cheers, DaveK -- 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: paste into vim
DaveK wrote: Nah, there's a different model where for some completely nutso reason they decided to get rid of the Ins. key so they could have a double-height Del. instead! Here's another such abomination, from the evil empire itself: http://www.itmedia.co.jp/news/0309/04/l_ms001.jpg Note how they've also relabeled all the F keys, with the proper labels relegated to the side of the keys. 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/
[OT] Re: 1.5.18-1: undefined reference to `ffs' in mno-cygwin mode
Dmitry Smirnov wrote: While this isn't a Cygwin issue (you're using '-mno-cygwin'), Well, I never installed mingw separately. Is was a part of Cygwin installation, so I supposed it has some relation. :-) Well, we give you a MinGW cross-compiler in the -mno-cygwin mode of gcc ... but we don't support MinGW programs that you write with it! I'll try to ask mingw guys. They're bound to know better than we do here what's the best way to fix it. This search: http://www.google.com/search?q=ffs+qemu leads to some links that look promising. First one (http://qemu-forum.ipi.fi/viewtopic.php?f=5t=4802) is mine. No replies yet. Some others were read before these posts. I did not find remedy. Thanks for bultin link, I'll investigate it... Talk to the MinGW guys, but the answer could be as simple as adding #if defined (__GNUC__) !defined (__OPTIMIZE__) #define ffs(x) __builtin_ffs ((x)) #endif ... to some appropriate header file. cheers, DaveK -- 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: ???????? owner and group
Corinna Vinschen wrote: Have a look into the ACL by using Windows Explorer properties/security dialog. What you see is thatthe user and group for a file on the share is Unix User\yourunixuser and Unix Group\yourunixgroup. These accounts are missing in your /etc/passwd and /etc/group files. Okay, that clears up the Samba side, but what about the local system files? $ getfacl /c/Windows/regedit.exe # file: /c/Windows/regedit.exe # owner: # group: user::rwx group::rwx group:root:r-x group:SYSTEM:r-x group:Users:r-x mask:rwx other:--- I re-ran mkpasswd with no flags, and got the same thing I have in /etc/passwd already. What you can do: - Add the Unix accounts to /etc/passwd and /etc/group, for instance: $ mkpasswd -L sambaserver,2 -U yourunixuser Unix User\yourunixuser:unused:21000:9:,S-1-22-1-1000:: $ mkgroup -L sambaserver -U yourunixgroup Unix Group\yourunixgroup:S-1-22-2-101:20101: - Change the cygdrive flags in /etc/fstab to noacl, which is equivalent to the old CYGWIN=nosmbntsec. These are alternatives, right, not two steps that both have to be done? I tried the second part first, figuring that I didn't mind the old nosmbntsec behavior -- all your files are belong to us -- but still got the question marks. Then I broke down and built up /etc/passwd and /etc/group until all the question marks over Samba went away, then removed the noacl option, restarted all Cygwin stuff, and the question marks are still gone. So, is noacl not doing what it's supposed to? If I change the cygdrive fstab entry to: none / cygdrive binary,posix=0,user,noacl 0 0 and restart all of Cygwin, I see: $ mount C:/cygwin/bin on /usr/bin type unknown (binary) C:/cygwin/lib on /usr/lib type unknown (binary) C:/cygwin on / type unknown (binary) C: on /c type ntfs (binary,posix=0,user,noumount) D: on /d type ntfs (binary,posix=0,user,noumount) T: on /t type smbfs (binary,posix=0,user,noumount) U: on /u type smbfs (binary,posix=0,user,noumount) V: on /v type smbfs (binary,posix=0,user,noumount) noacl doesn't appear in the mount flags. Is it incompatible with one of the others? -- 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: chere and mintty patch
Frank Fesevur wrote: Hereby a patch for chere to add support for MinTTY as well. Thanks Frank! I'll also look at adding support for dash, and anything else I've neglected for a while :) Dave. chere maintainer. -- 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: ???????? owner and group
On Jan 22 10:13, Warren Young wrote: Corinna Vinschen wrote: Have a look into the ACL by using Windows Explorer properties/security dialog. What you see is thatthe user and group for a file on the share is Unix User\yourunixuser and Unix Group\yourunixgroup. These accounts are missing in your /etc/passwd and /etc/group files. Okay, that clears up the Samba side, but what about the local system files? $ getfacl /c/Windows/regedit.exe # file: /c/Windows/regedit.exe # owner: # group: user::rwx group::rwx group:root:r-x group:SYSTEM:r-x group:Users:r-x mask:rwx other:--- I re-ran mkpasswd with no flags, and got the same thing I have in /etc/passwd already. Have another look into the ACL. For some reasons only the Microsoft developers know there's a new account called TrustedInstaller beginning with Vista, which is NOT listed by the account enumeration functions and which has a SID entirely differnt from your system's SID. Just ignore it. What you can do: - Add the Unix accounts to /etc/passwd and /etc/group, for instance: $ mkpasswd -L sambaserver,2 -U yourunixuser Unix User\yourunixuser:unused:21000:9:,S-1-22-1-1000:: $ mkgroup -L sambaserver -U yourunixgroup Unix Group\yourunixgroup:S-1-22-2-101:20101: - Change the cygdrive flags in /etc/fstab to noacl, which is equivalent to the old CYGWIN=nosmbntsec. These are alternatives, right, not two steps that both have to be done? Right. I tried the second part first, figuring that I didn't mind the old nosmbntsec behavior -- all your files are belong to us -- but still got the question marks. Then I broke down and built up /etc/passwd and /etc/group until all the question marks over Samba went away, then removed the noacl option, restarted all Cygwin stuff, and the question marks are still gone. So, is noacl not doing what it's supposed to? If I change the cygdrive fstab entry to: none / cygdrive binary,posix=0,user,noacl 0 0 and restart all of Cygwin, I see: $ mount C:/cygwin/bin on /usr/bin type unknown (binary) C:/cygwin/lib on /usr/lib type unknown (binary) C:/cygwin on / type unknown (binary) C: on /c type ntfs (binary,posix=0,user,noumount) D: on /d type ntfs (binary,posix=0,user,noumount) T: on /t type smbfs (binary,posix=0,user,noumount) U: on /u type smbfs (binary,posix=0,user,noumount) V: on /v type smbfs (binary,posix=0,user,noumount) Please not that mapping the cygdrive prefix to / is NOT supported. If something doesn't work as expected, it serves you right and it's all your own fault and you have been warned and and all that. My personal cygdrive prefix is /mnt for historical reasons. noacl doesn't appear in the mount flags. Is it incompatible with one of the others? Works fine for me. Changes in fstab only have an effect if really *all* of your Cygwin processes stopped. If you want a temporary effect in your current session without having to stop all Cygwin processes, use the mount command (for instance `mount -f -c /mnt -o posix=0,noacl'). See the user's guide under http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html and http://cygwin.com/1.7/cygwin-ug-net/using-utils.html#mount Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: chere and mintty patch
Dave wrote on Thursday, January 22, 2009 1:36 PM: Frank Fesevur wrote: Hereby a patch for chere to add support for MinTTY as well. Thanks Frank! I'll also look at adding support for dash, and anything else I've neglected for a while :) Dave. chere maintainer. I don't believe that currently dash is a package. Might someone package it? Personally, I think that a fully documented minimal shell like dash would be a good replacement for or supplement to ash. But note that I cannot volunteer*, am not making a request, and do not expect a follow-up to this email. (*I'm not a programmer.) And thanks, as always, to all the maintainers, developers and other Contributors to cygwin. We freeloaders appreciate your work. :-) - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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: chere and mintty patch
Buchbinder, Barry (NIH/NIAID) [E] wrote: Dave wrote on Thursday, January 22, 2009 1:36 PM: Frank Fesevur wrote: Hereby a patch for chere to add support for MinTTY as well. Thanks Frank! I'll also look at adding support for dash, and anything else I've neglected for a while :) I don't believe that currently dash is a package. Might someone package it? Sorry, I meant posh. I knew I'd seen an announcement for another shell a while back and assumed it had been dash. Dave. -- 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: environment problems mixing mintty and xterm
Lester Ingber wrote: However, if I run mintty from my xterm window I have some problems. For example, say I have open xterm (from startxwin.csh) with xterm +tb -j -sb -geometry 80x84-6+0 this sets LINES set to 84. If I have set up .minttyrc with Rows=100 then after I go to my mintty window and back to my xterm, my xterm window is messed up, e.g., top rows under `less` are off the screen. There is no such problem, when running xterm, if I open an additional mintty window as a Windows shortcut since it seems to open independently -- without taking on the environment variables in my xterm window. Thanks for the problem report, although I'd prefer to get these via the issue tracker at http://code.google.com/p/mintty/issues/ . Unfortunately I haven't been able to reproduce the problem. A Unix process only receives copies of its parent's environment variables and it cannot change the originals, so the problem isn't caused that way. Window size changes are signalled to the child process through a call to ioctl() on the child's pseudo terminal (pty), which triggers a SIGWINCH signal in any processes controlled by that pty. Perhaps something is going awry there. Does the LINES variable in the xterm change immediately after invoking mintty, when you change mintty's size, or only after exiting it? What command line are you invoking mintty with? 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: Signal handling in WIN32 console programs
avade...@certicom.com wrote: My WIN32 app is compiled under vc7 and uses signal() to trap SIGINT, SIGABRT and SIGTERM. If I run the application under console2 or a native terminal, pressing ^C triggers the handler and the application stops programmatically due to a state change made by the handler. When I do the same under rxvt (not the X based one) or minTTY, the ^C stops the process without the signal handler executing. Similarly, even when run from the native console, kill (-INT, -ABRT, -TERM) causes the application to end without the handler catching the signal. So I wonder if the native console passes the character to the process directly whereas the minTTY/rxvt shells interpret it and send a signal that the native app doesn't really understand properly. MinTTY and rxvt do not interpret the ^C keypress in any special way. They simply write a ^C (0x03) character to the child process' pty. The pty driver may translate that into a signal depending on the pty's line settings (as shown by stty). Sorry I don't know how ^C is processed in a Windows console or why the behaviour would be different with ptys. 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: Signal handling in WIN32 console programs
On Thu, Jan 22, 2009 at 09:58:08PM +, Andy Koppe wrote: avade...@certicom.com wrote: My WIN32 app is compiled under vc7 and uses signal() to trap SIGINT, SIGABRT and SIGTERM. If I run the application under console2 or a native terminal, pressing ^C triggers the handler and the application stops programmatically due to a state change made by the handler. When I do the same under rxvt (not the X based one) or minTTY, the ^C stops the process without the signal handler executing. Similarly, even when run from the native console, kill (-INT, -ABRT, -TERM) causes the application to end without the handler catching the signal. So I wonder if the native console passes the character to the process directly whereas the minTTY/rxvt shells interpret it and send a signal that the native app doesn't really understand properly. MinTTY and rxvt do not interpret the ^C keypress in any special way. They simply write a ^C (0x03) character to the child process' pty. The pty driver may translate that into a signal depending on the pty's line settings (as shown by stty). Sorry I don't know how ^C is processed in a Windows console or why the behaviour would be different with ptys. The operative term here is, once again, Windows Console. A pure Windows program running in MinTTY or rxvt does not have a windows console and so won't see the type of SIGINT that the windows console generates. cgf -- 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: Status of Compatibility with Windows Server 2008 (2k8)
Perhaps it's bad form to reply to my own message, but I've got the 2k8 installation (x86) up and running and I'm ready to take the plunge and report back on what works and what doesn't work. Should I use the 1.5 release on the main page, or use the 1.7 release (setup-1.7.exe)? Alternatively, should I not even bother because it is known that Win2k8 and Cygwin just don't play well together? ~Oren PS. If the lack of reply to my previous question was due to some failure on my part, I'm quite sorry. I did check the FAQ and the archives of this list for any information in Cygwin's relationship with Win2k8. Google was also rather unhelpful in finding up-to-date information. On Thu, Jan 22, 2009 at 10:16 AM, Oren Elrad orenel...@gmail.com wrote: Hello, I am considering upgrading my 2k3 installation to 2k8. I currently use cygwin for basic utilities: mainly lighthttpd, sshd and rsync (and the relative pleasure of using bash instead of cmd). Could someone on this list give me an idea of what kind of issues to expect in the transition? I read through the archives and there are a few issues but those seem to be dated from 2007 and earlier. -Oren PS. The compiled answer could perhaps go into the FAQ for future use. Keywords: Windows Server 2008, Windows Server 2k8 -- Oren The avoidance of taxes is the only intellectual pursuit that carries any reward. ~John Maynard Keynes Violence can only be concealed by a lie, and the lie can only be maintained by violence. Any man who has once proclaimed violence as his method is inevitably forced to take the lie as his principle. ~Alexander Solzhenitsyn Among the many misdeeds of the British rule in India, history will look upon the act depriving a whole nation of arms as the blackest. ~Mohandas Gandhi We will bankrupt ourselves in the vain search for absolute security. ~Dwight D. Eisenhower -- 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: Signal handling in WIN32 console programs
On Thu, Jan 22, 2009 at 05:04:23PM -0500, Christopher Faylor wrote: On Thu, Jan 22, 2009 at 09:58:08PM +, Andy Koppe wrote: avade...@certicom.com wrote: My WIN32 app is compiled under vc7 and uses signal() to trap SIGINT, SIGABRT and SIGTERM. If I run the application under console2 or a native terminal, pressing ^C triggers the handler and the application stops programmatically due to a state change made by the handler. When I do the same under rxvt (not the X based one) or minTTY, the ^C stops the process without the signal handler executing. Similarly, even when run from the native console, kill (-INT, -ABRT, -TERM) causes the application to end without the handler catching the signal. So I wonder if the native console passes the character to the process directly whereas the minTTY/rxvt shells interpret it and send a signal that the native app doesn't really understand properly. MinTTY and rxvt do not interpret the ^C keypress in any special way. They simply write a ^C (0x03) character to the child process' pty. The pty driver may translate that into a signal depending on the pty's line settings (as shown by stty). Sorry I don't know how ^C is processed in a Windows console or why the behaviour would be different with ptys. The operative term here is, once again, Windows Console. A pure Windows program running in MinTTY or rxvt does not have a windows console and so won't see the type of SIGINT that the windows console generates. Is there something that I could do inside the native application code to catch what it is getting? I've tried SetConsoleCtrlhandler, but that also never gets invoked prior to the process termination. cgf -- 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: Status of Compatibility with Windows Server 2008 (2k8)
Oren Elrad wrote: Perhaps it's bad form to reply to my own message, but I've got the 2k8 installation (x86) up and running and I'm ready to take the plunge and report back on what works and what doesn't work. Should I use the 1.5 release on the main page, or use the 1.7 release (setup-1.7.exe)? Alternatively, should I not even bother because it is known that Win2k8 and Cygwin just don't play well together? ~Oren PS. If the lack of reply to my previous question was due to some failure on my part, I'm quite sorry. I did check the FAQ and the archives of this list for any information in Cygwin's relationship with Win2k8. Google was also rather unhelpful in finding up-to-date information. There have been some reports here on Cygwin and W2K8, though generally none that I recall suggest any major issue with W2K8. Since I don't use W2K8, I can't say whether 1.5 or 1.7 would work better there. It depends on your needs. 1.7 is definitely where things are headed and should give you a better experience overall, especially for things like sshd that wants to change users (see /usr/share/doc/Cygwin/openssh.readme and/or http://cygwin.com/ml/cygwin-developers/2006-11/msg0.html). If you're up to using beta software, I'd recommend trying that. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: python 2.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jason Tishler wrote: Yaakov, did you have openssl-devel installed when you built Python 2.6.1? Yes, that is clearly indicated in the documentation. If so, are you able to run the regression test [2] without threading related problems? Testing it now, I'm seeing the same results as you. What exactly is the correlation between openssl and threads? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkl5L18ACgkQpiWmPGlmQSNQCwCgqvnUS6l7YJH90YdPtYdoiNUU h9oAnj7Suwd3Ypk4OAo9x0945BrchzR2 =eDG1 -END PGP SIGNATURE- -- 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/
Nedit text plane inoperable.
Hello, I've been successfully using Nedit on Cygwin for several years. Today, I did a fresh Cygwin install and Nedit no longer works properly. Now Nedit starts up just like it always did in the past, but the text plane is inoperable. I am able to read the document, and the document is not in read only state. When I click on the text plane, nothing happens. Normally a cursor would appear. Menu items popup when I click on them, but I cannot type characters in the dialog boxes. When I swap my cygwin directory with a previous install, everything works fine. I'm using the following: Xming (6-9-0-31) as my X server Windows XP Professional SP2 Anyone else experiencing these problems? Thanks, -Bill -- 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: Nedit text plane inoperable.
Thanks. -Original Message- From: Larry Hall (Cygwin) [mailto:reply-to-list-only...@cygwin.com] Sent: Thursday, January 22, 2009 11:43 PM To: WEEBER Bill Subject: Re: Nedit text plane inoperable. WEEBER Bill wrote: Hello, I've been successfully using Nedit on Cygwin for several years. Today, I did a fresh Cygwin install and Nedit no longer works properly. Now Nedit starts up just like it always did in the past, but the text plane is inoperable. I am able to read the document, and the document is not in read only state. When I click on the text plane, nothing happens. Normally a cursor would appear. Menu items popup when I click on them, but I cannot type characters in the dialog boxes. When I swap my cygwin directory with a previous install, everything works fine. I'm using the following: Xming (6-9-0-31) as my X server Windows XP Professional SP2 Anyone else experiencing these problems? Try the the cygwin-xfree list. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Nedit text plane inoperable.
Hello, I've been successfully using Nedit on Cygwin for several years. Today, I did a fresh Cygwin install and Nedit no longer works properly. Now Nedit starts up just like it always did in the past, but the text plane is inoperable. I am able to read the document, and the document is not in read only state. When I click on the text plane, nothing happens. Normally a cursor would appear. Menu items popup when I click on them, but I cannot type characters in the dialog boxes. When I swap my cygwin directory with a previous install, everything works fine. I'm using the following: Xming (6-9-0-31) as my X server Windows XP Professional SP2 Anyone else experiencing these problems? Thanks, -Bill -- 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: Nedit text plane inoperable.
Oops, Sent this to wrong mail list. Sorry:) -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of WEEBER Bill Sent: Friday, January 23, 2009 12:06 AM To: cygwin@cygwin.com Subject: RE: Nedit text plane inoperable. Hello, I've been successfully using Nedit on Cygwin for several years. Today, I did a fresh Cygwin install and Nedit no longer works properly. Now Nedit starts up just like it always did in the past, but the text plane is inoperable. I am able to read the document, and the document is not in read only state. When I click on the text plane, nothing happens. Normally a cursor would appear. Menu items popup when I click on them, but I cannot type characters in the dialog boxes. When I swap my cygwin directory with a previous install, everything works fine. I'm using the following: Xming (6-9-0-31) as my X server Windows XP Professional SP2 Anyone else experiencing these problems? Thanks, -Bill -- 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/
