Re: package conflict: cygwin and sunrpc
On Aug 17 23:09, Charles Wilson wrote:
On 8/17/2010 8:55 PM, Eric Blake wrote:
Both cygwin-1.7.6-1 and sunrpc-4.0-3 install
/usr/include/rpc/{types,xdr}.h. Depending on which package is installed
last, this causes spurious compilation failures, because the two
implementations differ on whether they need sockaddr_in to be declared.
Now that xdr functions have been subsumed into cygwin proper, is it
time to obsolete sunrpc?
Yes, especially as it is orphaned, completely out of date -- even the
upstream version has been replaced in real *nix distros by libtirpc or
derivatives thereof.
On the other hand, libvirt wants to #include
rpc/rpc.h, which only sunrpc provides; is it time to provide that
header as part of base cygwin?
No.
What needs to happen is I need to get off my butt and ITP the following,
already ported, packages:
libtirpc-0.2.1-1
rpcbind-0.2.0-1
rpcgen-2.11.90_20100305-1
Together, these provide a complete replacement for the existing sunrpc
package, and are ported to work with cygwin's xdr implementation.
The only problem is, I haven't had a chance to test rpcbind (it
compiles, but I haven't set up the daemon, nor written a foo-config
script for it, nor written the detailed cygwin documentation that
daemon/services require). There might also be some cygwin-specific
changes necessary, since even with cygrunsrv, the win32 service
environment != unix daemon environment. (e.g. user authentication,
changing uid/gid of remote procedure calls, etc...)
If I posted my current packages, could somebody help out with that?
Right now my hands are kinda full trying to get the sysroot libtool
stuff shepherded...
What about creating an interim package of sunrpc without any headers,
and just upload the libtirpc-0.2.1-1 package which, hopefully, provides
the missing headers in its -devel package?
Note that I'm not talking about rebuilding the sunrpc package, just
re-packing.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [RFU] {emacs,emacs-X11,emacs-el}-23.2-2
On Aug 17 18:11, Ken Brown wrote: New test release. wget -x -nH --cut-dirs=2 \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-23.2-2-src.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-23.2-2.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-X11/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-X11/emacs-X11-23.2-2.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-el/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-el/emacs-el-23.2-2.tar.bz2 Please leave 23.1-10 as previous and 23.2-1 as current. Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH] setup: be less scary about missing dependencies
On Aug 17 20:02, Andy Koppe wrote: The Unmet Dependencies Found message on the Resolve Dependencies page may mislead people into thinking that there's a problem with setup.exe or packaging, when in fact it's a routine step now. Also, the message box that appears when choosing not to select required packages overstates its case a little bit. So this patch tweaks both. Andy ChangeLog: * res.rc (IDD_PREREQ): Say Resolving Dependencies instead of Unmet Dependencies Found * prereq.cc (PrereqPage::OnNext): Tone down message box about missing dependencies. SOunds good to me. Please apply. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
ITP: libtirpc
libtirpc is an updated version of the Sun RPC library. As such, it replaces part of the (orphaned) sunrpc package -- just as on linux, it replaces the built-in RPC routines in glibc: http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php The headers are installed into \ /usr/lib/tirpc/rpc/* and not /usr/lib/rpc/ which forces developers to add -I/usr/lib/tirpc. Similarly, linking requires -ltirpc. However, this is the same procedure used on linux -- so any client that has already been taught how to accept tirpc on linux will be fine on cygwin. This version is compiled without the XDR routines, as cygwin-1.7.2+ provides those routines internally. It is compiled without AUTH_DES support (that is, cygwin libtirpc is not NIS-aware, because there is not yet any cygwin NIS server or client; since NIS requires a portmap or rpcbind implementation, we have a bit of a chicken/egg issue). Also, it is compiled without GSS_API support, because the official cygwin distribution does not yet contain any Kerboros implementation. Thus, this version of libtirpc supports only unencrypted communication. However, MOST uses of RPC are unencrypted, so this shouldn't be a big deal. http://cygwin.cwilson.fastmail.fm/ITP/libtirpc1-0.2.1-1.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/libtirpc-devel-0.2.1-1.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/libtirpc-0.2.1-1.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/libtirpc-0.2.1-1-src.tar.bz2 libtirpc is included in the Fedora distribution: http://koji.fedoraproject.org/koji/packageinfo?packageID=398 setup.hint - category: Net requires: sdesc: A port of Sun's Transport-Independent RPC library (doc) ldesc: TI-RPC provides a library that implements Transport Independent Remote Procedure Calls. It supports RPCs over IPv4, IPv6, as well as local unix sockets. devel.hint - category: Net Devel requires: libtirpc1 external-source: libtirpc sdesc: A port of Sun's Transport-Independent RPC library (devel) ldesc: TI-RPC provides a library that implements Transport Independent Remote Procedure Calls. It supports RPCs over IPv4, IPv6, as well as local unix sockets. runtime.hint - category: Net Libs requires: libtirpc libgcc1 external-source: libtirpc sdesc: A port of Sun's Transport-Independent RPC library (runtime) ldesc: TI-RPC provides a library that implements Transport Independent Remote Procedure Calls. It supports RPCs over IPv4, IPv6, as well as local unix sockets. -- Chuck
ITA (sortof): sunrpc
sunrpc is orphaned. It provides libraries and headers for rpc routines, utilities including rpcgen, documentation, and the portmap daemon. The current version of sunrpc is 4.0-3, from 2005. The proposed version, 4.0-4, has NOT been recompiled. It is simply a repackaged version of 4.0-3, with some of the elements removed as they are now provided by cygwin itself, or by newly ITP'ed replacement packages such as 'libtirpc' and 'rpcgen'. What remains is simply: /usr/bin/rstat.exe /usr/sbin/portmap.exe /usr/sbin/rpcinfo.exe /usr/include/rpcsvc/various /usr/share/doc/Cygwin/sunrpc.README /usr/share/doc/sunrpc/* /usr/share/man/man1/rstat.1.gz /usr/share/man/man5/rpc.5.gz /usr/share/man/man8/portmap.8c /usr/share/man/man8/rpcinfo.8c /usr/share/man/man8/rstat_svc.8c http://cygwin.cwilson.fastmail.fm/ITP/sunrpc-4.0-4.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/sunrpc-4.0-4-src.tar.bz2 Eventually, portmap and rpcinfo will be replaced by the rpcbind package, and 'sunrpc' can be completely retired. But until that happens, a tiny bit of TLC is needed: hence, this sortof ITA. category: Net requires: rpcgen libtirpc libtirpc-devel sdesc: Sun RPC (ONC/RPC) utilities ldesc: This distribution contains Sun Microsystem's implementation of the RPC portmapper and other utilities. Also included are the RPC service specification files, and demonstration services in the format used by the RPC protocol compiler (rpcgen). This package is 'almost' obsolete; most of the earlier contents (a library providing XDR and RPC functions, the rpcgen utility, and other documentation) have been supplanted by cygwin itself, or the new 'libtirpc' and 'rpcgen' pacakges. Eventually, this package will be completely obsoleted, once the new 'rpcbind' package is completely ported for cygwin.
Re: New VIM version 7.3.002-1
On Tue, 2010-08-17 at 11:54 +0200, Corinna Vinschen wrote: I have prepared a new release of vim, 7.3.002-1, so it's the new 7.3 release from yesterday with its first two patches. [snip] You can find the source and binary packages on sourceware under ~corinna/x/vim/ Please ping me when you finished the corresponding gvim release. Thanks for the heads-up. gvim is now on sourceware under ~yselkowitz/uploads/gvim/ . Yaakov
[PATCH] setup: update non-experimental packages too when Exp is selected
At the moment, non-experimental packages don't get updated when 'Exp'
is selected. This was reported at
http://cygwin.com/ml/cygwin/2010-08/msg00460.html.
The fix turned out to be quite simple.
Andy
ChangeLog:
* package_meta.h (packagemeta::trustp): Update non-experimental
packages too when Exp is selected.
Index: package_meta.h
===
RCS file: /cvs/cygwin-apps/setup/package_meta.h,v
retrieving revision 2.38
diff -u -r2.38 package_meta.h
--- package_meta.h 13 Dec 2009 19:23:43 - 2.38
+++ package_meta.h 19 Aug 2010 05:06:47 -
@@ -94,9 +94,9 @@
std::string action_caption () const;
packageversion trustp (trusts const t) const
{
-return t == TRUST_PREV ? (prev ? prev : (curr ? curr : installed))
- : t == TRUST_CURR ? (curr ? curr : installed)
-: exp ? exp : installed;
+return t == TRUST_PREV prev ? prev
+ : t == TRUST_TEST exp ? exp
+ : curr ? curr : installed;
}
exp.patch
Description: Binary data
src/winsup/cygwin ChangeLog fhandler_disk_file.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-18 10:10:14 Modified files: winsup/cygwin : ChangeLog fhandler_disk_file.cc Log message: * fhandler_disk_file.cc (fhandler_base::fstat_helper): Set st_rdev to correct device number for fs_special devices. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4994r2=1.4995 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.331r2=1.332
src/winsup/cygwin ChangeLog exceptions.cc path.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-18 14:22:08 Modified files: winsup/cygwin : ChangeLog exceptions.cc path.cc Log message: * exceptions.cc (open_stackdumpfile): Don't try to open file if we have no filesystem based CWD. Add comment. * path.cc (cwdstuff::set): Set CWD handle to NULL if CWD is a virtual path. Simplify matching comment. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4995r2=1.4996 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/exceptions.cc.diff?cvsroot=srcr1=1.348r2=1.349 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.600r2=1.601
src/winsup/doc ChangeLog pathnames.sgml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-18 15:28:16 Modified files: winsup/doc : ChangeLog pathnames.sgml Log message: * pathnames.sgml (pathnames-win32-api): Try to use a more clear wording. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.310r2=1.311 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/pathnames.sgml.diff?cvsroot=srcr1=1.56r2=1.57
winsup/cygwin ChangeLog external.cc include/cy ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-08-18 19:15:37 Modified files: cygwin : ChangeLog external.cc cygwin/include/cygwin: version.h cygwin/include/sys: cygwin.h Log message: * external.cc (CW_SETCWD): New option. * include/cygwin/version.h: Bump api minor to 231. * include/sys/cygwin.h (CW_SETCWD): Define. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4997r2=1.4998 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/external.cc.diff?cvsroot=uberbaumr1=1.116r2=1.117 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/include/cygwin/version.h.diff?cvsroot=uberbaumr1=1.321r2=1.322 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/include/sys/cygwin.h.diff?cvsroot=uberbaumr1=1.87r2=1.88
src/winsup/w32api ChangeLog include/winbase.h
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2010-08-18 23:34:08 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: winbase.h Log message: 2010-08-18 Ladislav Michl la...@users.sourceforge.net * include/winbase.h (SYMBOLIC_LINK_FLAG_DIRECTORY, CreateSymbolicLinkW, CreateSymbolicLinkA, CreateSymbolicLink): Define Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.1026r2=1.1027 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winbase.h.diff?cvsroot=srcr1=1.98r2=1.99
Re: Postinstall for mintty fails when installing just for me
On 17 August 2010 20:12, Buchbinder, Barry (NIH/NIAID) [E] wrote: Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:49 AM On Aug 17 06:52, Andy Koppe wrote: On 17 August 2010 02:26, Buchbinder, Barry wrote: $ bash --norc --noprofile /etc/postinstall/mintty.sh /bin/mkdir: cannot create directory `/c/Documents and Settings/All Users/Start Menu/Programs/Cygwin': Permission denied mkshortcut: Saving C:\Documents and Settings\All Users\Start Menu\Programs\Cygwin\mintty.lnk failed; does the target directory exist? /bin/chmod: cannot access `/c/Documents and Settings/All Users/Start Menu/Programs/Cygwin/mintty.lnk': No such file or directory echo $? 1 Hmm, the test at the top of the script is meant to avoid that, by checking whether the 'All Users/Start Menu/Programs' folder is writable. Any idea why that's saying yes when apparently it isn't writable? I tried your script and it works fine for me. If I'm running as admin in a UAC-restricted shell, the test fails as expected. The problem is, we don't know anything about your environment, Barry. cygcheck output as requested by http://cygwin.com/problems.html would be helpful, perhaps. Attached. Thanks. Please note: $ cygcheck -s -v -r cygcheck.out /usr/bin/cygrunsrv: warning: OpenService failed for 'TapiSrv': Win32 error 5 Access is denied. As is getfacl/cacls output for the /c/Documents and Settings/All Users/Start Menu/Programs directory. $ getfacl '/c/Documents and Settings/All Users/Start Menu/Programs' # file: /c/Documents and Settings/All Users/Start Menu/Programs # owner: BBuchbinder # group: Domain Users user::rwx group::r-x other:r-x mask:rwx Hmm, so you've got 'rwx' permissions on that directory yet you can't create a directory in it. That just leaves me puzzled. $ cacls 'C:\Documents and Settings\All Users\Start Menu\Programs' C:\Documents and Settings\All Users\Start Menu\Programs BUILTIN\Administrators:(OI)(CI)F CREATOR OWNER:(OI)(CI)(IO)F NT AUTHORITY\SYSTEM:(OI)(CI)F BUILTIN\Users:(OI)(CI)R Not knowing enough about ACLs: does the BUILTIN\Users, which says read-only, override the CREATOR OWNER entry, which grants full access? Is there a proper way for a postinstall script to find out whether it's an install for all users or Just Me? Hmm, afaik no. You could try to write to All Users first and if that fails, write to the user's own Programs. Sounds like the way to go (for the moment anyway), especially now that mkshortcut correctly reports success. But, maybe we should define a couple of useful, installation-specific arguments for postinstall scripts and change setup accordingly? I think that would be useful. Looking at the source in script.cc, the Cygwin root is passed as a variable already. I should have started by saying that, as a practical matter, this is not a problem for me. I have a minty shortcut and renaming /etc/postinstall/minty.sh to /etc/postinstall/minty.sh.done stops the error message from coming up. Yep, that's the right workaround. And thanks for this upgrade of setup. For some time now the pending view had the same two empty packages appear each time I ran setup. Very annoying. Now, they no longer show up. Dave Korn fixed that one. A relief indeed. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Setup 2.712 crashes when running reinstall after install
Hi all, the setup.exe crashes when I do are install after an install operation (downloading files only). When I click back after installation complete to select reinstall the a message box appears with Download incomplete. Try again?. If I select yes then then download site list appears. After selecting next the select packages window appears having set reinstall in the All Category (others default). Selecting next again crashes setup.exe. OS is Win7 64-bit. This used to work up the previous version of setup.exe KJ PS: the crash also happens when running reinstall from the very beginning. Problemsignatur: Problemereignisname: APPCRASH Anwendungsname: setup.exe_unknown Anwendungsversion:0.0.0.0 Anwendungszeitstempel:4c617e25 Fehlermodulname: StackHash_0a9e Fehlermodulversion: 0.0.0.0 Fehlermodulzeitstempel: Ausnahmecode: c005 Ausnahmeoffset: 009a9d58 Betriebsystemversion: 6.1.7600.2.0.0.256.4 Gebietsschema-ID: 1031 Zusatzinformation 1: 0a9e Zusatzinformation 2: 0a9e372d3b4ad19135b953a78882e789 Zusatzinformation 3: 0a9e Zusatzinformation 4: 0a9e372d3b4ad19135b953a78882e789 Lesen Sie unsere Datenschutzbestimmungen online: http://go.microsoft.com/fwlink/?linkid=104288clcid=0x0407 Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline: C:\Windows\system32\de-DE\erofflps.txt -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Postinstall for mintty fails when installing just for me
On Aug 17 15:12, Buchbinder, Barry (NIH/NIAID) [E] wrote: Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:49 AM On 17 August 2010 02:26, Buchbinder, Barry wrote: $ bash --norc --noprofile /etc/postinstall/mintty.sh /bin/mkdir: cannot create directory `/c/Documents and Settings/All Users/Start Menu/Programs/Cygwin': Permission denied mkshortcut: Saving C:\Documents and Settings\All Users\Start Menu\Programs\Cygwin\mintty.lnk failed; does the target directory exist? /bin/chmod: cannot access `/c/Documents and Settings/All Users/Start Menu/Programs/Cygwin/mintty.lnk': No such file or directory echo $? 1 [...] The problem is, we don't know anything about your environment, Barry. cygcheck output as requested by http://cygwin.com/problems.html would be helpful, perhaps. Attached. Please note: $ cygcheck -s -v -r cygcheck.out /usr/bin/cygrunsrv: warning: OpenService failed for 'TapiSrv': Win32 error 5 Access is denied. That usually just means you don't have admin privs. As is getfacl/cacls output for the /c/Documents and Settings/All Users/Start Menu/Programs directory. $ getfacl '/c/Documents and Settings/All Users/Start Menu/Programs' # file: /c/Documents and Settings/All Users/Start Menu/Programs # owner: BBuchbinder # group: Domain Users user::rwx group::r-x other:r-x mask:rwx $ cacls 'C:\Documents and Settings\All Users\Start Menu\Programs' C:\Documents and Settings\All Users\Start Menu\Programs BUILTIN\Administrators:(OI)(CI)F CREATOR OWNER:(OI)(CI)(IO)F NT AUTHORITY\SYSTEM:(OI)(CI)F BUILTIN\Users:(OI)(CI)R [...] Here's the actual problem: cygdrive prefix / system binary,noacl,posix=0,auto The cygdrive prefix is set to the mount option noacl. So the output from getfacl or ls or stat for this directory shows just fake permissions based on the DOS R/O flag. You're not an admin, so you're not allowed to write to this directory, see the cacls output. However, since the cygdrive prefix is mounted with noacl, Cygwin tools just don't know it. Andy, to workaround this, you *could* create a user mount first which has no noacl, then use the user mount to check permissions, and eventually umount again. Like this: PROGS=/tmp/.mintty-postinstall-$$ mount -f `cygpath -APm` $PROGS if [ -w $PROGS ]; then [...] else [...] fi umount $PROGS Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7 lock directory problem
On Aug 18 01:52, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 01:05:13PM +0800, Huang Bambo wrote: Do you have a series of steps that produces the problem you see? As I said in previous mail. 1. cd /cygdriver/i( I is mounted as a usb-stick) 2. cd /proc 3. Use some tools such as Unlocker to check driver I, Unlocker said driver I is locked by bash. 4. cd / ( / is at d:\cygwin ) 5. do the same as step 3, driver is not locked by bash. That's how Cygwin 1.7.5 would work. I would expect different behavior for 1.7.6. No, that's also how 1.7.6 works. I documented this behaviour in path.cc: /* Note that we don't set the dir handle to NULL for virtual paths. The handle is used to generate a stackdump file. Since we can't create a stackdump in a virtual path, we have at least *some* directory handle to generate the stackdump in. However, note that we have to make sure that we don't use the handle wrongly as soon as we start to use it in other cases as well. */ Looks like this behaviour is a problem and we should better close the old handle. What to do with the new one? Just set it to NULL and disallow stackdumps as long as we're in a virtual path? Or set it to some well known path, like Cygwin's root? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h endian.h.diff
On Aug 17 22:44, Pedro Izecksohn wrote: --- Corinna Vinschen wrote: For this patch, given that it is just a bunch of rather obvious defines, I don't think we have to treat the patch as significant. I do not think that these macros are obvious. I think that I was there when these macros were first implemented at 1987: I talked with the programmer who was paid by the Correios to port everything from the mainframe to the Apple II. I was a stenchy kid with his father, that asked the employee what he was doing. When I asked about other possibilities of endianness, the programmer answered about the PDP. The programmer explained about BSD being a flavor of Unix. That talk changed my life. However, please don't use _BSD_SOURCE. The newlib/Cygwin headers are not set up like the Linux headers and the big bunch of definitions from /usr/include/features.h are not available so far. The _BSD_SOURCE define is not honored or set anywhere right now. What you can do is to use _POSIX_SOURCE. So, if you're going to use #ifndef _POSIX_SOURCE instead, and if you're creating a ChangeLog entry in the correct ChangeLog entry format (see the ChangeLog file), then I guess we can check it in. Would you agree with: #if defined _BSD_SOURCE || ! defined _POSIX_SOURCE Ok. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mknod bug? major minor's are whacky
On Aug 17 17:51, Eric Blake wrote: On 08/17/2010 05:46 PM, Bob Goldberg wrote: cygwin 1.7.6 attempting to: $ mknod null c 1 3 what I get is: crw-rw-rw- 1 user mkgroup-l-d 46200, 14467 2010-08-17 18:44 null WHERE did those crazy major/minor's come from!?!? They come from Cygwin. They are an accidental reflection of the volume id, which is used in stat::st_rdev for files by default. Cygwin only set st_dev to the device number so far. I fixed that in CVS so that st_rdev and st_dev both contain the device number now for device files. Thanks for the report, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7 lock directory problem
Greetings, Corinna Vinschen! Do you have a series of steps that produces the problem you see? As I said in previous mail. 1. cd /cygdriver/i( I is mounted as a usb-stick) 2. cd /proc 3. Use some tools such as Unlocker to check driver I, Unlocker said driver I is locked by bash. 4. cd / ( / is at d:\cygwin ) 5. do the same as step 3, driver is not locked by bash. That's how Cygwin 1.7.5 would work. I would expect different behavior for 1.7.6. No, that's also how 1.7.6 works. I documented this behaviour in path.cc: /* Note that we don't set the dir handle to NULL for virtual paths. The handle is used to generate a stackdump file. Since we can't create a stackdump in a virtual path, we have at least *some* directory handle to generate the stackdump in. However, note that we have to make sure that we don't use the handle wrongly as soon as we start to use it in other cases as well. */ Looks like this behaviour is a problem and we should better close the old handle. What to do with the new one? Just set it to NULL and disallow stackdumps as long as we're in a virtual path? Or set it to some well known path, like Cygwin's root? /var or /tmp would be more sensible. -- WBR, Andrey Repin (anrdae...@freemail.ru) 18.08.2010, 14:27 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7 lock directory problem
On Aug 18 14:28, Andrey Repin wrote: Greetings, Corinna Vinschen! Do you have a series of steps that produces the problem you see? As I said in previous mail. 1. cd /cygdriver/i( I is mounted as a usb-stick) 2. cd /proc 3. Use some tools such as Unlocker to check driver I, Unlocker said driver I is locked by bash. 4. cd / ( / is at d:\cygwin ) 5. do the same as step 3, driver is not locked by bash. That's how Cygwin 1.7.5 would work. I would expect different behavior for 1.7.6. No, that's also how 1.7.6 works. I documented this behaviour in path.cc: /* Note that we don't set the dir handle to NULL for virtual paths. The handle is used to generate a stackdump file. Since we can't create a stackdump in a virtual path, we have at least *some* directory handle to generate the stackdump in. However, note that we have to make sure that we don't use the handle wrongly as soon as we start to use it in other cases as well. */ Looks like this behaviour is a problem and we should better close the old handle. What to do with the new one? Just set it to NULL and disallow stackdumps as long as we're in a virtual path? Or set it to some well known path, like Cygwin's root? /var or /tmp would be more sensible. Maybe, but it also costs time. /var and /tmp Windows paths have to be generated by a full path conversion every time you call chdir() to a virtual directory. The Cygwin installation path (aka the root dir) is just available. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mintty hangs after SSH disconnect
On 18 August 2010 09:51, Csaba Raduly wrote: The following scenario keeps happening more often than I like: I open a mintty console with a ssh: C:\cygwin17\bin\mintty.exe /bin/bash --login -c /usr/bin/ssh -Y lablinux1 (time passes) I set the computer to sleep (the power button is reconfigured to sleep instead of shutdown). When I come back (usually the next day) and bring the computer back up, the SSH connection is lost: Write error: connection reset by peer This is understandable, considering the long time gap with no connection. The normal behavior is that after pressing Enter, the mintty window disappears. However, sometimes at this point mintty is consuming 100% CPU and has to be killed manually. That's http://code.google.com/p/mintty/issues/detail?id=211, broken since 0.8-beta1, reported and fixed in svn for 0.8.2 just last night. Btw, the close button and Alt+F4 should still work inspite of the 100% CPU. I guess I better also restore the behaviour where any keypress closes the terminal if the pty has reported EOF. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Postinstall for mintty fails when installing just for me
On 18 August 2010 09:43, Corinna Vinschen wrote: On Aug 17 15:12, Buchbinder, Barry (NIH/NIAID) [E] wrote: Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:49 AM On 17 August 2010 02:26, Buchbinder, Barry wrote: $ bash --norc --noprofile /etc/postinstall/mintty.sh /bin/mkdir: cannot create directory `/c/Documents and Settings/All Users/Start Menu/Programs/Cygwin': Permission denied mkshortcut: Saving C:\Documents and Settings\All Users\Start Menu\Programs\Cygwin\mintty.lnk failed; does the target directory exist? /bin/chmod: cannot access `/c/Documents and Settings/All Users/Start Menu/Programs/Cygwin/mintty.lnk': No such file or directory echo $? 1 [...] The problem is, we don't know anything about your environment, Barry. cygcheck output as requested by http://cygwin.com/problems.html would be helpful, perhaps. Attached. Please note: $ cygcheck -s -v -r cygcheck.out /usr/bin/cygrunsrv: warning: OpenService failed for 'TapiSrv': Win32 error 5 Access is denied. That usually just means you don't have admin privs. As is getfacl/cacls output for the /c/Documents and Settings/All Users/Start Menu/Programs directory. $ getfacl '/c/Documents and Settings/All Users/Start Menu/Programs' # file: /c/Documents and Settings/All Users/Start Menu/Programs # owner: BBuchbinder # group: Domain Users user::rwx group::r-x other:r-x mask:rwx $ cacls 'C:\Documents and Settings\All Users\Start Menu\Programs' C:\Documents and Settings\All Users\Start Menu\Programs BUILTIN\Administrators:(OI)(CI)F CREATOR OWNER:(OI)(CI)(IO)F NT AUTHORITY\SYSTEM:(OI)(CI)F BUILTIN\Users:(OI)(CI)R [...] Here's the actual problem: cygdrive prefix / system binary,noacl,posix=0,auto The cygdrive prefix is set to the mount option noacl. So the output from getfacl or ls or stat for this directory shows just fake permissions based on the DOS R/O flag. Thanks very much for spotting that. You're not an admin, so you're not allowed to write to this directory, see the cacls output. However, since the cygdrive prefix is mounted with noacl, Cygwin tools just don't know it. Andy, to workaround this, you *could* create a user mount first which has no noacl, then use the user mount to check permissions, and eventually umount again. Like this: PROGS=/tmp/.mintty-postinstall-$$ mount -f `cygpath -APm` $PROGS if [ -w $PROGS ]; then [...] else [...] fi umount $PROGS Hmm, I'm a bit afraid that might find creative new ways of going wrong. ;) I think I'll go with your previous suggestion of just going ahead and trying to create the 'All Users' shortcut and falling back to the user's start menu if that fails. Although, perhaps there's a way to tell from $CYGWINROOT whether we're dealing with an install for all users or just me? Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Postinstall for mintty fails when installing just for me
On Aug 18 12:24, Andy Koppe wrote: On 18 August 2010 09:43, Corinna Vinschen wrote: Andy, to workaround this, you *could* create a user mount first which has no noacl, then use the user mount to check permissions, and eventually umount again. Like this: PROGS=/tmp/.mintty-postinstall-$$ mount -f `cygpath -APm` $PROGS if [ -w $PROGS ]; then [...] else [...] fi umount $PROGS Hmm, I'm a bit afraid that might find creative new ways of going wrong. ;) The only way that could go wrong is, if the user already has 30 mount points, since that's the current maximum nuber of allowed mounts. I think I'll go with your previous suggestion of just going ahead and trying to create the 'All Users' shortcut and falling back to the user's start menu if that fails. Although, perhaps there's a way to tell from $CYGWINROOT whether we're dealing with an install for all users or just me? No, but I don't think it would hurt to enhance setup.exe, either by adding arguments to postinstall/preremove scripts, or by adding an environment variable like $CYGWIN_AUDIENCE with the values all_user or just_me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated [experimental]: {emacs,emacs-X11,emacs-el}-23.2-2
New releases of the emacs, emacs-X11, and emacs-el packages (23.2-2) are now available as experimental packages. These are rebuilds of the 23.2-1 packages, with D-BUS support. You will need to install libdbus1_3 in order to run the new binaries. Please report any regressions. If nothing serious is reported, the new releases will be promoted to current in a few weeks. CYGWIN NOTES There is a known bug in the cygwin build of emacs, which affects emacs functions like display-time. See /usr/share/doc/Cygwin/emacs.README for details and a simple workaround. Install the emacs-X11 package if you want to use the X11 GUI. You can then type 'emacs' in an xterm window, and emacs will start in a new window. If you run emacs in the cygwin console, be sure that your CYGWIN environment variable (http://cygwin.com/cygwin-ug-net/setup-env.html) contains tty. The script /usr/bin/make-emacs-shortcut can be used to create a shortcut for starting emacs. The shortcut starts emacs under X if an X server is running and in a mintty window otherwise. Edit the shortcut and/or the script if you want different behavior. You will need the cygutils package to run the script, and you will need mintty and run2 to use the shortcut. In addition, the user who runs the script needs to be able to write to /usr/local/bin. EMACS NEWS == See http://www.gnu.org/software/emacs/ for a summary of new features since Emacs 23.1. You can also use the command 'C-h n' within emacs to browse the NEWS file. DESCRIPTION === Emacs is a powerful, customizable, self-documenting, modeless text editor. Emacs contains special code editing features, a scripting language (elisp), and the capability to read mail, news, and more without leaving the editor. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then run setup and answer all the questions. Ken Brown Cygwin emacs maintainer *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Postinstall for mintty fails when installing just for me
On Aug 18 13:35, Corinna Vinschen wrote: On Aug 18 12:24, Andy Koppe wrote: On 18 August 2010 09:43, Corinna Vinschen wrote: Andy, to workaround this, you *could* create a user mount first which has no noacl, then use the user mount to check permissions, and eventually umount again. Like this: PROGS=/tmp/.mintty-postinstall-$$ mount -f `cygpath -APm` $PROGS if [ -w $PROGS ]; then [...] else [...] fi umount $PROGS Hmm, I'm a bit afraid that might find creative new ways of going wrong. ;) The only way that could go wrong is, if the user already has 30 mount points, since that's the current maximum nuber of allowed mounts. Btw., see /bin/ssh-host-config, line 93 :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 1.7.5 segfault during setup
I'm still having this error. Is it possible for the Cygwin folks to create a setup.exe that includes debugging symbols so I can get more information out of gdb? It's a long shot, I know, but it's worth a try. On Mon, Aug 16, 2010 at 5:32 PM, Steve Marotta smaro...@gmail.com wrote: I am using Cygwin 1.7.5, upgraded from 1.5, or so I think. I am trying to run setup.exe so I can install new packages. I select Install from Internet and Direct Connection, and my network connection itself works fine. When setup tries to download the mirrors list, it says, This application has requested the Runtime to terminate it in an unusual way. I tried running it under gdb, but without debug symbols, it didn't do much good. Here's the output: Starting program: c:/Documents and Settings/smarotta.CRA/My Documents/downloads/setup-1.7.5.exe Loaded symbols for C:\WINDOWS\system32\ntdll.dll Loaded symbols for C:\WINDOWS\system32\kernel32.dll Loaded symbols for C:\WINDOWS\system32\advapi32.dll Loaded symbols for C:\WINDOWS\system32\rpcrt4.dll Loaded symbols for C:\WINDOWS\system32\secur32.dll Loaded symbols for C:\WINDOWS\WinSxS\X86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll Loaded symbols for C:\WINDOWS\system32\msvcrt.dll Loaded symbols for C:\WINDOWS\system32\gdi32.dll Loaded symbols for C:\WINDOWS\system32\user32.dll Loaded symbols for C:\WINDOWS\system32\shlwapi.dll Loaded symbols for C:\WINDOWS\system32\ole32.dll Loaded symbols for C:\WINDOWS\system32\shell32.dll Loaded symbols for C:\WINDOWS\system32\wsock32.dll Loaded symbols for C:\WINDOWS\system32\ws2_32.dll Loaded symbols for C:\WINDOWS\system32\ws2help.dll warning: LOG: 2 Starting cygwin install, version 2.697 warning: LOG: 2 io_stream_cygfile: fopen(/etc/setup/net-proxy-host) failed 2 No such file or directory warning: LOG: 2 io_stream_cygfile: fopen(/etc/setup/net-proxy-port) failed 2 No such file or directory warning: LOG: 2 io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No such file or directory warning: LOG: 2 io_stream_cygfile: fopen(/etc/setup/chooser_window_settings) failed 2 No such file or directory warning: LOG: 2 Current Directory: C:\Documents and Settings\smarotta\Home\temp warning: LOG: 2 User has backup/restore rights warning: LOG: 2 Changing gid to Administrators warning: LOG: 2 Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. warning: LOG: 2 source: network install warning: LOG: 2 root: C:\cygwin binary system warning: LOG: 2 Selected local directory: C:\Documents and Settings\smarotta\Home\temp warning: LOG: 2 net: Direct warning: LOG: 1 Loaded cached mirror list warning: LOG: 1 get_url_to_membuf http://cygwin.com/mirrors.lst warning: LOG: 1 getUrlToStream http://cygwin.com/mirrors.lst Program exited with code 03. Is there a problem with the cached mirrors list? Can I clear that cache? Can it be the .NET framework I have installed on my machine? I would appreciate any and all ideas anyone has on how to resolve this issue, as I need to use Cygwin as soon as possible. Thanks, Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7 lock directory problem
On 08/18/2010 05:08 AM, Corinna Vinschen wrote: Looks like this behaviour is a problem and we should better close the old handle. What to do with the new one? Just set it to NULL and disallow stackdumps as long as we're in a virtual path? Or set it to some well known path, like Cygwin's root? /var or /tmp would be more sensible. Maybe, but it also costs time. /var and /tmp Windows paths have to be generated by a full path conversion every time you call chdir() to a virtual directory. The Cygwin installation path (aka the root dir) is just available. Using / as the fallback during a virtual directory makes sense to me (there may be other permission problems if / is not writable by the current user, but a stack dump is a best effort attempt anyways). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: cygwin 1.7 lock directory problem
2010/8/18 Eric Blake ebl...@redhat.com: On 08/18/2010 05:08 AM, Corinna Vinschen wrote: Looks like this behaviour is a problem and we should better close the old handle. What to do with the new one? Just set it to NULL and disallow stackdumps as long as we're in a virtual path? Or set it to some well known path, like Cygwin's root? /var or /tmp would be more sensible. Maybe, but it also costs time. /var and /tmp Windows paths have to be generated by a full path conversion every time you call chdir() to a virtual directory. The Cygwin installation path (aka the root dir) is just available. Using / as the fallback during a virtual directory makes sense to me (there may be other permission problems if / is not writable by the current user, but a stack dump is a best effort attempt anyways). Even in linux, you can't generate core file in virtual directory also, so just don't generate core file if you can't write at anywhere. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7 lock directory problem
On Wed, Aug 18, 2010 at 09:51:29PM +0800, Huang Bambo wrote: 2010/8/18 Eric Blake ebl...@redhat.com: On 08/18/2010 05:08 AM, Corinna Vinschen wrote: Looks like this behaviour is a problem and we should better close the old handle. ?What to do with the new one? ?Just set it to NULL and disallow stackdumps as long as we're in a virtual path? ?Or set it to some well known path, like Cygwin's root? /var or /tmp would be more sensible. Maybe, but it also costs time. ?/var and /tmp Windows paths have to be generated by a full path conversion every time you call chdir() to a virtual directory. The Cygwin installation path (aka the root dir) is just available. Using / as the fallback during a virtual directory makes sense to me (there may be other permission problems if / is not writable by the current user, but a stack dump is a best effort attempt anyways). Even in linux, you can't generate core file in virtual directory also, so just don't generate core file if you can't write at anywhere. Right. I don't think we need a fallback. How is this any different than what happens when you generate a core dump in linux in a read-only directory? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7 lock directory problem
On Aug 18 10:07, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 09:51:29PM +0800, Huang Bambo wrote: 2010/8/18 Eric Blake ebl...@redhat.com: On 08/18/2010 05:08 AM, Corinna Vinschen wrote: Looks like this behaviour is a problem and we should better close the old handle. ?What to do with the new one? ?Just set it to NULL and disallow stackdumps as long as we're in a virtual path? ?Or set it to some well known path, like Cygwin's root? /var or /tmp would be more sensible. Maybe, but it also costs time. ?/var and /tmp Windows paths have to be generated by a full path conversion every time you call chdir() to a virtual directory. The Cygwin installation path (aka the root dir) is just available. Using / as the fallback during a virtual directory makes sense to me (there may be other permission problems if / is not writable by the current user, but a stack dump is a best effort attempt anyways). Even in linux, you can't generate core file in virtual directory also, so just don't generate core file if you can't write at anywhere. Right. I don't think we need a fallback. How is this any different than what happens when you generate a core dump in linux in a read-only directory? I just applied a matching patch. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
run changes behavior with cygwin-17.6
Hi, After upgrading to cygwin17.6 the program run changes behavior. For example: If I start mintty with the followin .bat @echo off C: chdir \cygwin\bin run mintty -e '/bin/bash' --login -i exit In the mintty window that is started appears the following message: /bin/find: failed to restore initial working directory: No such file or directory rmed...@limon ~ $ --- The message of /bin/find is due to the run program and does not appear with cygwin17.5 Everything else is OK Bye RM -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Aug 18 10:21, Rodrigo Medina wrote: Hi, After upgrading to cygwin17.6 the program run changes behavior. For example: If I start mintty with the followin .bat @echo off C: chdir \cygwin\bin run mintty -e '/bin/bash' --login -i exit In the mintty window that is started appears the following message: /bin/find: failed to restore initial working directory: No such file or directory Looks like the run tool now needs a call to CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd)); and then use win32_cwd in the call to CreateProcess. See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
X-forwarding very very slow
Hi, I have a problem with Cygwin. I am connecting from USA by ssh to the Hector supermachine in Edinburgh ( I write startx in Cygwin and then I use ssh -Y v1aca...@login.hector.ac.uk ). Everything works fine, the only problem is that the forwarding of the windows is very very slow. It takes sometimes also up to 5 minutes to open a new window. I am debugging a code with Totalview and it is a impossible to work. I am in contact with the Hector support and with their computer they tried to run Cygwin under windows and connecting by ssh (exactly like I am doing) and they say that x-forwarding is fast. My version is: CYGWIN_NT-5.1 1.7.1(0.218/5/3) 2009-12-07 11:48 while their version is: CYGWIN_NT-6.0 1.5.25(0.156/4/2) 2008-06-12 19:34 So my version is more recent. I do not fell like to downgrade Cygwin, everything works well save the slow X-forwarding. Any suggestion please? Thank you very much best regards Alberto -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: X-forwarding very very slow
On 8/18/10 8:43 AM, Alberto Canestrelli wrote: I have a problem with Cygwin. I am connecting from USA by ssh to the Hector supermachine in Edinburgh ( I write startx in Cygwin and then I use ssh -Y v1aca...@login.hector.ac.uk ). Everything works fine, the only problem is that the forwarding of the windows is very very slow. It takes sometimes also up to 5 minutes to open a new window. I am debugging a code with Totalview and it is a impossible to work. I am in contact with the Hector support and with their computer they tried to run Cygwin under windows and connecting by ssh (exactly like I am doing) and they say that x-forwarding is fast. The performance they're seeing probably has little to do with their Cygwin version --- they're a lot closer, after all, so support's latency is probably a lot lower. NX actually works under Cygwin, though it's a pain to compile (and unsupported I imagine). This document provides an introduction to getting the system to work: http://www.nomachine.com/documentation/building-components.php -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On 18 August 2010 15:51, Rodrigo Medina wrote: After upgrading to cygwin17.6 the program run changes behavior. For example: If I start mintty with the followin .bat �...@echo off C: chdir \cygwin\bin run mintty -e '/bin/bash' --login -i exit In the mintty window that is started appears the following message: /bin/find: failed to restore initial working directory: No such file or directory You can invoke mintty with the cmd.exe built-in 'start' instead of 'run'. Even better, just invoke it directly from a shortcut rather than from a .bat script, which also avoids a console window flashing up briefly. The 'mintty' package in setup.exe automatically creates a suitable shortcut under Cygwin in the start menu. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: X-forwarding very very slow
On 8/18/2010 11:50 AM, Daniel Colascione wrote: On 8/18/10 8:43 AM, Alberto Canestrelli wrote: I have a problem with Cygwin. I am connecting from USA by ssh to the Hector supermachine in Edinburgh ( I write startx in Cygwin and then I use ssh -Y v1aca...@login.hector.ac.uk ). Everything works fine, the only problem is that the forwarding of the windows is very very slow. It takes sometimes also up to 5 minutes to open a new window. I am debugging a code with Totalview and it is a impossible to work. I am in contact with the Hector support and with their computer they tried to run Cygwin under windows and connecting by ssh (exactly like I am doing) and they say that x-forwarding is fast. The performance they're seeing probably has little to do with their Cygwin version --- they're a lot closer, after all, so support's latency is probably a lot lower. Agreed. I would point out, however, that the OPs Cygwin versions are pretty out-of-date as well. Though I'm not sure it will help in this particular matter, it's worth thinking about upgrading. -- 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? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: X-forwarding very very slow
On Wed, Aug 18, 2010 at 5:43 PM, Alberto Canestrelli wrote: Hi, I have a problem with Cygwin. I am connecting from USA by ssh to the Hector supermachine in Edinburgh ( I write startx in Cygwin and then I use ssh -Y v1aca...@login.hector.ac.uk ). Everything works fine, the only problem is that the forwarding of the windows is very very slow. Hi Alberto, It would be useful if you could try a non-Cygwin X server (e.g. a Linux or Solaris workstation). If X from under Linux appears fast, then the slowdown could be between your network card and display (probably Cygwin's fault). If X from Linux is also slow, the problem may be with the propagation of the X protocol between your network card and Hector (probably not Cygwin's fault) . -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On 8/18/2010 11:09 AM, Corinna Vinschen wrote: Looks like the run tool now needs a call to CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd)); and then use win32_cwd in the call to CreateProcess. See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api Yep. run2 also needs a similar update. Thanks for the heads up; I didn't really think about how the recent changes to cygwin's cwd handling would affect those two packages. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On 8/18/2010 10:12 AM, Charles Wilson wrote: On 8/18/2010 11:09 AM, Corinna Vinschen wrote: Looks like the run tool now needs a call to CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd)); and then use win32_cwd in the call to CreateProcess. See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api Yep. run2 also needs a similar update. Thanks for the heads up; I didn't really think about how the recent changes to cygwin's cwd handling would affect those two packages. I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. -- David Rothenberger daver...@acm.org micro: Thinker toys. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: endless problems with SSHD - bug ??
On 8/17/2010 Larry Hall wrote: On 8/17/2010 5:28 PM, Bob Goldberg wrote: I simply want to copy files from 1 pc to another using a script initiated by either a user or cron entry. Ideally this would happen using scp into a chroot'ed environment. chroot on Cygwin is completely faked. Don't use it. It will cause headaches. As for your problem with ssh command, you've apparently missed this appropriately titled tidbit in your googling: http://www.cygwin.com/ml/cygwin/2000-07/msg01050.html This may just be because you're trying to use 'rbash' as your login shell. I didn't test that theory. Larry - Tx much for your reply... well even if chroot is faked (not sure what that means) - I might still be inclined to use it... Unless - is there a way I can LIMIT activity to only scp? AND - prevent accessing outside what would be my jail? I certainly did miss that very well titled document - no wonder my searches were fruitless!! :-) I'll check to make sure the path is getting set correctly. Although, if I get scp running like I want, then I no longer need/care about resolving this problem TIA - Bob -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
ImageMagick: More insufficient package dependencies
My apologies to all the folks NOT involved in maintaining the ImageMagick package, but there doesn't appear to be any defined process for reporting bugs which might narrow down the attention-grab to a more relevant set of people. I had some insufficient package dependency problems wite ImageMagick a little while ago. Now I am getting some more. It seems that ImageMagick actually depends on some parts of X, but there is no relevant package dependency defined. ---8---snip-here--- $ convert /usr/bin/convert.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory $ cygcheck.exe convert Found: C:\cygwin\bin\convert.exe Found: C:\cygwin\bin\convert.exe Found: C:\Windows\system32\convert.exe Found: C:\cygwin\bin\convert.exe C:\cygwin\bin\convert.exe C:\cygwin\bin\cygwin1.dll C:\Windows\system32\ADVAPI32.DLL C:\Windows\system32\ntdll.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\RPCRT4.dll C:\cygwin\bin\cyggcc_s-1.dll C:\cygwin\bin\cygMagickCore-1.dll C:\cygwin\bin\cyggomp-1.dll C:\cygwin\bin\cygbz2-1.dll C:\cygwin\bin\cygfontconfig-1.dll C:\cygwin\bin\cygexpat-1.dll C:\cygwin\bin\cygfreetype-6.dll C:\cygwin\bin\cygz.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygltdl-7.dll C:\cygwin\bin\cygtiff-5.dll C:\cygwin\bin\cygjbig-2.dll C:\cygwin\bin\cygjpeg-7.dll C:\Windows\system32\GDI32.dll C:\Windows\system32\USER32.dll C:\cygwin\bin\cygMagickWand-1.dll cygcheck: track_down: could not find cygX11-6.dll cygcheck: track_down: could not find cygXext-6.dll cygcheck: track_down: could not find cygX11-6.dll ---8---snip-here--- Regards, Bill -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: endless problems with SSHD - bug ??
On 8/18/2010 1:27 PM, Bob Goldberg wrote: Larry - Tx much for your reply... well even if chroot is faked (not sure what that means) - I might still be inclined to use it... fake == it does nothing. chroot is barely more than an empty shell (no pun intended). You won't find anyone seriously recommending its use. Unless - is there a way I can LIMIT activity to only scp? AND - prevent accessing outside what would be my jail? I certainly did miss that very well titled document - no wonder my searches were fruitless!! :-) I'll check to make sure the path is getting set correctly. Although, if I get scp running like I want, then I no longer need/care about resolving this problem If you need to restrict access, your best bet is to use Windows permissions. -- 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? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ImageMagick: More insufficient package dependencies
I have now installed the packages libX11_6 and libXext6. ImageMagick's convert is now working. I suspect that the ImageMagick Cygwin package may need to be modified to make it depend on libX11_6 and libXext6. Bill -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 10:16:50AM -0700, David Rothenberger wrote: On 8/18/2010 10:12 AM, Charles Wilson wrote: On 8/18/2010 11:09 AM, Corinna Vinschen wrote: Looks like the run tool now needs a call to CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd)); and then use win32_cwd in the call to CreateProcess. See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api Yep. run2 also needs a similar update. Thanks for the heads up; I didn't really think about how the recent changes to cygwin's cwd handling would affect those two packages. I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Call me dense but I don't understand why any changes are needed. If you're cd'ed to a non-Cygwin-special location why doesn't stuff just work? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On 18 August 2010 18:16, David Rothenberger wrote: On 8/18/2010 10:12 AM, Charles Wilson wrote: On 8/18/2010 11:09 AM, Corinna Vinschen wrote: Looks like the run tool now needs a call to CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd)); and then use win32_cwd in the call to CreateProcess. See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api Yep. run2 also needs a similar update. Thanks for the heads up; I didn't really think about how the recent changes to cygwin's cwd handling would affect those two packages. I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Ouch. This might affect even more cygutils. We really should have thought of that. At least there aren't any chdir() calls in any of the cygutils, so it should primarily be a question of setting the Win32 current directory in line with the POSIX one at startup, in any of the utils that may invoke a Win32 function with a relative path. Chuck, do you need a hand with going through them? Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ImageMagick: More insufficient package dependencies
On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote: My apologies to all the folks NOT involved in maintaining the ImageMagick package, but there doesn't appear to be any defined process for reporting bugs which might narrow down the attention-grab to a more relevant set of people. Actually, this is the defined way to report bugs in a cygwin package. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On 18 August 2010 19:24, Christopher Faylor wrote: I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Call me dense but I don't understand why any changes are needed. If you're cd'ed to a non-Cygwin-special location why doesn't stuff just work? The Win32 working directory is changed to '\\?\PIPE\' at process startup, otherwise the working directory can't be deleted from under the process, which you can do on Linux. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs and DBUS
Ken Brown kbr...@cornell.edu writes: Yes, I've just checked that it builds with D-Bus. I'll upload a test release in a few days. BTW, the configure script gives the following warning: D-Bus integration has been tested for GNU/Linux only. So I don't know if it will work. This message is from me (I wrote the D-Bus integration for Emacs). It works for other Unices as well; if your test build runs also successfully, it might be time to remove the warning. Don't hesitate to contact me if you run into trouble. Ken Best regards, Michael. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On 8/18/2010 1:12 PM, Charles Wilson wrote:
On 8/18/2010 11:09 AM, Corinna Vinschen wrote:
Looks like the run tool now needs a call to
CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd));
and then use win32_cwd in the call to CreateProcess.
See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api
Yep. run2 also needs a similar update.
Thanks for the heads up; I didn't really think about how the recent
changes to cygwin's cwd handling would affect those two packages.
The following patch seems to fix it for me. There will still be problems
if the win32-converted cwd is (a) longer than 259 chars, or (b) derived
from a cygwin-specific virtual path.
I don't want to duplicate all of cygwin's spawn_guts functionality in
run, run2, and cygstart, so I think (a) and (b) are acceptable. After
all, USUALLY you will invoke these tools via double-clicking some
icon...so cygwin-specific or too-long paths are not an issue.
--
Chuck
Index: src/run.c
===
RCS file: /cvs/cygwin-apps/run/src/run.c,v
retrieving revision 1.10
diff -u -p -r1.10 run.c
--- src/run.c 2 Dec 2009 02:51:54 - 1.10
+++ src/run.c 18 Aug 2010 18:35:47 -
@@ -198,6 +198,33 @@ WinMain (HINSTANCE hSelf, HINSTANCE hPre
{
STARTUPINFO start;
PROCESS_INFORMATION child;
+#if defined(__CYGWIN__)
+ /* Special CWD handling needed when calling CreateProcess() from a
+ * cygwin program, when cygwin kernel is 1.7.6 or above. See
discussion
+ * in the following threads:
+ * http://cygwin.com/ml/cygwin/2010-08/msg00205.html
+ * http://cygwin.com/ml/cygwin-developers/2010-08/msg2.html
+ */
+ char * win32_cwd;
+ long size;
+ char *posix_buf;
+ char *posix_cwd = NULL;
+ size = pathconf(., _PC_PATH_MAX);
+ if ((posix_buf = (char *)malloc((size_t)size)) != NULL)
+ {
+ posix_cwd = getcwd(posix_buf, (size_t)size);
+ if (posix_cwd)
+ {
+# if defined(HAVE_DECL_CYGWIN_CONV_PATH)
+ win32_cwd = (char *) cygwin_create_path
(CCP_POSIX_TO_WIN_A, (void *) posix_cwd);
+# else
+ win32_cwd = (char *) malloc (MAX_PATH);
+ if (win32_cwd)
+ cygwin_conv_to_win32_path (posix_cwd, win32_cwd);
+# endif
+ }
+ }
+#endif
ZeroMemory( child, sizeof(PROCESS_INFORMATION) );
ZeroMemory (start, sizeof (STARTUPINFO));
start.cb = sizeof (STARTUPINFO);
@@ -209,9 +236,26 @@ WinMain (HINSTANCE hSelf, HINSTANCE hPre
FALSE, /* handles are NOT inherited, */
0, /* creation flags */
NULL,/* use parent's environment*/
- NULL,/* use parent's current directory */
+#if defined(__CYGWIN__)
+ win32_cwd, /* working directory; may be null*/
+#else
+ NULL,/* use parent's working directory */
+#endif
start, /* STARTUPINFO pointer */
child); /* receives PROCESS_INFORMATION*/
+#if defined(__CYGWIN__)
+ if (win32_cwd)
+ {
+ free (win32_cwd);
+ win32_cwd = NULL;
+ }
+ if (posix_buf)
+ {
+ free (posix_buf);
+ posix_buf = NULL;
+ posix_cwd = NULL;
+ }
+#endif
if (ret_code == 0)
{
Trace((getlasterror: %d\n, GetLastError()));
run.exe.bz2
Description: Binary data
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 07:32:40PM +0100, Andy Koppe wrote: On 18 August 2010 19:24, Christopher Faylor wrote: I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Call me dense but I don't understand why any changes are needed. ??If you're cd'ed to a non-Cygwin-special location why doesn't stuff just work? The Win32 working directory is changed to '\\?\PIPE\' at process startup, otherwise the working directory can't be deleted from under the process, which you can do on Linux. Yes, I guess I did not properly appreciate the fact that we presumably broke every CreateProcess call in a cygwin program when we did this. While I'm on record about not caring too much about that scenario, it seems meaner than usual for us to break this since the report which caused the recent change was from someone calling CreateProcess in a cygwin program. But, anyway, since we have broken this, I don't think we should force every user of CreateProcess to call CYGWIN_CONV_TO_POSIX_PATH. We probably should add an internal interface which sets the current working directory for windows if it can. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On 8/18/2010 2:25 PM, Andy Koppe wrote: Ouch. This might affect even more cygutils. We really should have thought of that. At least there aren't any chdir() calls in any of the cygutils, so it should primarily be a question of setting the Win32 current directory in line with the POSIX one at startup, in any of the utils that may invoke a Win32 function with a relative path. Chuck, do you need a hand with going through them? Oh, right. The problem is this: since the win32 CWD is *always* bogus, it is possible that other win32 functions will croak, not just CreateProcess. So, there are a number of native win32 calls in the cygutils tools, like: cygstart: CreateProcess, among others lpr: ...many... putclip/getclip: GetClipboardData, SetClipboardData, etc Now, I haven't tested each of these tools exhaustively under cygwin-1.7.6, so I'm not sure the bogus win32 cwd affects them (except obviously cygstart). But...by their very nature many of these tools use the native w32api. So...each should probably take care to set the win32 cwd if at all possible. Yeah, patches would be great. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs and DBUS
On 8/18/2010 2:43 PM, Michael Albinus wrote: Ken Brown writes: Yes, I've just checked that it builds with D-Bus. I'll upload a test release in a few days. BTW, the configure script gives the following warning: D-Bus integration has been tested for GNU/Linux only. So I don't know if it will work. This message is from me (I wrote the D-Bus integration for Emacs). It works for other Unices as well; if your test build runs also successfully, it might be time to remove the warning. Don't hesitate to contact me if you run into trouble. Thanks, Michael. I don't use D-BUS myself, but I hope the OP will test it and report back. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Aug 18 14:54, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 07:32:40PM +0100, Andy Koppe wrote: On 18 August 2010 19:24, Christopher Faylor wrote: I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Call me dense but I don't understand why any changes are needed. ??If you're cd'ed to a non-Cygwin-special location why doesn't stuff just work? The Win32 working directory is changed to '\\?\PIPE\' at process startup, otherwise the working directory can't be deleted from under the process, which you can do on Linux. Yes, I guess I did not properly appreciate the fact that we presumably broke every CreateProcess call in a cygwin program when we did this. While I'm on record about not caring too much about that scenario, it seems meaner than usual for us to break this since the report which caused the recent change was from someone calling CreateProcess in a cygwin program. But, anyway, since we have broken this, I don't think we should force every user of CreateProcess to call CYGWIN_CONV_TO_POSIX_PATH. We probably should add an internal interface which sets the current working directory for windows if it can. I'm going to add a new call cygwin_internal (CW_SYNC_WINCWD); which will do the same for the CWD as cygwin_internal (CW_SYNC_WINENV); already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. However, in contrast to CW_SYNC_WINENV, CW_SYNC_WINCWD will return -1 and set errno if setting a Windows CWD fails. The error codes will be typically ENOTDIR if the CWD is a virtual directory EACCESif the directory is actually inaccessible or ENAMETOOLONG if the directory has a pathname 258 chars. I'll also add documentation for this. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 09:13:40PM +0200, Corinna Vinschen wrote: On Aug 18 14:54, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 07:32:40PM +0100, Andy Koppe wrote: On 18 August 2010 19:24, Christopher Faylor wrote: I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Call me dense but I don't understand why any changes are needed. ??If you're cd'ed to a non-Cygwin-special location why doesn't stuff just work? The Win32 working directory is changed to '\\?\PIPE\' at process startup, otherwise the working directory can't be deleted from under the process, which you can do on Linux. Yes, I guess I did not properly appreciate the fact that we presumably broke every CreateProcess call in a cygwin program when we did this. While I'm on record about not caring too much about that scenario, it seems meaner than usual for us to break this since the report which caused the recent change was from someone calling CreateProcess in a cygwin program. But, anyway, since we have broken this, I don't think we should force every user of CreateProcess to call CYGWIN_CONV_TO_POSIX_PATH. We probably should add an internal interface which sets the current working directory for windows if it can. I'm going to add a new call cygwin_internal (CW_SYNC_WINCWD); which will do the same for the CWD as cygwin_internal (CW_SYNC_WINENV); Actually I just checked in CW_SETCWD which just calls SetCurrentDirectoryW. I was just going to request trying a snapshot when I saw your message. already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs and DBUS
Ken Brown kbr...@cornell.edu writes: Thanks, Michael. I don't use D-BUS myself, but I hope the OP will test it and report back. It's some years ago I have used Cygwin. But if you have uploaded the build already, I could check, whether I have problems running Emacs + D-Bus under Cygwin. Ken Best regards, Michael. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Aug 18 15:19, Christopher Faylor wrote:
On Wed, Aug 18, 2010 at 09:13:40PM +0200, Corinna Vinschen wrote:
I'm going to add a new call
cygwin_internal (CW_SYNC_WINCWD);
which will do the same for the CWD as
cygwin_internal (CW_SYNC_WINENV);
Actually I just checked in CW_SETCWD which just calls
SetCurrentDirectoryW. I was just going to request trying a snapshot
when I saw your message.
Oh. Shouldn't SetCurrentDirectoryW only be called if cygheap-cwd.get_error
is 0? Here's what I had in mind:
Index: external.cc
===
RCS file: /cvs/src/src/winsup/cygwin/external.cc,v
retrieving revision 1.116
diff -u -p -r1.116 external.cc
--- external.cc 4 Jul 2010 17:12:26 - 1.116
+++ external.cc 18 Aug 2010 19:37:33 -
@@ -162,6 +162,24 @@ sync_winenv ()
free (envblock);
}
+/* Synchronize Win32 CWD with Cygwin CWD. Return -1 and set errno if
+ setting the Win32 CWD fails. */
+static unsigned long
+sync_wincwd ()
+{
+ if (cygheap-cwd.get_error ())
+{
+ set_errno (cygheap-cwd.get_error ());
+ return (unsigned long) -1;
+}
+ if (!SetCurrentDirectoryW (cygheap-cwd.win32.Buffer))
+{
+ __seterrno ();
+ return (unsigned long) -1;
+}
+ return 0;
+}
+
/*
* Cygwin-specific wrapper for win32 ExitProcess and TerminateProcess.
* It ensures that the correct exit code, derived from the specified
@@ -514,6 +532,9 @@ cygwin_internal (cygwin_getinfo_types t,
res = (uintptr_t) strerror (err);
}
break;
+ case CW_SYNC_WINCWD:
+ res = sync_wincwd ();
+ break;
default:
set_errno (ENOSYS);
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 09:34:46PM +0200, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, the current change affects every one of those programs and more. And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Yes. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Aug 18 21:34, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. Chuck, btw., the function setup_win_environ() in run.c can easily be replaced with `cygwin_internal (CW_SYNC_WINENV);' Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On 18 August 2010 20:39, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 09:34:46PM +0200, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, the current change affects every one of those programs and more. Right, that's a pretty big argument for favouring Windows integration rather than Linux compatibility here. So what would be the consequences of not allowing the current working directory of a running process to be deleted? And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Yes. I'm not convinced such a compromise would be worthwhile, because it would forfeit Linux compatibility while still breaking some Win32-using programs. I think it should be one way or the other: either stick with the current approach, or always sync the Win32 working directory up-to-date (except when that's not possible). Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Wed, 18 Aug 2010, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Can someone please remind me why you shouldn't change to that directory only when SetCurrentDirectory would fail due to a long path, virtual path, etc? I think it was covered in the developer list, but I can't find it right now. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On 8/18/2010 3:41 PM, Corinna Vinschen wrote: Chuck, btw., the function setup_win_environ() in run.c can easily be replaced with `cygwin_internal (CW_SYNC_WINENV);' Yes, I was just looking at that. I think setup_win_environ (or its guts before some early refactoring) pre-dated CW_SYNC_WINENV. Before removing it, I'll have to verify some things -- like whether that-cygwin-fork-we-don't-mention has CW_SYNC_WINENV, and how hard it would be to add if not -- since I want run to work over there too. With respect to the orginal discussion that spawned this thread, I'm going to hold off on any changes to run/run2/cygutils until a consensus is reached regarding: 1) what's going to happen inside cygwin wrt win32 cwd; 2) what new APIs are provided 3) and a project on how soon an official 1.7.7 will be released with those changes and then evaluate how best to modify the client apps. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Aug 18 20:47, Andy Koppe wrote: On 18 August 2010 20:39, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 09:34:46PM +0200, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, the current change affects every one of those programs and more. Right, that's a pretty big argument for favouring Windows integration rather than Linux compatibility here. So what would be the consequences of not allowing the current working directory of a running process to be deleted? And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Yes. I'm not convinced such a compromise would be worthwhile, because it would forfeit Linux compatibility while still breaking some Win32-using programs. I think it should be one way or the other: either stick with the current approach, or always sync the Win32 working directory up-to-date (except when that's not possible). The question here is a bit tricky, me thinks. 1) Do we want as much POSIX compatibility as possible? 2) Do we want POSIX compatibility but not compromise on Win32 compatibility? 3) Do we want as much POSIX compatibility as possible, but are willing to compromise if it breaks backward compatibility in the Win32 realms? Right now I tend strongly to 1, but I'm still open to 3 if the problems are really too heavy. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Wed, 18 Aug 2010, Brian Ford wrote: Can someone please remind me why you shouldn't change to that directory only when SetCurrentDirectory would fail due to a long path, virtual path, etc? I think it was covered in the developer list, but I can't find it right now. Nevermind, sigh... -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On 08/18/2010 01:55 PM, Corinna Vinschen wrote: I'm not convinced such a compromise would be worthwhile, because it would forfeit Linux compatibility while still breaking some Win32-using programs. I think it should be one way or the other: either stick with the current approach, or always sync the Win32 working directory up-to-date (except when that's not possible). The question here is a bit tricky, me thinks. 1) Do we want as much POSIX compatibility as possible? POSIX allows the refusal to delete an in-use directory; and Solaris NFS mounts behave this way. But since Linux can delete in-use directories (where an in-use directory includes the condition of at least one process owning that directory as its cwd), and cygwin emulates Linux rather than POSIX, we can try harder if it makes sense. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: run changes behavior with cygwin-17.6
On Aug 18 14:49, Brian Ford wrote: On Wed, 18 Aug 2010, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Can someone please remind me why you shouldn't change to that directory only when SetCurrentDirectory would fail due to a long path, virtual path, etc? I think it was covered in the developer list, but I can't find it right now. It breaks POSIX compatibility in terms of not being able to rename or delete a directory which is the CWD of any process. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On 08/18/2010 01:58 PM, Corinna Vinschen wrote: Can someone please remind me why you shouldn't change to that directory only when SetCurrentDirectory would fail due to a long path, virtual path, etc? I think it was covered in the developer list, but I can't find it right now. It breaks POSIX compatibility in terms of not being able to rename or delete a directory which is the CWD of any process. It breaks Linux, but not POSIX, compatibility. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: run changes behavior with cygwin-17.6
On Aug 18 15:51, Charles Wilson wrote: On 8/18/2010 3:41 PM, Corinna Vinschen wrote: Chuck, btw., the function setup_win_environ() in run.c can easily be replaced with `cygwin_internal (CW_SYNC_WINENV);' Yes, I was just looking at that. I think setup_win_environ (or its guts before some early refactoring) pre-dated CW_SYNC_WINENV. Before removing it, I'll have to verify some things -- like whether that-cygwin-fork-we-don't-mention has CW_SYNC_WINENV, and how hard it would be to add if not -- since I want run to work over there too. CW_SYNC_WINENV is available since May 2006. That's Cygwin 1.5.20-1. With respect to the orginal discussion that spawned this thread, I'm going to hold off on any changes to run/run2/cygutils until a consensus is reached regarding: 1) what's going to happen inside cygwin wrt win32 cwd; I'm not sure yet. Maybe we should really go cgf's idea to stick to the Win32 CWD, as long as chdir isn't called the first time. 2) what new APIs are provided In PM we agreed on my suggestion. I just have to test and document it first... 3) and a project on how soon an official 1.7.7 will be released with those changes I think 1.7.7 will be released rather very soon. Maybe this weekend. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Aug 18 13:57, Eric Blake wrote: On 08/18/2010 01:55 PM, Corinna Vinschen wrote: I'm not convinced such a compromise would be worthwhile, because it would forfeit Linux compatibility while still breaking some Win32-using programs. I think it should be one way or the other: either stick with the current approach, or always sync the Win32 working directory up-to-date (except when that's not possible). The question here is a bit tricky, me thinks. 1) Do we want as much POSIX compatibility as possible? POSIX allows the refusal to delete an in-use directory; and Solaris NFS mounts behave this way. But since Linux can delete in-use directories (where an in-use directory includes the condition of at least one process owning that directory as its cwd), and cygwin emulates Linux rather than POSIX, we can try harder if it makes sense. That lets me more tend to 3 now (cgf's idea to defer until the first chdir). I'm still chewing nails, though. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Upgrading to cygwin 1.7.6 vs gcc 4.5
On 18 August 2010 06:25, Andy Koppe wrote: On 18 August 2010 00:09, Eric Blake wrote: On 08/17/2010 04:54 PM, Ross Smith wrote: I've installed the experimental gcc 4.5 packages (because that's the version I'm using in all my other development environments, and it's nice not to have to target multiple compiler versions any more), but now that cygwin dll 1.7.6 is out, I can't seem to find a way to upgrade cygwin without also downgrading gcc. In the installer, if I select Current I get the new cygwin but the old gcc, while if I select Experimental, it keeps the new gcc but doesn't offer me the new cygwin. At the moment I'm sticking with the old cygwin, because the gcc upgrade is more important to me than the cygwin upgrade. Is there some way I'm missing to select both, or do I just have to accept that I can't upgrade anything else until the official gcc 4.5 is ready? Stay on the 'Curr' (not 'Exp'), click 'View' until you are on the Pending page, then cycle on the string next to each gcc package until it says Keep instead of the downgraded version number. I'd recommend selecting the 'Exp' button actually. That ensures that all dependencies of gcc, e.g. libgcc and libffi, are upgraded to 4.5 too. (It's yet another flaw of setup.exe that it doesn't automatically upgrade dependencies of experimental versions accordingly.) Scratch that. I hadn't realised that if you select 'Exp', non-experimental packages no longer get updated, which of course is exactly what the OP was saying. This is awful. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ImageMagick: More insufficient package dependencies
On 18/08/2010 19:26, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote: My apologies to all the folks NOT involved in maintaining the ImageMagick package, but there doesn't appear to be any defined process for reporting bugs which might narrow down the attention-grab to a more relevant set of people. Actually, this is the defined way to report bugs in a cygwin package. A I see. It's /defined/ to be mediocre. Rather than attempting to solve the problem head-on, redefine the problem domain so that the problem is already solved. Inspired. Bill -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ImageMagick: More insufficient package dependencies
On Wed, Aug 18, 2010 at 09:32:50PM +0100, William Blunn wrote: On 18/08/2010 19:26, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote: My apologies to all the folks NOT involved in maintaining the ImageMagick package, but there doesn't appear to be any defined process for reporting bugs which might narrow down the attention-grab to a more relevant set of people. Actually, this is the defined way to report bugs in a cygwin package. A I see. It's /defined/ to be mediocre. For *you*, since you've decided to be insulting, you can actually expect less-than-mediocre handling of your problems, this being a volunteer process and human nature being what it is and all. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ImageMagick: More insufficient package dependencies
On Aug 18 21:32, William Blunn wrote: On 18/08/2010 19:26, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote: My apologies to all the folks NOT involved in maintaining the ImageMagick package, but there doesn't appear to be any defined process for reporting bugs which might narrow down the attention-grab to a more relevant set of people. Actually, this is the defined way to report bugs in a cygwin package. A I see. It's /defined/ to be mediocre. Rather than attempting to solve the problem head-on, redefine the problem domain so that the problem is already solved. Inspired. Is there something in the water lately, which makes people on the list more aggressive than usual? It hasn't been redefined at all. It's the common way of reporting problems for a long time: http://cygwin.com/problems.html If you don't like it, I'm sorry. Are you going to volunteer to maintain a Cygwin packages bug-tracking system? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ImageMagick: More insufficient package dependencies
On 18 August 2010 21:50, Corinna Vinschen wrote: On Aug 18 21:32, William Blunn wrote: On 18/08/2010 19:26, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote: My apologies to all the folks NOT involved in maintaining the ImageMagick package, but there doesn't appear to be any defined process for reporting bugs which might narrow down the attention-grab to a more relevant set of people. Actually, this is the defined way to report bugs in a cygwin package. A I see. It's /defined/ to be mediocre. Rather than attempting to solve the problem head-on, redefine the problem domain so that the problem is already solved. Inspired. Is there something in the water lately, which makes people on the list more aggressive than usual? It hasn't been redefined at all. It's the common way of reporting problems for a long time: http://cygwin.com/problems.html If you don't like it, I'm sorry. Are you going to volunteer to maintain a Cygwin packages bug-tracking system? Besides, thanks to the magic of mail filters, grabbing the attention of a package maintainer isn't the problem anyway. The issue is whether there's an active maintainer in the first place. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs and DBUS
On 8/18/2010 3:19 PM, Michael Albinus wrote: Ken Brownkbr...@cornell.edu writes: Thanks, Michael. I don't use D-BUS myself, but I hope the OP will test it and report back. It's some years ago I have used Cygwin. But if you have uploaded the build already, I could check, whether I have problems running Emacs + D-Bus under Cygwin. Yes, it's uploaded. See http://cygwin.com/ml/cygwin-announce/2010-08/msg00020.html Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: X-forwarding very very slow
On 8/18/2010 11:55 AM, Csaba Raduly wrote: On Wed, Aug 18, 2010 at 5:43 PM, Alberto Canestrelli wrote: Hi, I have a problem with Cygwin. I am connecting from USA by ssh to the Hector supermachine in Edinburgh ( I write startx in Cygwin and then I use ssh -Y v1aca...@login.hector.ac.uk ). Everything works fine, the only problem is that the forwarding of the windows is very very slow. Hi Alberto, It would be useful if you could try a non-Cygwin X server (e.g. a Linux or Solaris workstation). If X from under Linux appears fast, then the slowdown could be between your network card and display (probably Cygwin's fault). If X from Linux is also slow, the problem may be with the propagation of the X protocol between your network card and Hector (probably not Cygwin's fault) . You could also try enabling compression with -C. I have found this to be a necessity when connecting with X over ssh between work and home even though the locations are quite near each other and plain text based ssh access runs fine without the compression. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Postinstall for mintty fails when installing just for me
Corinna Vinschen sent the following at Wednesday, August 18, 2010 4:43 AM That usually just means you don't have admin privs. For the archive: That is indeed the case. Here's the actual problem: cygdrive prefix / system binary,noacl,posix=0,auto The cygdrive prefix is set to the mount option noacl. So the output from getfacl or ls or stat for this directory shows just fake permissions based on the DOS R/O flag. You're not an admin, so you're not allowed to write to this directory, see the cacls output. However, since the cygdrive prefix is mounted with noacl, Cygwin tools just don't know it. With acl, I had been getting annoying error messages about copying permissions with cp -p on some network drives, so I switched everything to noacl. I'll try switching back to acl, testing for error messages, and going to noacl only on drives that seem to have problems. Thanks for your input. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: run changes behavior with cygwin-17.6
On 8/18/10 1:19 PM, Corinna Vinschen wrote: POSIX allows the refusal to delete an in-use directory; and Solaris NFS mounts behave this way. What about renaming directories though? (Damn this tight coupling Windows has between files and filenames.) But since Linux can delete in-use directories Not just Linux -- OS X and the other BSDs too, presumably, allow renaming and deleting directories that are the CWD of some process. (where an in-use directory includes the condition of at least one process owning that directory as its cwd), and cygwin emulates Linux rather than POSIX, we can try harder if it makes sense. That lets me more tend to 3 now (cgf's idea to defer until the first chdir). I'm still chewing nails, though. IMVHO, #1 is the right choice. It's a lot less surprising than #3, and it fails safe. It's a very simple model: relative filename use will fail unless you do something special, and by doing something special, you signify that you understand the magic. I can imagine #3 causing subtle bugs in programs that only chdir() sometimes. Using Win32 functions in a Cygwin program already requires extra knowledge; adding CWD tracking doesn't hurt much. The other crazy idea would be to override the Win32 file and path functions and handle the notion of a current directory entirely within Cygwin for both Win32 and Cygwin functions, but IIRC, playing games with Windows API functions was explicitly rejected a while ago. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:16 AM What changed since Cygwin 1.7.5: - Cygwin handles the current working directory entirely on its own. The Win32 current working directory is set to an invalid path to be out of the way. This affects calls to the Win32 file API (CreateFile, etc.). See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api ^ In case you ever copy and paste the link, htdocs/ needs to be deleted for it to work. Thanks for all you do for the cygwin community. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
RE: endless problems with SSHD - bug ??
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com]on Behalf Of Larry Hall (Cygwin) Sent: Wednesday, August 18, 2010 1:04 PM To: cygwin@cygwin.com Subject: Re: endless problems with SSHD - bug ?? On 8/18/2010 1:27 PM, Bob Goldberg wrote: Unless - is there a way I can LIMIT activity to only scp? AND - prevent accessing outside what would be my jail? I certainly did miss that very well titled document - no wonder my searches were fruitless!! :-) I'll check to make sure the path is getting set correctly. Although, if I get scp running like I want, then I no longer need/care about resolving this problem If you need to restrict access, your best bet is to use Windows permissions. = OK Larry, 'nuf said on the sshd chroot :o) permissions - no problem - got that covered already STILL - can NOT get scp to work to save my life. AFAIK - path DOES look good according to debug info. i've changed my shell back to /bin/bash to eliminate that variable. relevant reminders: using cygwin 1.7.6 on win2k; using RSA-keys for auth $ ssh a...@cappy # WORKS GREAT (no typing - RSA auth works) $ ssh a...@cappy echo hello # fails in same manner as scp below and so my scp command continues to give: BEGIN screen dump $ scp puttest.txt a...@cappy:~/ debug1: permanently_set_uid: 3945/514 debug3: Copy environment: ALLUSERSPROFILE=C:\\Documents and Settings\\All Users debug3: Copy environment: COMPUTERNAME=CAPPY debug3: Copy environment: COMSPEC=C:\\WINNT\\system32\\cmd.exe debug3: Copy environment: OS=Windows_NT debug3: Copy environment: PATH=/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cyg drive/c/WINNT/System32/Wbem:/cygdrive/c/Program Files/Symantec/pcAnywhere/:/bin debug3: Copy environment: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.W SH debug3: Copy environment: SYSTEMDRIVE=C: debug3: Copy environment: SYSTEMROOT=C:\\WINNT debug3: Copy environment: WINDIR=C:\\WINNT debug3: Copy environment: CYGWIN=ntsec getsockname failed: Socket operation on non-socket getsockname failed: Socket operation on non-socket Environment: ALLUSERSPROFILE=C:\Documents and Settings\All Users COMPUTERNAME=CAPPY COMSPEC=C:\WINNT\system32\cmd.exe OS=Windows_NT PATH=/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32 /W bem:/cygdrive/c/Program Files/Symantec/pcAnywhere/:/bin PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH SYSTEMDRIVE=C: SYSTEMROOT=C:\WINNT WINDIR=C:\WINNT CYGWIN=ntsec USER=als LOGNAME=als HOME=/home/chroot/home/als MAIL=/var/spool/mail/als SHELL=/bin/bash SSH_CLIENT=192.168.1.156 3824 0 SSH_CONNECTION=192.168.1.156 3824 UNKNOWN 0 debug3: channel 0: close_fds r -1 w -1 e -1 1096 [main] sshd 1960 E:\cygwin\usr\sbin\sshd.exe: *** fatal error - could no t load user32, Win32 error 1114 Stack trace: Frame Function Args 00229E84 61004ADB (61177840, 8000, , 61178977) 0022AEB4 61004ADB (61178084, 61161E4C, 61161E4C, 0022AFA0) 0022AEE4 61001325 (61030A0B, 6123D224, 0022AF50, 0022AF18) 0022BBC8 6115764C (0003, , , 61117A22) 0022BC08 610CADE3 (0003, 006BBAC8, 0022BD0C, 006C2998) 0022BC28 6102952B (006BBAC8, 0022BD0C, 006C2998, 6115F410) 0022C148 610BFEA5 (006BB1F8, 0069B2C0, 0002, 0001) 0022C198 00412D4B (006BB1F8, 0069B2C0, 006BB1F8, 00427EA2) 0022C1C8 004130F4 (006BB1F8, 0069B2C0, 006BF218, 006B290C) 0022C288 0041343C (006BF258, 006BF218, 006BF218, 0001) 0022C2C8 0040AAF3 (0062, 000A, 006BCC38, 0040BB05) 0022C308 004389D6 (0001, , 006BCC38, 0040C6FA) 0022C348 0040BC6A (006C2D48, 006BBA30, 0022C388, 00417DF6) 0022C388 00413CCE (006C2D48, 0003, , 0022CC44) 0022CD58 004040F3 (, , 0022CD98, 61006C53) 0022CD98 61006C53 (, 0022CDD4, 610064F0, 7FFDF000) End of stack trace (more stack frames may be present) lost connection END screen dump and as I finish this - just had a h... having cygwin installed on non- C: isn't a problem - is it?? TIA (again :) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
All scripts in /etc/postinstall have wrong filetype
After running Cygwin setup to update my Cygwin install, I got a popup error, so I looked in /var/log/setup.log. (BTW, it would be very helpful for the popup to say Check /var/log/setup.log instead of Check setup.log.) setup.log said, among other things: 2010/08/16 00:50:22 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/update-info-dir.sh 2010/08/16 00:50:30 can't run /etc/postinstall/update-info-dir.sh: No such file 2010/08/16 00:50:30 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/bash.sh 2010/08/16 00:50:30 can't run /etc/postinstall/bash.sh: No such file 2010/08/16 00:50:30 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/docbook-xml42.sh 2010/08/16 00:50:30 abnormal exit: exit code=1 I looked in C:/cygwin/etc/postinstall. Every single script there had .done appended to its name, eg bash.sh = bash.sh.done Hence none of the scripts could be run. This is on Windows XP SP3, with an AMD64. I think I downloaded files from ftp://mirror.cs.vt.edu, or possibly ftp.gtlib.gatech.edu . -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: All scripts in /etc/postinstall have wrong filetype
On 19 August 2010 04:50, Phil Goetz wrote: After running Cygwin setup to update my Cygwin install, I got a popup error, so I looked in /var/log/setup.log. (BTW, it would be very helpful for the popup to say Check /var/log/setup.log instead of Check setup.log.) Yep. That's already fixed in CVS. setup.log said, among other things: 2010/08/16 00:50:22 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/update-info-dir.sh 2010/08/16 00:50:30 can't run /etc/postinstall/update-info-dir.sh: No such file 2010/08/16 00:50:30 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/bash.sh 2010/08/16 00:50:30 can't run /etc/postinstall/bash.sh: No such file 2010/08/16 00:50:30 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/docbook-xml42.sh 2010/08/16 00:50:30 abnormal exit: exit code=1 I looked in C:/cygwin/etc/postinstall. Every single script there had .done appended to its name, eg bash.sh = bash.sh.done Hence none of the scripts could be run. The .done is appended after a script has been run successfully. So the question is why it tried to run scripts that had been run already. Could you attach the log? Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Curious behavior of fifo on cygwin 1.7.5
Hi, Thanks for your answer . In order to have the standard behavior, I open/close the filedescriptor before/after each read as in the attached code and it seems to work Regards, Etienne Carrière 2010/8/17 Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com: On Tue, Aug 17, 2010 at 07:25:25PM +0200, Etienne Carriere wrote: Hello, I currently have a curious behavior with fifo (named pipes on cygwin 1.7.5) . I first discovered when using Nagios on cygwin but I achieved to simplify it . The scenario is the following : If you search the mailing list archives, you'll see a fair number of problems with fifos and you'll also see my acknowledgement of same. fifos in Cygwin are a work-in-progress and are not guaranteed to work like their linux counterparts. I do poke at them from time to time but, for now, you'll have to consider them to be as-is. That means that some things are broken. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple consume_fifo_workaround.c Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated [experimental]: {emacs,emacs-X11,emacs-el}-23.2-2
New releases of the emacs, emacs-X11, and emacs-el packages (23.2-2) are now available as experimental packages. These are rebuilds of the 23.2-1 packages, with D-BUS support. You will need to install libdbus1_3 in order to run the new binaries. Please report any regressions. If nothing serious is reported, the new releases will be promoted to current in a few weeks. CYGWIN NOTES There is a known bug in the cygwin build of emacs, which affects emacs functions like display-time. See /usr/share/doc/Cygwin/emacs.README for details and a simple workaround. Install the emacs-X11 package if you want to use the X11 GUI. You can then type 'emacs' in an xterm window, and emacs will start in a new window. If you run emacs in the cygwin console, be sure that your CYGWIN environment variable (http://cygwin.com/cygwin-ug-net/setup-env.html) contains tty. The script /usr/bin/make-emacs-shortcut can be used to create a shortcut for starting emacs. The shortcut starts emacs under X if an X server is running and in a mintty window otherwise. Edit the shortcut and/or the script if you want different behavior. You will need the cygutils package to run the script, and you will need mintty and run2 to use the shortcut. In addition, the user who runs the script needs to be able to write to /usr/local/bin. EMACS NEWS == See http://www.gnu.org/software/emacs/ for a summary of new features since Emacs 23.1. You can also use the command 'C-h n' within emacs to browse the NEWS file. DESCRIPTION === Emacs is a powerful, customizable, self-documenting, modeless text editor. Emacs contains special code editing features, a scripting language (elisp), and the capability to read mail, news, and more without leaving the editor. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then run setup and answer all the questions. Ken Brown Cygwin emacs maintainer *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL.
