Re: launch server x without startx command
Alexis Cothenet wrote: I have seen http://www.cygwin.com/ml/cygwin-xfree/2004-01/msg00476.html ( tried with my own ip) but it doesn't work for me. i'm working with tcsh shell. Maybe there is a place where i could launch the startx script ? I took a slightly different route that either of those posters did. The end result should be the same, but it's still worth a try, since you seem to be able to run startx once you have a POSIX shell. My system has c:\cygwin\bin;c:\cygwin\usr\X11R6\bin at the end of $PATH$, and I simply stuck a shortcut to 'sh startx' in the default user's startup folder. As long as startx works on your system, this should too, since it's simply automating the invocation of the startx shell script. This should work in user-specific environment variables and startup folders too, and if you don't want to edit your Windows path variable, prefixing the Windows path to bin/sh to the shortcut should produce the same end result as well.
Launching an X app and getting access to the local (win32) drives
This is a newbie question I have RH8 installed (actually in a VM under VMWare) and have installed the cygwin/X on a Windows 2000 Pro box. After some work getting the X configuration setup properly, from the cygwin bash shell, I am able to telnet into my linux box, export the display, and run all of the X apps correctly on the win32 machine. Before telnetting into linux, the bash shell can see the local win32 drives, but the telnet session (and the X application) can only see file space on the linux machine. How do I make the local win32 drives available to the X application? Thanks for any help Steve
Re: Launching an X app and getting access to the local (win32) drives
On Thu, 17 Feb 2005, Steve wrote: This is a newbie question I have RH8 installed (actually in a VM under VMWare) and have installed the cygwin/X on a Windows 2000 Pro box. After some work getting the X configuration setup properly, from the cygwin bash shell, I am able to telnet into my linux box, export the display, and run all of the X apps correctly on the win32 machine. Before telnetting into linux, the bash shell can see the local win32 drives, but the telnet session (and the X application) can only see file space on the linux machine. How do I make the local win32 drives available to the X application? export the drives as windows shares and use samba to access them. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Problem with the cygwin5A
[EMAIL PROTECTED] wrote: Hi Alexander, MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 040C (040c) (--) Using preset keyboard for French (Standard) (40c), type 4 (--) 3 mouse buttons found Could not init font path element /usr/X11R6/lib/X11/fonts/TTF/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/Type1/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/100dpi/, removing from list! With normal invocation a lot more should follow. Please try XWin -clipboard -multiplemonitors -rootless -kb If this works, you are most likely suffering from an incompatibility with personal firewalls. bye ago NP: Terminal Choice - Black Dressed Woman -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
src/winsup/cygwin ChangeLog times.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-02-17 12:08:17 Modified files: winsup/cygwin : ChangeLog times.cc Log message: * times.cc (utimes): Open files with FILE_WRITE_ATTRIBUTES first, if that fails, try opeing with GENERIC_WRITE. Fix comments. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2713r2=1.2714 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/times.cc.diff?cvsroot=srcr1=1.58r2=1.59
src/winsup/cygwin ChangeLog fhandler_disk_file.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-02-17 12:41:49 Modified files: winsup/cygwin : ChangeLog fhandler_disk_file.cc Log message: * fhandler_disk_file.cc (fhandler_disk_file::fstat): Set st_ctime if has_changed flag is set. (fhandler_disk_file::touch_ctime): Reset has_changed flag on success. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2714r2=1.2715 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.101r2=1.102
winsup/cygwin ChangeLog path.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2005-02-17 17:21:11 Modified files: cygwin : ChangeLog path.cc Log message: * path.cc (path_conv::check): Set fs flag when a unix-domain socket is detected. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.2715r2=1.2716 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/path.cc.diff?cvsroot=uberbaumr1=1.347r2=1.348
Copyright Assignment received from Yitzchak Scott-Thoennes
Patch as patch can, Yitzchak! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: patch to allow touch to work on HPFS (and others, maybe??)
On Feb 14 23:59, Eric Blake wrote: Corinna Vinschen vinschen at redhat.com writes: I guess trying my approach isn't the worst one, though. We should use that as a start point for further experimenting, IMHO. I'll check that in. Checking win32.has_acls() and using GENERIC_WRITE caused a regression in utimes (). The new upstream automake-1.9.5 tarball contains a read-only file (mode 0444). Before the 20050211 snapshot, when utimes() is still using FILE_WRITE_ATTRIBUTES, tar does just fine at adjusting the timestamp of that file when unpacking to an NFS-mounted directory. However, with the current code, when I tried to unpack, tar is no longer able to touch the timestamps of the read-only file because GENERIC_WRITE requires write access for at least one of user, group, and other, even though touching the timestamp does not. Too bad. I'll change the code to try FILE_WRITE_ATTRIBUTES first and GENERIC_WRITE only if that fails. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Bug in 'find' 4.2.11-CVS when traversing NTFS mount points
I'm experiencing a problem with 'find' when mounted NTFS volumes (junctions) are involved. I have created a sample directory structure /cygdrive/c/aa/aa where 'aa' is the mount point for another NTFS drive. From DOSland it looks like this: C:\ dir \aa Directory of C:\aa 2005/02/17 00:35 DIR . 2005/02/17 00:35 DIR .. 2005/02/17 00:35 JUNCTION aa The problem behavior with find is that these command works: $ find /cygdrive/c/aa -name @@@F\* /cygdrive/c/aa/aa/@@@FindMeFirst $ find /cygdrive/c/aa/aa -name @@@F\* /cygdrive/c/aa/aa/@@@FindMeFirst but this gets errors and @@@FindMeFirst is not found: $ find /cygdrive/c -name @@@F\* find: Filesystem loop detected; `/cygdrive/c/aa/aa' has the same device number and inode as a directory which is 2 levels higher in the filesystem hierarchy. I tried with CYGWIN=smbntsec and CYGWIN unset and the behavior was the same. Volumes mounted on a root folder (e.g. C:\mnt) get the same error except for ...which is 1 level higher __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com Cygwin Configuration Diagnostics Current System Time: Thu Feb 17 01:32:07 2005 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: .\ c:\Home\TravelPak\script c:\home\cygwinhome\Administrator\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\EDA_tools\Modeltech_6.0c\win32pe c:\EDA_tools\Xilinx\bin\nt c:\WINNT\system32 c:\WINNT c:\WINNT\System32\Wbem c:\bin c:\bat c:\borland\bcc55\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 500(Administrator) GID: 513(None) 513(None) Output from C:\cygwin\bin\id.exe (ntsec) UID: 500(Administrator) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINNT\system32 WinDir: C:\WINNT HOME = `c:\home\cygwinhome\Administrator' MAKE_MODE = `unix' PWD = `/home/Administrator' USER = `Administrator' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\Administrator\Application Data' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `MARMOT1' COMSPEC = `C:\WINNT\system32\cmd.exe' CYGWIN = `smbntsec' DESK = `/c/Documents and Settings/Administrator/Desktop' DIRSPATH = `/home/Administrator' DISPLAY = `127.0.0.1:0.0' GROUP = `None' HID = `78F6' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\Administrator' HOST = `marmot1' HOSTTYPE = `i386' LESS = `-E -F -X' LOGNAME = `Administrator' LOGONSERVER = `\\MARMOT1' MACHTYPE = `i386' MANPATH = `/usr/autotool/devel/share/man:/usr/man:/usr/share/man:/usr/share/TeXmacs/plugins/r/r/TeXmacs/man:/usr/share/xemacs/mule-packages/man:/usr/share/xemacs/xemacs-packages/man:/usr/ssl/man:/usr/X11R6/man:/usr/X11R6/share/man' MG_MODEL_REV = `r0' MULTIMON = `1' NUMBER_OF_PROCESSORS = `1' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' OSTYPE = `posix' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PID_Path = `/cygdrive/z' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' PRINTER = `LPT1:' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 2 Stepping 1, AuthenticAMD' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0201' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' QESS_PLATFORM = `bin' QESS_ROOTDIR = `C:\EDA_tools\altera\quartus42' QUARTUS_ROOTDIR = `C:\EDA_tools\altera\quartus42' RESETNAME = `Reset' RESETPOLARITY = `1' SHELL = `/usr/bin/tcsh' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' ScreenSize = `1280x1024' TERM = `cygwin' TZ = `PST8PDT7,M4.1.0/2,M10.5.0/2' TravelPakPath = `/c/Home/TravelPak/' USERDOMAIN = `MARMOT1' USERNAME = `Administrator' USERPROFILE = `C:\Documents and Settings\Administrator' VENDOR = `intel' WHERE_AM_I = `marmot' WHICH_OS = `cygwin' WINDIR = `C:\WINNT' XSERVER = `none' hn = `m' nedit_winsize = `80x71' neditmem = `on' neditpurge = `on' xterm_bigwinsize = `160x56' xterm_winsize = `80x56' 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\mounts v2 C__EDA_tools_altera_quartus42_bin_cygwin_bin_cygwin1_dll 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
Re: snapshots are breaking shred
On Feb 14 21:19, Eric Blake wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: With coreutils 5.3.0-2 and various snapshots, I am seeing regressions in shred(1)caused by cygwin changes: As far as fsync is affected, I don't see how that could ever fail, except the Windows call fails for some reason. The fsync code hasn't changed for quite some time. I found what is causing this. Coreutils shred uses the following code: int dir_fd = open (dir, O_WRONLY | O_NOCTTY); So it tries to open directories for writing despite of POSIX not allowing this? How weird. POSIX requires that open fail with EISDIR on open with O_WRONLY or O_RDWR on a directory, and you implemented that in a patch on Jan 6. So with 1.5.12, shred got a writeable fd from the first open, but with snapshots after Jan 6 it has only a readable fd from the second open. But fsync() is implemented with FlushFileBuffers, which requires write access to the handle it is about to flush, so it now fails with EACCES. I don't know if it is better to patch open_fs() to additionally grant GENERIC_WRITE access when opening directories as O_RDONLY (since that is the only way to open a directory), or to patch fsync() to temporarily grant write access to a directory for the duration of the flush. But it is a definite regression from 1.5.12 that should be fixed. I also think that fsync() could be patched to return EINVAL on non-directory file descriptors that were opened as O_RDONLY, rather than performing a failed FlushFileBuffers and getting EACCES, as a closer match to the errors allowed by POSIX. http://www.opengroup.org/onlinepubs/009695399/functions/fsync.html I'm pretty busy with non-Cygwin stuff at the moment. But you know, http://cygwin.com/acronyms/#PTC . Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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: more ctime bugs
On Feb 13 04:30, Eric Blake wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: I'll update Cygwin to set ctime in close and link. Link is special since it doesn't involve using any explicit file descriptors, so it's a bit unclear where to set the flags inside Cygwin to get that right. Using close() seems a good way to have ctime set for write() as well as open(O_TRUNC). I see the new has_changed flag in the 20050211 snapshot. But you still have to add a call to touch_ctime() within the stat() family of calls if has_changed is set, in order to comply with the required semantics; stat and lstat are not allowed to return out-of-date timestamps. You know that this contradicts the target to maintain speed on write? It's not done with adding a call to touch_ctime() to fstat, because that only affects the application which also has written to the file. If I read SUSv3 correctly, any call to stat/fstat/lstat on the file by any application would require to update the timestamp. That's no fun. I'm willing to simply ignore this. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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: more ctime bugs
On Feb 17 13:31, Corinna Vinschen wrote: On Feb 13 04:30, Eric Blake wrote: I see the new has_changed flag in the 20050211 snapshot. But you still have to add a call to touch_ctime() within the stat() family of calls if has_changed is set, in order to comply with the required semantics; stat and lstat are not allowed to return out-of-date timestamps. You know that this contradicts the target to maintain speed on write? It's not done with adding a call to touch_ctime() to fstat, because that only affects the application which also has written to the file. If I read SUSv3 correctly, any call to stat/fstat/lstat on the file by any application would require to update the timestamp. That's no fun. I'm willing to simply ignore this. I've called touch_ctime in fstat nevertheless. It's a first approximation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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: cygwin bughunt (Jip-hee!)
Christopher Faylor wrote: Actually, we do. We provide the source code. It's easy to build. You are right; I was wrong. Building Cygwin is easy. (At least when it comes to newer versions :-p.) It even compiles under itself. *impressed*. It's been a few weeks, and I've tested with the debug version. Seems that it's hanging in some pipe related stuff, see GDB output further down. Other peculiarities noted: 1. When listing processes with PS, the hung process has the 'WINPID' in the cygwin PID column instead of the cyg PID. 2. The problem seems to only occur on one machine, which happens to be multi-processor (2*Xeon). At least it occurs very frequently on this box. I've seen a hang once on a UP machine. I tried to find more information about the process using Process Explorer, which seemingly triggers another strange condition - the CPU time of the process shot to 100%. It was looping in ntdll.dll!RtlConvertUiListToApiList+0x2fd. Here's backtraces from GDB (snipped a bit here and there). core dump 1 (gdb) info threads 3 process 3620 0x77e88785 in KERNEL32!GetModuleFileNameA () 2 process 4236 0x77f839eb in ntdll!ZwReadFile () * 1 process 3832 0x77f8376e in ntdll!ZwClose () (gdb) bt #0 0x77f8376e in ntdll!ZwClose () #1 0x77e87738 in KERNEL32!CloseHandle () #2 0x61073b16 in fhandler_pipe::close() (this=0x616d15f0) --- at ../../../../winsup/cygwin/pipe.cc:103 #3 0x6109ac34 in close (fd=5) at winsup/cygwin/cygheap.h:304 #4 0x6108db7f in _sigfe () at winsup/cygwin/cygserver.h:82 = core dump 2 (gdb) info threads 3 process 4496 0x77e88785 in KERNEL32!GetModuleFileNameA () 2 process 3796 0x77f839eb in ntdll!ZwReadFile () * 1 process 1528 0x77f8376e in ntdll!ZwClose () (gdb) bt #0 0x77f8376e in ntdll!ZwClose () #1 0x77e87738 in KERNEL32!CloseHandle () #2 0x61073b16 in fhandler_pipe::close() (this=0x616d0fd8) --- at ../../../../winsup/cygwin/pipe.cc:103 #3 0x6109ac34 in close (fd=5) at winsup/cygwin/cygheap.h:304 #4 0x6108db7f in _sigfe () at winsup/cygwin/cygserver.h:82 = core dump 3 (gdb) info threads 3 process 2424 0x77e88785 in KERNEL32!GetModuleFileNameA () 2 process 4568 0x77f839eb in ntdll!ZwReadFile () * 1 process 4540 0x77f8376e in ntdll!ZwClose () (gdb) bt #0 0x77f8376e in ntdll!ZwClose () #1 0x77e87738 in KERNEL32!CloseHandle () #2 0x61073b16 in fhandler_pipe::close() (this=0x616d15f0) --- at ../../../../winsup/cygwin/pipe.cc:103 #3 0x6109ac34 in close (fd=5) at winsup/cygwin/cygheap.h:304 #4 0x6108db7f in _sigfe () at winsup/cygwin/cygserver.h:82 = The test were performed with 1.5.10-3, as newer versions call upon me all sorts of other problems and thus can't be pushed to the failing box right now. Btw, I urge everyone to try the latest cygwin snapshot! Will do. Has the problem been found that results in this error?: *** MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 -- 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: cygwin bughunt (Jip-hee!)
On Thu, Feb 17, 2005 at 02:23:42PM +0100, David Dindorp wrote: Christopher Faylor wrote: Actually, we do. We provide the source code. It's easy to build. You are right; I was wrong. Building Cygwin is easy. (At least when it comes to newer versions :-p.) It even compiles under itself. *impressed*. It's been a few weeks, and I've tested with the debug version. Er, who are you? **cgf checks archives Ah, yes! You're the you don't want people to debug cygwin because you aren't spoon feeding me debugging information guy! You're the guy who insisted on dropping back to 1.5.10! I remember now! In the future, please provide more context if you really want to be helped, especially after almost a month of silence. The test were performed with 1.5.10-3, as newer versions call upon me all sorts of other problems and thus can't be pushed to the failing box right now. Btw, I urge everyone to try the latest cygwin snapshot! Will do. Has the problem been found that results in this error?: *** MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 1) Regardless of whether the new versions call upon (you) all sorts of other problems, I doubt that anyone is going to spend any time tracking down problems in older versions. 2) You can *try* a snapshot to see if it fixes your problem. 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/
file globbing
I've recently noticed a problem with Cygwin ls. I did a quick search of the archives, but didn't get any hits. Has anyone else seen this? Try: ls -dl ../tcl[7-9]* Result on Linux: ../tcl ../tcl8 Result on Cygwin: ../tcl8 That is, on Cygwin tcl[7-9]* does not match tcl. I think it should. I have upgraded to the latest coreutils and still see the problem. Comments? Jim. -- James Lemke [EMAIL PROTECTED] Orillia, Ontario 1992 ST1100, STOC #3750; FWD# M:245401 H:246889 Life is what happens to you while you're busy making other plans. --John Lennon -- 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: file globbing
I've recently noticed a problem with Cygwin ls. I did a quick search of the archives, but didn't get any hits. Has anyone else seen this? Try: ls -dl ../tcl[7-9]* Result on Linux: ../tcl ../tcl8 Result on Cygwin: ../tcl8 That is, on Cygwin tcl[7-9]* does not match tcl. I think it should. I have upgraded to the latest coreutils and still see the problem. Comments? Which version of linux? What versions of ls and [insert shell] are you using on both? My Debian (testing) box matches Cygwin functionality... J. -- 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: file globbing
On Thu, 17 Feb 2005, James Lemke wrote: I've recently noticed a problem with Cygwin ls. I did a quick search of the archives, but didn't get any hits. Has anyone else seen this? Try: ls -dl ../tcl[7-9]* Result on Linux: ../tcl ../tcl8 Result on Cygwin: ../tcl8 That is, on Cygwin tcl[7-9]* does not match tcl. I think it should. I have upgraded to the latest coreutils and still see the problem. Comments? You were looking in the wrong place. Globbing is done by the shell. Most likely it's bash. Check your bash versions on both Cygwin and Linux. Also, check the shell settings (shopt). FWIW, * in bash usually means anything, not any number of occurrences of the previous expression (i.e., globs aren't regular expressions). But YMMV. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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: file globbing
On Thu, 2005-02-17 at 10:50, Igor Pechtchanski wrote: On Thu, 17 Feb 2005, James Lemke wrote: I've recently noticed a problem with Cygwin ls. I did a quick search of the archives, but didn't get any hits. Has anyone else seen this? Try: ls -dl ../tcl[7-9]* Result on Linux: ../tcl ../tcl8 Result on Cygwin: ../tcl8 That is, on Cygwin tcl[7-9]* does not match tcl. I think it should. I have upgraded to the latest coreutils and still see the problem. Comments? You were looking in the wrong place. Globbing is done by the shell. Most likely it's bash. Check your bash versions on both Cygwin and Linux. Also, check the shell settings (shopt). FWIW, * in bash usually means anything, not any number of occurrences of the previous expression (i.e., globs aren't regular expressions). But YMMV. Igor Ahem... sorry. I'm mistaken. It doesn't match ../tcl (in bash) on either Linux or Cygwin, and it shouldn't. The configure problem I'm looking at is something else. You may now return to your regularly scheduled programming. -- James Lemke [EMAIL PROTECTED] Orillia, Ontario 1992 ST1100, STOC #3750; FWD# M:245401 H:246889 Life is what happens to you while you're busy making other plans. --John Lennon -- 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/
Win32 Question
Sorry, I know this is a pretty odd question to ask in a forum like this, but I'm hoping someone can help. Basically, I would like to write a GUI (using Delphi Win32) for a Win32 console program. I had hoped I could read and write to the console program using pipes. However it appears that you cannot read the program's stdout through a pipe (stderr works fine). When I try to run it in the MingW32 console, it appears to hang. Clearly MingW32 is falling foul of the same pipes problem as I am. What's puzzling me is that the Cygwin console *isn't* bothered by this problem. The program's output appears fine, as if it was running in cmd.exe. Does anyone know what the Cygwin console is doing differently that allows it to read and display the program's stdout when MingW32 and my app fail? I think the program in question uses multi-threading, though I'm not sure how that would affect things. Thanks -- Bryan -- 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: file globbing
On Thu, 17 Feb 2005, James Lemke wrote: Date: Thu, 17 Feb 2005 10:31:37 -0500 From: James Lemke [EMAIL PROTECTED] To: cygwin@cygwin.com Subject: file globbing I've recently noticed a problem with Cygwin ls. I did a quick search of It's not ls that does the globbing. That is done by the shell before it runs ls. the archives, but didn't get any hits. Has anyone else seen this? Try: ls -dl ../tcl[7-9]* Result on Linux: ../tcl ../tcl8 Result on Cygwin: ../tcl8 That is, on Cygwin tcl[7-9]* does not match tcl. I think it should. It should not. Shell regular expressions for globbing filenames are not the same as normal regular expressions. [7-9]* does not mean ``zero or more occurences of a character in the 7-9 class'' it means ``exactly one occurence of 7, 8 or 9 followed by zero or more characters''. Not sure what is going on with the Linux example. If you are investigating glob behavior, try using echo rather than ls: echo ../tcl[7-9]* If there is any confusion about what is being matched due to leading, trailing or embedded whitespace, try this: for x in pattern; do echo $x; done Then you get each matching name, in angle braces, on a separate line. I have upgraded to the latest coreutils and still see the problem. Comments? The only apparent problem is on the Linux side, where a pattern that calls for a digit in the range 7-8 seems to be matching a name that contains no such thing. It does look like the shell you are using on Linux is interpreting the pattern as a full regular expression. -- Meta-CVS: the working replacement for CVS that has been stable since 2002. It versions the directory structure, symbolic links and execute permissions. It figures out renaming on import. Plus it babysits the kids and does light housekeeping! http://freshmeat.net/projects/mcvs -- 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/
gmake -r -p -n problem on fast computers: erroneous thread activa tion
Hi, I have problems with gmake on the new computers I use (and not with the same Cygwin version with older computers). I do gmake -r -p -n and parse the output to get some variables content. The problem occurs when a variable is computed using the $(shell ...) command. I shortened the makefile and wrote a small script that shows the problem. Use example (put test.mk and run_test_simple.csh at the same place): run_test_simple.csh 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 1 [exiting thread] gmake 1912 cygthread::stub: erroneous thread activation Thanks for your help. Best regards, Yves -- run_test_simple.csh file -- #!/usr/bin/tcsh -f # I create multiple empty files # mkdir -p test_src set i=0 while ($i = 363) touch test_src/$i.c @ i++ end # I build a gmake output reference file # gmake -f test.mk -r -p -n | grep 'SRC_WITH_MAIN *:=' liste_simple.ref set n=0 set i=0 # And I repeat calling gmake # while ( $n == 0 ) # sleep 1 @ i++ echo -n $i gmake -f test.mk -r -p -n | grep 'SRC_WITH_MAIN *:=' liste_simple.txt set n=`diff -wBq liste_simple.txt liste_simple.ref | wc -l` end cp liste_simple.txt liste-differ_simple.txt exit 0 -- test.mk file --- SRC_DIR := test_src C_EXT = c CPP_EXT = cpp SRC_EXTLIST = $(C_EXT) $(CPP_EXT) SRC_FILES:= $(foreach EXT,$(SRC_EXTLIST),$(wildcard $(SRC_DIR)/*.$(EXT))) SRC_WITH_MAIN:= $(shell ls -1 $(SRC_FILES)) all : ; @printf '%s\n' $(SRC_WITH_MAIN) Cygwin Configuration Diagnostics Current System Time: Thu Feb 17 17:04:18 2005 Windows .NET Server Ver 5.2 Build 3790 Path: d:\QA\tools\simulators\ccs\cygwin\bin d:\QA\tools\compilers\scc d:\QA\tools\excel\reporting d:\QA\tools\excel d:\QA\tools\mutex d:\QA\tools\Other_src\pc-script d:\QA\tools\Other_src\update_tools d:\QA\tools C:\cygwin\home\qauser\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\local\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin d:\scc_simulators C:\cygwin\bin d:\qa\tools d:\qa\tools\Other_src\update_tools c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem .\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(qauser) GID: 544(Administrators) 544(Administrators) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(qauser) GID: 544(Administrators) 513(None)544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\Documents and Settings\qauser\WINDOWS CYGWIN = `ntea ntsec nosmbntsec winsymlinks binmode tty' HOME = `c:\cygwin\home\qauser' MAKE_MODE = `unix' PWD = `/home/qauser' USER = `qauser' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\qauser\Application Data' CC = `scc' CLUSTERLOG = `C:\WINDOWS\Cluster\cluster.log' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMSPEC = `C:\WINDOWS\system32\cmd.exe' CYG_DRIVE = `c:' CYG_PATH = `\cygwin' DISPLAY = `127.0.0.1:0.0' GREP_OPTIONS = `--binary-files=without-match --directories=skip' GROUP = `Administrators' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\qauser' HOSTTYPE = `i386' LESS = `-earX' LOGNAME = `qauser' MACHTYPE = `i386' MANPATH = `:/usr/ssl/man' NEW_QA_ROOT = `/cygdrive/d/QA/root' NUMBER_OF_PROCESSORS = `2' OS = `Windows_NT' OSTYPE = `posix' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 5 Stepping 8, AuthenticAMD' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0508' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' QA_TOOLS = `/cygdrive/d/QA/tools' SESSIONNAME = `RDP-Tcp#11' SHLVL = `1' SYS = `cygwin' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TERM = `cygwin' TZ = `EEST-2EEDT-3,M3.5.0/0,M10.5.0/1' USERNAME = `qauser' USERPROFILE = `C:\Documents and Settings\qauser' VENDOR = `intel' WINDIR = `C:\WINDOWS' 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
Re: gmake -r -p -n problem on fast computers: erroneous thread activa tion
Upgrade your cygwin to the newest snapshot, that has that problem fixed. Guerte Yves-r57319 wrote: Hi, I have problems with gmake on the new computers I use (and not with the same Cygwin version with older computers). I do gmake -r -p -n and parse the output to get some variables content. The problem occurs when a variable is computed using the $(shell ...) command. I shortened the makefile and wrote a small script that shows the problem. Use example (put test.mk and run_test_simple.csh at the same place): run_test_simple.csh 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 1 [exiting thread] gmake 1912 cygthread::stub: erroneous thread activation Thanks for your help. Best regards, Yves -- run_test_simple.csh file -- #!/usr/bin/tcsh -f # I create multiple empty files # mkdir -p test_src set i=0 while ($i = 363) touch test_src/$i.c @ i++ end # I build a gmake output reference file # gmake -f test.mk -r -p -n | grep 'SRC_WITH_MAIN *:=' liste_simple.ref set n=0 set i=0 # And I repeat calling gmake # while ( $n == 0 ) # sleep 1 @ i++ echo -n $i gmake -f test.mk -r -p -n | grep 'SRC_WITH_MAIN *:=' liste_simple.txt set n=`diff -wBq liste_simple.txt liste_simple.ref | wc -l` end cp liste_simple.txt liste-differ_simple.txt exit 0 -- test.mk file --- SRC_DIR := test_src C_EXT = c CPP_EXT = cpp SRC_EXTLIST = $(C_EXT) $(CPP_EXT) SRC_FILES:= $(foreach EXT,$(SRC_EXTLIST),$(wildcard $(SRC_DIR)/*.$(EXT))) SRC_WITH_MAIN:= $(shell ls -1 $(SRC_FILES)) all : ; @printf '%s\n' $(SRC_WITH_MAIN) -- 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: setup package format v. rpm, reasoning?
Peter Rehley wrote: It would require a new setup.exe. The current setup program is a pure windows program. This is needed because it doesn't require using any cygwin program or package. If it used, say for example the cygwin1.dll, that dll couldn't be updated because windows won't allow files to be changed while they are in use. But I already get that message using setup now -- some files were in use when trying to replace them, Please reboot or your installation may not work correctly... I thought setup used the cygwin library...*oh*...*duh*...that must because I run cron now...but that replacement issue is already solved in current setup framework. So, the new setup would need create a temporary cygwin environment that is totally separate from any already installed cygwin environment. The environment could have rpm and do updates pointing to the cygwin environment being updated. If setup could handle installing some base package that rpm would need to run, all of the rest of the packages could become rpm's. Not that I'm expecting it to just magically happen, but if it just gravitated in that direction...Wouldn't have to happen overnight. Current setup could be enhanced to call .rpm for rpm packaged utils, which, for now, could be build with dependencies commented out for now unless the rpm database could somehow be populated from any database setup might use But all that's beside the point if it isn't wanted. Just thought it might make porting packages easier as, often, their sources are even in .rpm's. Wouldn't it be nice if one could take a source RPM, and just rebuild it with only minor changes in the .spec file to have it work? Just a pipedream, perhaps... Linda -- 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: kerberos
Kevin Van Workum wrote: There is a site that I need to access via kerberos. Has anyone built the kerberos clients on cygwin? I have a windows version of kinit, which lets me get a ticket. I can then use putty's ssh to login. I'd like to use the cygwin OpenSSH to do this. If I try, I get: I posted an older version of Kerberos here: http://cygutils.fruitbat.org/testing/ (just use setup.exe and enter the above URL as an alternate download site) However, a word of warning: it is totally and completely unsupported. If it does not work, or you can't figure out how to get it to work, that is Not My Problem. :-) One other thing: AFAIK, every client that uses kerboros keys must be kerberized -- e.g. compiled specifically to use them. That's why kerberos provides its own versions of telnet etc. I do not believe that cygwin SSH has been compiled in this manner. Nor is it likely to, as krb5 is NOT an official cygwin package and is (again) totally unsupported by anyone associated with the cygwin project, including me. -- Chuck -- 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/
Dead link on cygwin web page
Another user alerted me that the link to CygUtils here: http://www.cygwin.com/ported.html has not been updated to reflect CygUtils' new home, at http://cygutils.fruitbat.org/ -- Chuck -- 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: recommendations for 3rd party distributors?
Op Mon, 14 Feb 2005 10:16:08 -0500 schreef Christopher Faylor in [EMAIL PROTECTED]: : On Mon, Feb 14, 2005 at 09:54:41AM -0500, Dick Repasky wrote: : Every so often a query surfaces about cygwin dll version compatibility. [...] : The recommendations are: : :1) Use a distinctly named shared memory area in the cygwin dll. : 2) Use a distinctly named registry key for storing cygwin file system : mount points. : 3) Identify the origin of the cygwin dll in the cygwin dll. [...] : If you are a 3rd party distributor, you should check for existing : installations of the dll. If the existing version of cygwin DLL is the : same or newer than the one you want to use, then notify the user that : there is already a version on the system and that you will not be : installing a new version. : : Otherwise, install your version in a standard location so that it will : survive being upgraded if a user decides to upgrade. : : And, of course, unless this is a distribution which is internal to your ^^^ : organization, remember to offer the user the source code to whatever : application you're providing to them. Where did you find this exception? I don't recall seeing it in the GPL. (I'm a member of the organization of all beings, aren't you as well?) [...] L8r, Buzz. [TITT[TL]L] -- ) | | ---/ ---/ Yes, this | This message consists of true | I do not -- | | // really is | and false bits entirely.| mail for ) | | //a 72 by 4 +---+ any1 but -- \--| /--- /--- .sigfile. | |perl -pe s.u(z)\1.as.| me. 4^re -- 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: recommendations for 3rd party distributors?
On Fri, Feb 18, 2005 at 05:52:02AM +0100, Bas van Gompel wrote: Op Mon, 14 Feb 2005 10:16:08 -0500 schreef Christopher Faylor in [EMAIL PROTECTED]: : And, of course, unless this is a distribution which is internal to your ^^^ : organization, remember to offer the user the source code to whatever : application you're providing to them. Where did you find this exception? I don't recall seeing it in the GPL. (I'm a member of the organization of all beings, aren't you as well?) These kind of questions are best answered by perusing www.gnu.org. Specifically: http://www.gnu.org/licenses/gpl-faq.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: Problem with 20050215 snapshot and ssh-agent forwarding
On Wed, Feb 16, 2005 at 11:23:03AM -0800, David Rothenberger wrote: I'm having a problem with the 20050215 snapshot (and the 20050131 as well). My ssh-agent connection is not being forwarded by ssh. This is working fine with the 20041119 snapshot. Here are the steps to reproduce the problem. I've got ssh and sshd correctly configured to forward ssh-agent connections. The second ssh command should not prompt to the public key passphrase. % keychain ~/.ssh/id_dsa KeyChain 2.0.3; http://www.gentoo.org/projects/keychain Copyright 2002 Gentoo Technologies, Inc.; Distributed under the GPL * All previously running ssh-agent(s) have been stopped. * Initializing /home/drothe/.keychain/tela-sh file... * Initializing /home/drothe/.keychain/tela-csh file... * Starting new ssh-agent * 1 more keys to add... Enter passphrase for /home/drothe/.ssh/id_dsa: Identity added: /home/drothe/.ssh/id_dsa (/home/drothe/.ssh/id_dsa) % . ~/.keychain/tela-sh % ssh `hostname` % ssh `hostname` Enter passphrase for key '/home/drothe/.ssh/id_dsa': I tried this on four different computers and was unable to duplicate the problem. I also asked Corinna to try it out and she was unable to duplicate it either. I assume that ssh-agent is disappearing after the first ssh connection attempt. Can you use strace -ofoo -p pid to attach to the ssh-agent prior to the first ssh `hostname` and send the output here? 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/
minor problem in guile package
The man page for guile is placed in: /usr/share/man/man/man1/guile.1 instead of: /usr/share/man/man1/guile.1 As installed, man guile doesn't find the installed web page. -- 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: minor problem in guile package
Linda W. writes: The man page for guile is placed in: /usr/share/man/man/man1/guile.1 Thanks, that will be fixed in the next release. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org -- 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/
