Re: Who's using CYGWIN=tty and why?
On Wed, May 11, 2011 at 18:34, Corinna Vinschen wrote: On May 10 17:17, Len Giambrone wrote: We use windows native jam which spawns any number of cmd, cygwin, or studio processes. If we spawn it from a Cygwin terminal that doesn't have CYGWIN=tty set, we get: I assume that most people, like me, don't even know what jam is. At the risk of confusing the issue if I'm mistaken: jam - Just Another Make http://www.perforce.com/jam/jam.html -- David. -- 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: Python: subprocess running rsync causes broken socket in telnetlib
On Fri, Nov 12, 2010 at 16:19, David Antliff wrote:
I'm reporting a problem I see on Cygwin because I do not see the same
behaviour on Ubuntu Linux - both systems are running Python 2.6.5.
I have a script that opens a long-term telnet connection (telnetlib)
to a remote host. There is an object called Telnet().socket that is
created and represents an active socket connection to the remote host,
once the right telnetlib calls are made.
Then the script uses subprocess to do something else (the line is
actually longer than this but I've simplified it to the most basic
version that exhibits the problem):
process = subprocess.Popen(rsync, stdout=subprocess.PIPE)
On Cygwin 1.7.7, this does something nasty to the completely unrelated
yet existing telnetlib socket so that any further attempts to read or
write from this socket raise an exception:
File /usr/lib/python2.6/telnetlib.py, line 280, in write
self.sock.sendall(buffer)
File string, line 1, in sendall
socket.error: [Errno 32] Broken pipe
On Linux, this doesn't happen at all.
I've tried a few other programs via subprocess like cat and ssh
but they don't seem to cause this problem - only rsync does so far.
There may be others but I haven't found them.
If anyone is prepared to look into this I have attached a small python
script (bug.py) that demonstrates the problem. The error returned in
this case is 113: Software caused connection abort, but the end
result is the same - the socket is broken by the call to subprocess
rsync:
$ python bug.py
('telnet', '220 mx.google.com ESMTP w42sm3212723wfh.15\r\n')
('ssh', 0, 'OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010\n')
('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n')
('rsync', 0, 'rsync version 3.0.7 protocol version 30\nCopyright (C) 1996')
Traceback (most recent call last):
File bug.py, line 38, in module
print(telnet, t.read_eager())
File /usr/lib/python2.6/telnetlib.py, line 370, in read_eager
self.fill_rawq()
File /usr/lib/python2.6/telnetlib.py, line 516, in fill_rawq
buf = self.sock.recv(50)
socket.error: [Errno 113] Software caused connection abort
If you edit the script and set 'crash' to False, you'll see that the
script completes without error:
$ python bug.py
('telnet', '220 mx.google.com ESMTP i16sm3108013ibl.0\r\n')
('ssh', 0, 'OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010\n')
('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n')
('telnet', '250-SIZE 35651584\r\n250-8BITMIME\r\n250-STARTTLS\r\n250')
And on Linux:
$ python bug.py
('telnet', '220 mx.google.com ESMTP i16sm3106343ibl.18\r\n')
('ssh', 0, 'OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009\n')
('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n')
('rsync', 0, 'rsync version 3.0.7 protocol version 30\nCopyright (C) 1996')
('telnet', '250-SIZE 35651584\r\n250-8BITMIME\r\n250-STARTTLS\r\n250')
This bug is still present in Cygwin 1.7.8:
$ uname -a
CYGWIN_NT-5.1 pc770 1.7.8(0.236/5/3) 2011-03-01 09:36 i686 Cygwin
rsync is still version 3.0.7.
What additional information may be required? Let me know and I'll
assist with debugging, especially as the implications of this bug may
be quite serious (leaking file descriptors?)
-- David.
--
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: Invoking GUI programs over SSH
On Sun, Jan 23, 2011 at 02:29, Michael Lutz wrote: If it's a different set of files though (i.e. LF for .sh files, CRLF for source code or whatever), you might benefit from switching to the newer core.eol mechanism, which allows to override the line endings for individual files through .gitattributes. Refer to http://www.kernel.org/pub/software/scm/git/docs/git-config.html http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html Thanks Michael, core.eol looks useful. -- David. -- 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: Invoking GUI programs over SSH
On Sat, Jan 22, 2011 at 00:37, Thorsten Kampe wrote: * David Antliff (Fri, 21 Jan 2011 08:47:02 +1300) Yes, that would work, but it's not quite that simple - git clones files in CRLF format, with the autocrlf option set. I don't see the connection to git. Shell scripts should have LF endings. Trying to find a workaround for that will just require you to create more and more workarounds and custom scripts which eventually will break. I suppose it's a bug with git then, since it produces CRLF files on check-out (even if they were checked in as LF), and as this is an automated system I'd need to either set igncr or run dos2unix or equivalent on each script after check-out (which incidentally will require a script, so I'd probably have to use a language that doesn't care, like Python or Perl, rather than Bash). Either way it's a work-around, unfortunately. But it's OK, I can implement one of these workarounds, at least until git's behaviour changes. Setting up and maintaining Hudson + git + Cygwin on Windows turns out to be a giant collection of workarounds anyway, so what's one more :) Thanks for the advice, -- David. -- 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: Invoking GUI programs over SSH
On Sat, Jan 22, 2011 at 03:03, Michael Lutz wrote: Am 21.01.2011 13:06 schrieb David Antliff: I suppose it's a bug with git then, since it produces CRLF files on check-out (even if they were checked in as LF), [...] Seems more like a documentation misunderstanding to me: | core.autocrlf | | Setting this variable to true is almost the same as setting the text | attribute to auto on all files except that text files are not | guaranteed to be normalized: files that contain CRLF in the repository | will not be touched. Use this setting if you want to have CRLF line | endings in your working directory even though the repository does not | have normalized line endings. This variable can be set to input, in | which case no output conversion is performed. http://www.kernel.org/pub/software/scm/git/docs/git-config.html Don't set core.autocrlf to true if you don't want to have CRLFs in your files. Use input if you just want to avoid accidentally commit CRLFs. That is also what I understood the behaviour to be, but Eric has just mentioned it's possibly a bug (which is actually the first time anyone has suggested this to me). I do want to have CRLF endings in my files, because merge tools like kdiff3 (on Windows) require CRLF files. We could live without kdiff3, however changing this setting down the track is a harder problem to solve than using 'set -o igncr'. All sorts of strange problems occur if people stop using autocrlf=true. We have a very large number of repositories and clones, making a global change difficult, but perhaps not impossible. In this case what it really comes down to is bash - why should bash care if a script ends in LF or CRLF? Answer is, it doesn't, provided you tell it not to care. I can live with that. I haven't even begun to get into the internal git idiosyncrasies with CRLF/LF diffs, trailing whitespace in a CRLF file, unresolvable 'modified' files that aren't, and the problems you get into when someone 'git add's a file with the wrong case... but I understand all of these problems, and I have workarounds for all of them. I've also reported them in the past, on this list. -- David. -- 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: Invoking GUI programs over SSH
On Thu, Jan 20, 2011 at 20:06, Thorsten Kampe wrote: * David Antliff (Thu, 20 Jan 2011 18:31:25 +1300) Actually there is one outstanding issue with this Hudson slaves over SSH issue - due to the inability for Cygwin's bash to run scripts with DOS line endings, we've had to use SHELLOPTS=igncr in our Cygwin.bat files, since it cannot be modified once bash is running. Convert the shell scripts to LF endings. Yes, that would work, but it's not quite that simple - git clones files in CRLF format, with the autocrlf option set. I can't easily disable that option without other consequences (it breaks some diff tools, not to mention existing clones), and I've already found the solution - it's SHELLOPTS=igncr when bash starts. So what I want to know is how to set sshd to set this option on new bash instances for incoming connections. And no, you can't convert them to LF, recommit them in git, and expect them to check out later in LF format. They won't - they'll come out in CRLF format again, because of the way git works in Cygwin with autocrlf=true set. I could write a non-bash 'bootstrap' script that goes through the entire git clone and converts shell scripts to LF endings - but it seems pretty unnecessary if the problem is already solved with the 'igncr' option. So the question still remains - how to get sshd to pass this option to spawned bash instances. I did a search and found an old cygwin mailing list thread from 2007 that resulted in use the new version of Cygwin, which I believe I have covered as I'm using Cygwin 1.7.5. Sorry, but this seems to get a bit ridiculous: http://cygwin.com/ - Current Cygwin DLL version... I didn't say I was using the latest, merely that I'm using a newer version than the thread from 2007 concerned. Of course 1.7.5 isn't the latest, but it's the most tested version I have here. I didn't mean to convey that I was thought I was using the latest and that I'd made the ridiculous mistake of picking the wrong version. However if someone can tell me that this problem is fixed in 1.7.7, then of course I'll look at an upgrade - but there's a lot of acceptance testing required, I can't simply move everyone to 1.7.7 without weeks of testing and writing yet-more-workaround-scripts for the inevitable inconsistencies in git (caused by Windows). But I'll happily try 1.7.7 (or whatever the latest is) on an independent installation if someone thinks it's the solution to the problem above. -- David. -- 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: Invoking GUI programs over SSH
On Fri, Jan 21, 2011 at 08:59, Eric Blake wrote: On 01/20/2011 12:47 PM, David Antliff wrote: On Thu, Jan 20, 2011 at 20:06, Thorsten Kampe wrote: * David Antliff (Thu, 20 Jan 2011 18:31:25 +1300) Actually there is one outstanding issue with this Hudson slaves over SSH issue - due to the inability for Cygwin's bash to run scripts with DOS line endings, we've had to use SHELLOPTS=igncr in our Cygwin.bat files, since it cannot be modified once bash is running. Actually, it CAN be modified when bash is running, via 'set -o igncr'. Reread the bash release announcement for the various ways to control the igncr settings: http://cygwin.com/ml/cygwin-announce/2010-12/msg00032.html Ah, that's good, I'll use that - thank you. Introduced in bash 3.2.2 I see. Convert the shell scripts to LF endings. Yes, that would work, but it's not quite that simple - git clones files in CRLF format, with the autocrlf option set. Are you using msysgit? Because cygwin git does not clone files in CRLF format on binary mounts (at least, it shouldn't, and if it does, that's a bug in cygwin git). No, I'm using native Cygwin git 1.7.1 on Cygwin 1.7.5. A quick test (with core.autocrlf=true) clearly shows all cloned files as being in CRLF format. Would you like me to test with the latest Cygwin? And no, you can't convert them to LF, recommit them in git, and expect them to check out later in LF format. They won't - they'll come out in CRLF format again, because of the way git works in Cygwin with autocrlf=true set. Use cygwin git when using cygwin. Indeed. We've been using Cygwin git for two+ years now, and the line-endings issue is a major and constant headache, but I've posted all that months ago (and without resolution). These days we just delete and reclone when the dreaded line-endings-prevent-checkout-or-commit-or-anything problem raises its head :) -- David. -- 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: Invoking GUI programs over SSH
On Wed, Jan 19, 2011 at 21:30, Thorsten Kampe wrote: I don't think anyone will do that unless you provide the logs in native (PML) format. Ok, I can do that - I posted them as CSV as I thought they'd be easier to read/diff and I wasn't sure if I should attach a file here. So should I attach them to my response or host them elsewhere and link to them? Are on-list attachments acceptable? -- David. -- 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: Invoking GUI programs over SSH
On Thu, Jan 20, 2011 at 04:59, Christopher Faylor wrote: On Wed, Jan 19, 2011 at 01:45:02PM +0100, marco atzeri wrote: On Wed, Jan 19, 2011 at 1:34 PM, Thorsten Kampe wrote: * David Antliff (Wed, 19 Jan 2011 23:27:36 +1300) On Wed, Jan 19, 2011 at 21:30, Thorsten Kampe wrote: I don't think anyone will do that unless you provide the logs in native (PML) format. Ok, I can do that - I posted them as CSV as I thought they'd be easier to read/diff and I wasn't sure if I should attach a file here. The amount of data in a PM log is much easier to handle via PM itself (although it doesn't do diffs). So should I attach them to my response or host them elsewhere and link to them? Are on-list attachments acceptable? Attachments are okay in general (see http://cygwin.com/problems.html). Despite the do not compress recommendation, I think compression would be advisible since PM log files tend to be huge. Thorsten long attachment are rejected by the mailing list. Actually long email messages are rejected. It has nothing to do with attachments. But, please don't send long log files here if they are just for one person to inspect. Use private email for that. Ok, advice noted, thank you. This is actually why I converted them to .csv and posted them on pastebin.com in the first place - to avoid attaching long logs that aren't diff-able. However I understand that native format is probably easier for direct inspection so I may host them on dropbox and post the link here instead, if anyone is interested in taking a look at them. Will sort that out later today. Also, Cyrille, thank you for your suggestion, I've looked at those links and I'm going to double-check the environment too. Thanks for the advice everyone, -- David. -- 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: Invoking GUI programs over SSH
On Wed, Jan 19, 2011 at 1:34 PM, Thorsten Kampe wrote: * David Antliff (Wed, 19 Jan 2011 23:27:36 +1300) On Wed, Jan 19, 2011 at 21:30, Thorsten Kampe wrote: I don't think anyone will do that unless you provide the logs in native (PML) format. Ok, I can do that - I posted them as CSV as I thought they'd be easier to read/diff and I wasn't sure if I should attach a file here. The amount of data in a PM log is much easier to handle via PM itself (although it doesn't do diffs). Ok, I have recreated the logs in PML and CSV format (for textual diff) and put them here: http://dl.dropbox.com/u/360506/debug/synplify-pm-logs-20110120.zip I haven't tried Cyrille's suggestion yet (but will) however from what I can tell, the 'fail' case seems to be missing a large C: filesystem 'scan' that is present in the working log. Then the working log @ 12:18:53.7389940 seems to 'catch up' with the failed log @ 12:19:41.6704435. Then they fall out of sync again at 12:18:54.2057690 works / 12:19:42.3868006 fails. So the first disparate operation between them is where 'working' does a CreateFile on C:\ and 'fail' does not. -- David. -- 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: Invoking GUI programs over SSH
On Thu, Jan 20, 2011 at 13:06, David Antliff wrote: I haven't tried Cyrille's suggestion yet (but will) Ok, an update - I've managed to solve this problem - the vendor informed me (indirectly) that the error I was seeing was due to the access of files in c:\lsc_env - turns out I hadn't ensured that the LSC_INI_PATH environment variable was set properly in the 'ssh' instance. So it turned out to be something fairly simple in the end - but thank you everyone for your advice. Cyrille - I tried your script but it didn't seem to do anything. I had a look over the source and I wasn't really able to work out what it was doing. However it did give me the idea to copy/paste my entire 'env' from the working to non-working shell and then slowly eliminate variables until I found the one I needed, so it was very helpful in an indirect way - thank you. Regards, -- David. -- 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: Invoking GUI programs over SSH
On Thu, Jan 20, 2011 at 16:28, David Antliff wrote: Ok, an update - I've managed to solve this problem - the vendor informed me (indirectly) that the error I was seeing was due to the access of files in c:\lsc_env - turns out I hadn't ensured that the LSC_INI_PATH environment variable was set properly in the 'ssh' instance. Actually there is one outstanding issue with this Hudson slaves over SSH issue - due to the inability for Cygwin's bash to run scripts with DOS line endings, we've had to use SHELLOPTS=igncr in our Cygwin.bat files, since it cannot be modified once bash is running. But for a bash shell running over ssh, this option is not set, so coupled with git's strange autocrlf behaviour in Cygwin (which I have reported before) this leads to bash scripts that are freshly cloned from git being un-runnable from an ssh session. So my question is - how do I get the bash shell that runs when I ssh to a Cygwin host to have the SHELLOPTS=igncr option set? Somehow I need to get the sshd service to spawn the new bash instance with this option set. I did a search and found an old cygwin mailing list thread from 2007 that resulted in use the new version of Cygwin, which I believe I have covered as I'm using Cygwin 1.7.5. -- David. -- 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: Invoking GUI programs over SSH
On Tue, Jan 18, 2011 at 22:52, Thorsten Kampe wrote: * David Antliff (Tue, 18 Jan 2011 13:13:22 +1300) Along these lines, I was wondering if anyone knows how to run the Cygwin SSH daemon manually, rather than as a service? On Linux one can just run sshd from the command line, specifying an alternative port if necessary. But in Cygwin I can't find sshd.exe or anything similarly named. On Cygwin you do it the same way as you do it on Linux and the executable is in the same place as it is on Linux. Thorsten, thank you. I had to adjust some folder permissions and grant some special privileges (as described at the end of this page: http://ist.uwaterloo.ca/~kscully/CygwinSSHD_W2K3.html), but once I did that it seemed to work, at least running under a User rather than Local System account. Jeremy: thank you also - ProcessMonitor is very useful, and I'm using it to compare the behaviour of the working (local) and non-working (over SSH) instances. It's going to take me some time to sift though them, but there are big differences: Working: http://pastebin.com/W30xcT6P Non-working: http://pastebin.com/Xt3an4Qs The two logs diverge massively at line 12. The working instance appears to start scanning the filesystem, whereas the non-working instance starts going through registry keys. I'm not 100% convinced I'm comparing oranges with oranges here, but I'm hoping there's a clue somewhere. I'll be spending some time trying to deduce what the problem might be, but if anyone looks at those logs and can easily tell me, I'd really appreciate it! :) Thanks, -- David. -- 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
Invoking GUI programs over SSH
Hello, I've found this thread so far: http://cygwin.com/ml/cygwin/2010-07/msg6.html It's related to what I am trying to do, but I'd like to get confirmation that what I am attempting is impossible, or not. Essentially I have a seemingly command-line based FPGA synthesis tool (a compiler if you prefer) called Synplify Pro. Unfortunately it is not truly command-line, but does some sort of GUI-related operations even though it shows no actual GUI (except sometimes a splash screen). This means that although I can run it from a local bash instance, and it will run, I don't seem to be able to run it from an SSH session. Copyright (c) 1991-2010 Lattice Semiconductor Corporation, All rights reserved. Failed to get 'Config' context string of ispLever System Failed to get 'Root' context string of ispLever System The reason I want to do this is because I'm using the Hudson Continuous Integration server to create a cluster of build machines. Hudson uses SSH to connect to Slave nodes and run processes. A build using Synplify Pro will work on the 'master' node, but does not work on any Slave node because of the above error. I believe it needs access to GUI services to run correctly. I noticed when I run Windows apps such as notepad.exe or calc.exe over SSH that they start up, no GUI appears, but as far as I can tell they remain running. Note that I do not want the GUI to appear on the remote computer - I understand that is an entirely different proposition and I'm not interested in this. I just want the program to think it can open the GUI and not abort with an error message. Does anyone know of any 'trick' to enable a GUI program to work via SSH please? I'm using Cygwin 1.7.5 on Windows XP SP3 32bit. -- David. -- 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: Invoking GUI programs over SSH
On Tue, Jan 18, 2011 at 10:34, Jeremy Bopp wrote: On 1/17/2011 3:20 PM, David Antliff wrote: Essentially I have a seemingly command-line based FPGA synthesis tool (a compiler if you prefer) called Synplify Pro. Unfortunately it is not truly command-line, but does some sort of GUI-related operations even though it shows no actual GUI (except sometimes a splash screen). This means that although I can run it from a local bash instance, and it will run, I don't seem to be able to run it from an SSH session. Copyright (c) 1991-2010 Lattice Semiconductor Corporation, All rights reserved. Failed to get 'Config' context string of ispLever System Failed to get 'Root' context string of ispLever System [snip] I noticed when I run Windows apps such as notepad.exe or calc.exe over SSH that they start up, no GUI appears, but as far as I can tell they remain running. [snip] Does anyone know of any 'trick' to enable a GUI program to work via SSH please? I'm using Cygwin 1.7.5 on Windows XP SP3 32bit. Perhaps you could use the editrights program to add the SeInteractiveLogonRight for the user running the ssh service and effectively get access to the main desktop that way. Hi Jeremy, thank you for your idea. I just tried this - in fact I used the AdministrativeTools/Services applet to set the Cygwin SSHD service to Allow service to interact with desktop. This actually had a useful effect - I can now start 'notepad' or 'calc' and I see the process appear on the main desktop. However, unfortunately, I still get the same error from Synplify Pro. I wonder if it's looking for more than just GUI services? Also, having that option set causes any SSH connection attempts *from Cygwin* to connect, then immediately terminate. However if I connect from a Linux host, it connects fine. If I turn off the Allow service to interact with desktop, then I can connect again. Not a big deal, but odd. I've also tried running the sshd service as the same user currently logged in (i.e. running the desktop). However when I do this, the sshd service fails to start with no error message other than service could not be started. The service did not report an error. -- David. -- 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: Invoking GUI programs over SSH
On Tue, Jan 18, 2011 at 11:06, Jeremy Bopp wrote: On 1/17/2011 3:46 PM, David Antliff wrote: However, unfortunately, I still get the same error from Synplify Pro. I wonder if it's looking for more than just GUI services? Yeah, the error message you described originally didn't sound like a problem with starting the GUI. The message really looks like it's failing to read some configuration information. Maybe there is some strange permission on an important registry setting or a file that is preventing the authenticated account from accessing the necessary information when logging in through SSH. Is it possible that Synplify Pro is attempting to access some network resource or a special dongle for verifying its registration or something similar? There's no dongle but there is a license server it needs to communicate with. I'll investigate that, although based on experience it usually just blurts out no license, goodbye. I'll check permissions as well. Do you know if there is an equivalent tool to 'strace' for Windows that I can use to log all syscalls/file/resource accesses made by a program and its threads? I've also tried running the sshd service as the same user currently logged in [snip] people are discouraged from attempting it and then asking for help Ok, I'm not sure it was going to help anyway, since I can open notepad remotely when running as the Local System. Have you tried contacting Synplify Pro's author/distributor to see if they have suggestions for automating its use as you're attempting? Yes, I've made a support request so we'll see if that comes back with anything. Thanks for your comments, -- David. -- 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: Invoking GUI programs over SSH
On Tue, Jan 18, 2011 at 12:06, David Antliff wrote: On Tue, Jan 18, 2011 at 11:06, Jeremy Bopp wrote: I've also tried running the sshd service as the same user currently logged in [snip] people are discouraged from attempting it and then asking for help Along these lines, I was wondering if anyone knows how to run the Cygwin SSH daemon manually, rather than as a service? On Linux one can just run sshd from the command line, specifying an alternative port if necessary. But in Cygwin I can't find sshd.exe or anything similarly named. -- David. -- 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: Invoking GUI programs over SSH
On Tue, Jan 18, 2011 at 13:19, Larry Hall (Cygwin) wrote: On 1/17/2011 7:13 PM, David Antliff wrote: Along these lines, I was wondering if anyone knows how to run the Cygwin SSH daemon manually, rather than as a service? On Linux one can just run sshd from the command line, specifying an alternative port if necessary. But in Cygwin I can't find sshd.exe or anything similarly named. Running sshd manually is unsupported by this list. However, you'll find sshd in /usr/sbin. 'cygcheck -l openssh | grep sshd' gives you a good hint. That's great info - thank you. -- David. -- 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: uptime not reporting CPU usage on Windows 7 (Possibly only when running in VMWare)
On Fri, Dec 31, 2010 at 08:23, Andrew DeFaria wrote: Well that sucks. Surely Windows has some means of reporting how busy the system is. uptime should use that. But then they wouldn't be actual load averages where most people/programs expected to see load averages. -- David. -- 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: uptime not reporting CPU usage on Windows 7 (Possibly only when running in VMWare)
On Fri, Dec 31, 2010 at 12:27, Andrew DeFaria wrote: On 12/30/2010 06:05 PM, David Antliff wrote: On Fri, Dec 31, 2010 at 08:23, Andrew DeFaria wrote: Well that sucks. Surely Windows has some means of reporting how busy the system is. uptime should use that. But then they wouldn't be actual load averages where most people/programs expected to see load averages. -- David Understood, but current real load averages be calculated? Besides wouldn't those people who expect to see real load averages (i.e. me!) be disappointed to only see 0's?!? IOW wouldn't even fake load averages be better than just always 0?!? The load average is a bit more complicated than just how busy the system is - it's related to the number of processes waiting for the CPU, with some time-weighted averaging and a few other herbs and spices. I'm no Windows system programmer so I don't even know if that sort of information is even available to Cygwin. I 'discovered' this zero thing myself last year when I was trying to incorporate some sort of logging into a build system I wrote to run in Cygwin - I had hoped to compare 'machine load' over multiple builds over time, but as you know, you just get zeroes. So I just used build timing metrics instead (i.e. the 'time' command). Personally I wouldn't mind a Cygwin/Windows-specific measurement that provided some sort of how busy is the machine metric (one probably exists - anyone?) but I think it might be better to not overload the load average fields as they are pretty specific in their meaning. In my opinion, I think it's better to have zero values rather than anything fake. A consistent and reasonable 'estimate' (if possible) would be OK for my purposes but I can't speak for anyone else. -- David. -- 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: Python: subprocess running rsync causes broken socket in telnetlib
On Wed, Nov 17, 2010 at 09:57, David Sastre wrote: On Wed, Nov 17, 2010 at 09:39:38AM +1300, David Antliff wrote: On Mon, Nov 15, 2010 at 10:00, David Antliff wrote: Can anyone else see the fault if they run the script I posted? [snip] I can reproduce it on my side. That doesn't mean I can debug it further, though, sorry. Thanks for giving it a try. Cygwin core developers - is there anything more I can do to help solve this one? Perhaps it's related to other unexplained process interaction? It's certainly a disturbing thing to see. -- David. -- 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: Python: subprocess running rsync causes broken socket in telnetlib
On Mon, Nov 15, 2010 at 10:00, David Antliff wrote: Can anyone else see the fault if they run the script I posted? It would be great to know if this fault exists only at my site, or if other sites can also demonstrate this fault. It's pretty easy to test - ensure you have Python and rsync installed and simply run the script in my original post. If the problem arises, you'll get a python socket.error exception, error 113 Software caused connection abort. 100% reproducible for me, on every Cygwin installation I've tried it on. This fault might suggest a file descriptor leak between processes. -- David. -- 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: Python: subprocess running rsync causes broken socket in telnetlib
On Sat, Nov 13, 2010 at 18:03, Charles Wilson wrote: On 11/11/2010 10:19 PM, David Antliff wrote: On Cygwin 1.7.7, this does something nasty to the completely unrelated yet existing telnetlib socket so that any further attempts to read or write from this socket raise an exception: [snip] Try capturing stderr, and see what's there. I suspect you may be getting an error message like this: 52967 [main] python 9340 C:\cygwin-1.7\bin\python.exe: *** fatal error - unable to remap \\?\C:\cygwin-1.7\lib\python2.6\lib-dynload\time.dll to same address as parent: 0x36 != 0x3A Perhaps running rebaseall (or some analog to perlrebase for python?) Hi Chuck, thank you for your reply. I captured stderr when running 'rsync' (by adding stderr=subprocess.STDOUT to the subprocess call), but I see nothing extra on stderr at all. Bear in mind that rsync does actually run - I originally found this as part of a larger script that copies some files to a remote host via rsync, and it would copy them fine on Cygwin or Linux, but on Cygwin a (much) later operation on the telnet socket would break. I reduced the problem down to the script I posted earlier. I tried a rebaseall and that didn't seem to change the situation. I'm not aware of a python-specific equivalent (anyone?) but I can try that if it exists. For now I have worked around the problem in my script by rebuilding all Telnet connections after running rsync. It's messy but it does allow the script to run on Cygwin. I've also reproduced this on several Cygwin 1.7.5 installations (entirely different machines). Can anyone else see the fault if they run the script I posted? -- David. -- 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
Python: subprocess running rsync causes broken socket in telnetlib
I'm reporting a problem I see on Cygwin because I do not see the same
behaviour on Ubuntu Linux - both systems are running Python 2.6.5.
I have a script that opens a long-term telnet connection (telnetlib)
to a remote host. There is an object called Telnet().socket that is
created and represents an active socket connection to the remote host,
once the right telnetlib calls are made.
Then the script uses subprocess to do something else (the line is
actually longer than this but I've simplified it to the most basic
version that exhibits the problem):
process = subprocess.Popen(rsync, stdout=subprocess.PIPE)
On Cygwin 1.7.7, this does something nasty to the completely unrelated
yet existing telnetlib socket so that any further attempts to read or
write from this socket raise an exception:
File /usr/lib/python2.6/telnetlib.py, line 280, in write
self.sock.sendall(buffer)
File string, line 1, in sendall
socket.error: [Errno 32] Broken pipe
On Linux, this doesn't happen at all.
I've tried a few other programs via subprocess like cat and ssh
but they don't seem to cause this problem - only rsync does so far.
There may be others but I haven't found them.
If anyone is prepared to look into this I have attached a small python
script (bug.py) that demonstrates the problem. The error returned in
this case is 113: Software caused connection abort, but the end
result is the same - the socket is broken by the call to subprocess
rsync:
$ python bug.py
('telnet', '220 mx.google.com ESMTP w42sm3212723wfh.15\r\n')
('ssh', 0, 'OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010\n')
('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n')
('rsync', 0, 'rsync version 3.0.7 protocol version 30\nCopyright (C) 1996')
Traceback (most recent call last):
File bug.py, line 38, in module
print(telnet, t.read_eager())
File /usr/lib/python2.6/telnetlib.py, line 370, in read_eager
self.fill_rawq()
File /usr/lib/python2.6/telnetlib.py, line 516, in fill_rawq
buf = self.sock.recv(50)
socket.error: [Errno 113] Software caused connection abort
If you edit the script and set 'crash' to False, you'll see that the
script completes without error:
$ python bug.py
('telnet', '220 mx.google.com ESMTP i16sm3108013ibl.0\r\n')
('ssh', 0, 'OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010\n')
('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n')
('telnet', '250-SIZE 35651584\r\n250-8BITMIME\r\n250-STARTTLS\r\n250')
And on Linux:
$ python bug.py
('telnet', '220 mx.google.com ESMTP i16sm3106343ibl.18\r\n')
('ssh', 0, 'OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009\n')
('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n')
('rsync', 0, 'rsync version 3.0.7 protocol version 30\nCopyright (C) 1996')
('telnet', '250-SIZE 35651584\r\n250-8BITMIME\r\n250-STARTTLS\r\n250')
rsync is version 3.0.7.
-- David.
#!/usr/bin/python
Script to demonstrate how combination of subprocess rsync causes a telnetlib connection to fail.
David Antliff, Nov 2010
import telnetlib
import subprocess
import time
# change this to False to avoid the crash
crash = True
# Use Google's SMTP server as a demonstration
host = smtp.gmail.com
port = 25
# connect to a remote host with telnetlib
t = telnetlib.Telnet()
t.open(host, port)
time.sleep(1)
print(telnet, t.read_eager())
# THE FOLLOWING LINE DOES NOT SEEM TO CAUSE A PROBLEM
process = subprocess.Popen([ssh, -V], stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
output = process.communicate()[0]
retcode = process.returncode
print(ssh, retcode, output)
# query the telnet server
t.write(EHLO\r\n)
time.sleep(1)
print(telnet, t.read_eager())
if crash:
# THE FOLLOWING LINE KILLS THE telnetlib SOCKET
process = subprocess.Popen([rsync, --version], stdout=subprocess.PIPE)
output = process.communicate()[0]
retcode = process.returncode
print(rsync, retcode, output[0:60])
# this will now result in a crash because the connection is lost:
print(telnet, t.read_eager())
t.write(QUIT\r\n)
t.close()
--
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: Python: subprocess running rsync causes broken socket in telnetlib
On Fri, Nov 12, 2010 at 16:19, David Antliff wrote: Then the script uses subprocess to do something else (the line is actually longer than this but I've simplified it to the most basic version that exhibits the problem): process = subprocess.Popen(rsync, stdout=subprocess.PIPE) FWIW, this function also exhibits the same problem: subprocess.call(rsync) -- David. -- 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: Python: subprocess running rsync causes broken socket in telnetlib
On Fri, Nov 12, 2010 at 16:26, David Antliff david.antl...@gmail.com wrote: On Fri, Nov 12, 2010 at 16:19, David Antliff wrote: Then the script uses subprocess to do something else (the line is actually longer than this but I've simplified it to the most basic version that exhibits the problem): process = subprocess.Popen(rsync, stdout=subprocess.PIPE) FWIW, this function also exhibits the same problem: subprocess.call(rsync) As does: os.system(rsync) And wrapping up rsync inside another script and calling that script also doesn't work around the problem either. This is a bit concerning as it means rewriting my scripts to avoid mixing the use of rsync with telnet, on Cygwin. Does anyone have any ideas why 'rsync' is special in this case? How can it affect an existing filehandle in a parent process? Isn't that a violation of process separation? -- David. -- 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: Looking for experienced CygWin Users
What a disappointing trail of negativity and discouragement. Isn't the need to create a separate, hopefully more welcoming environment now painfully obvious? -- David. -- 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: Looking for experienced CygWin Users
On Fri, Oct 8, 2010 at 11:09, Christopher Faylor wrote: On Fri, Oct 08, 2010 at 09:46:28AM +1300, David Antliff wrote: What a disappointing trail of negativity and discouragement. What, specifically was negative and discouraging? Was it: A random mailing list user expressing dislike for web forums? A maintainer stating that he didn't want to split his time between the Cygwin mailing lists and some other unofficial forum? Telling someone how to spell the name of the project they want to be helping? Mentioning that fragmenting support is probably a bad idea? Suggesting that directly helping the project by helping to write documentation is a better idea than trying to start something unofficial? Suggesting that, unless you're going to be actively moderating a forum, you can't guarantee tone or content? Yep, pretty much all of that. It's not what was said (which sounds fine when you paraphrase it as you have), but the way it was said. It was my reaction to reading the thread in one sitting, especially as I thought the OP had good intentions. That is all. -- David. -- 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 command line takes a long time to start
On Mon, Jul 26, 2010 at 08:12, Csaba Raduly wrote: On Fri, Jul 23, 2010 at 3:53 AM, David Antliff wrote: How would one go about debugging the bash or mintty startup before .bash_profile is read? Duplicate your shortcut which launches bash and add -x to the bash options (which should include -l a.k.a. --login) Thanks everyone - using these tips I was able to determine that bash_completion was actually running twice - once by /etc/profile.d/bash_completion.sh, and again by my own .bash_profile, which was modifying the path prior to invoking it so that apps in my ~/bin were picked up. I don't actually have anything useful in there any more so it's really just a bunch of old stuff I brought over from my Linux config. I've tidied it up now. I now get the bash prompt after about 5 seconds, rather than 10. Disabling bash_completion completely gives me a prompt in less than 1 second, but I do quite like bash_completion so I'll live with that. -- David. -- 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 command line takes a long time to start
On Fri, Jul 23, 2010 at 07:49, Larry Hall (Cygwin) wrote: OK then the easiest thing to do is add set -x to your ~/.bash_profile and watch where the delay happens as the statements scroll by. Ah, that's useful - I also have a 10-second-or-so delay when mintty starts. By using a bunch of 'echo' commands and that set -x (which of course extends the time, but at least makes it clear if anything is 'hanging') it's clear to me that the majority of the delay (about 6 seconds) happens before .bash_profile executes. I am loading bash_completion and it does take about 5 seconds, but that's the last thing to run before the prompt appears, and the delay is happening before that. How would one go about debugging the bash or mintty startup before .bash_profile is read? -- David. -- 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: 'cp' utility bug when lt;dest-namegt;.exe file exist.
On Fri, Jun 11, 2010 at 10:26, Eric Backus wrote: As a side note, this same kind of reasoning is why I think Cygwin bash should default the igncr option to on. I agree - using git with core.autocrlf=true (a controversial setting in itself, but one that you're stuck with if you choose to use it) without SHELLOPTS=igncr results in bash scripts being checked out in DOS-style, which bash can't run properly. But it's not too hard to set this in Cygwin.bat before bash starts, once you know what the problem is. set SHELLOPTS=igncr -- David. -- 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: 'cp' utility bug when dest-name.exe file exist.
On Wed, Jun 9, 2010 at 13:38, Julio Costa wrote: And this is where my head got reeeally spinning... can anyone, please, explain the reason to why this .exe magic exists, anyway? I can't answer that, but there is a style of symlinks that use .lnk files. Cygwin displays them without that extension, but the actual filename is .lnk so presumably Cygwin has to do some 'lnk-magic' to deal with that. I know it's not the same thing as exe-magic, but it might be related because Cygwin has to hide the reality from the user in order for the symlink to work. On Wed, Jun 9, 2010 at 04:21, Corinna Vinschen wrote: There is. foo can mean foo. or foo.lnk, or foo.exe. Cygwin is handling all these names as being the same file. With symlinks I can understand this, but why match to .exe? Is it because Cygwin allows a user to execute a .exe file without specifying the .exe extension? That is perhaps wrong too - if I want to run foo.exe, I should type ./foo.exe, not ./foo - but ./foo currently works. Then, perhaps this logic was translated into 'cp' (but not 'mv' for some reason?) because people wanted to copy such executables around in the same manner: cp foo bar rather than cp foo.exe bar.exe - but this seems like merely a 'convenience' for Windows users and not a very good one at that. Oh well, yet another thing I suppose to add to my list of ways Windows has set information technology back decades :-P -- David. -- 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: file command
On Fri, Apr 9, 2010 at 11:04, Kaumil B Desai wrote: I have installed cygwin. I want to use file command. So what package I need to install in cygwin. Oddly, you want the file package... :) -- David. -- 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 Virus
On Sat, Mar 20, 2010 at 20:42, Karthik Balaguru wrote: On Sun, Mar 14, 2010 at 7:12 AM, David Antliff wrote: On Sun, Mar 14, 2010 at 13:26, Karthik Balaguru wrote: Since cygwin is a windows utility that provides linux environment. What is the probability of the linux environment to get infected by virus ? Hello Karthik, I don't entirely understand your question - are you asking whether a Windows virus infection can affect files manipulated by Cygwin on that same system? I would imagine the answer is yes if Cygwin is using standard OS facilities to read/write files. Yeah, You are Correct. My actual question was related to this query. I was eager to know if the files touched by cygwin(Linux environment) would get infected due to an virus in Windows system ? Cygwin is just an application library upon Windows - there's no isolation from Windows. If something screws with Windows, then Cygwin can be affected too. This is other thought that i had in my mind while thinking about protecting files in linux environment(Cygwin) against that of windows. Is it possible ? Cygwin isn't Linux. It just feels like Linux because many of the same applications are provided. But it isn't Linux. Thinking over the similar lines, another query popped up in my mind - Is cygwin more vulnerable to Windows based Virus or Linux based Virus ? Cygwin isn't Linux, so it's not vulnerable to Linux-based viruses at all really. Cygwin is just an application on Windows, so yes, Cygwin is vulnerable to Windows based viruses and I'd imagine almost completely immune to Linux-based viruses unless they are silly Perl or shell script worms for example. That said, a security issue affecting something like OpenSSH could also be a problem in Cygwin. It really depends on where the root cause of the problem is that allows the issue to arise. In a nutshell - Cygwin is part of Windows. It's not an operating system in its own right. It's definitely not Linux. It just happens to do a lot of things that Linux can do because the same applications (like perl, bash, emacs, etc) are available. Hope this is helpful - if not, perhaps tell us what you want to achieve. -- David. -- 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 Virus
On Sun, Mar 14, 2010 at 13:26, Karthik Balaguru wrote: Since cygwin is a windows utility that provides linux environment. What is the probability of the linux environment to get infected by virus ? Hello Karthik, I don't entirely understand your question - are you asking whether a Windows virus infection can affect files manipulated by Cygwin on that same system? I would imagine the answer is yes if Cygwin is using standard OS facilities to read/write files. Or are you asking about viruses targeted at Cygwin specifically? Or are you asking about the vulnerability of Cygwin to Linux-targeted viruses (of which there aren't very many)? -- David. -- 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: setup.exe for Cygwin 1.5 doesn't recognise mirror's .ini file
On Sat, Feb 27, 2010 at 14:50, Rance Hall wrote: There is no commandline switch to do what you want. But there is an online verion of the legacy version of 1.5 setup.exe that you could use to create a 1.5 environment. On Sat, Feb 27, 2010 at 15:04, Peter A. Castro wrote: You might have missed the announcement, but Cygwin's current release has moved to 1.7 and 1.5 is effectively unsupported. If you really need 1.5, you can use the setup-legacy.exe (obtained from the cygwin website) and grab from the release-legacy tree (which is trunced as of mid December of 2009). Thanks Rance and Peter for your replies. I did not know about setup-legacy.exe, so when I downloaded this and ran it it did exactly what I needed it to. I have now added those packages to my permanent archive, so this shouldn't be a problem again. Now I have a test server running Cygwin 1.5, it's time to test the upgrade path to Cygwin 1.7 and compatibility with the rest of my environment (which for interest we use to build and test FPGAs...) Thanks again, -- David. -- 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.exe for Cygwin 1.5 doesn't recognise mirror's .ini file
Hello, I have an existing Cygwin-1.5 environment that I use to support my development team. I am setting up a virtual machine with Cygwin 1.5 so that I can test the upgrade to Cygwin 1.7. The installation process for my Cygwin 1.5 environment involves installing from a previously downloaded and archived local directory for the most part, but there's one final step where a few final packages (like apache2) are downloaded from an Internet mirror. However, the setup.exe that I currently have for 1.5 now fails to parse the current .ini file it downloads from any mirror - it suggests using a newer version of setup.exe. But I cannot find a version of setup.exe for Cygwin 1.5, only for the newer Cygwin 1.7, and this one will force me to upgrade I believe (unless there's a commandline switch I don't know about). This makes me wonder if the official mirrors don't carry Cygwin 1.5 packages any more. Is this the case? If they do, how can I get hold of a correct version of setup.exe that understands the latest version of the downloaded ini file but won't upgrade me to Cygwin 1.7? Or am I stuck with a mandatory upgrade to Cygwin 1.7? If that is the case, I can't see how I can test the upgrade process, and there's no way I can roll out Cygwin 1.7 onto our production servers without running it through a test upgrade first. If I can't install Cygwin 1.5 any more, I can't test this upgrade process. So there must be a way to do this and I'm missing something obvious. I understand that my 1.5 installation archive should have contained *all* the packages we need, and downloading the latest version of apache2 etc is the cause of my problem. However, hindsight is a wonderful thing... :) All help thankfully appreciated, -- David. -- 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: bash slow to get prompt
On Wed, Feb 17, 2010 at 01:06, lanco wrote: does anyone encountered this problem during its experience with cygwin 1.5? Commands in bash (ls, cd, awk, ncftp, sed, ...) appears executed correctly but prompt get many seconds to come back to life. [snip] PROMPT_COMMAND = 'history -a' Just wondering - might be a red herring, but how large is your ~/.bash_history file? Try: $ wc ~/.bash_history -l -- David. -- 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: Problems with line endings for shell scripts
On Tue, Feb 9, 2010 at 04:20, Jeremy Bopp jer...@bopp.net wrote: On 2/8/2010 6:30 AM, Jurgen Defurne wrote: Today I am having a problem with running a shell script (sh/bash) which has CRLF endings. The problem is that Bash only supports Unix line endings Indeed - the problem gets far worse when you start using git to manage scripts - with core.autocrlf = true set, git converts all scripts to DOS-endings on checkout, and bash won't run them. We resolved this by putting SHELLOPTS=igncr into Cygwin.bat. This has to be done before bash starts, so it won't work in .bashrc or .bash_profile. -- David. -- 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: Gitk issue post 1.7.1 upgrade
On Mon, Jan 18, 2010 at 23:52, Jeenu V jee...@gmail.com wrote: I'm using Gitk from Cygwin and I come across this problem quite frequently post upgrade to 1.7.1. While I'm viewing commits a pop-up appears saying writing to stdout fails. I'm able to consistently reproduce it by making quick random clicks on the commit graph. And I don't remember seeing this behavior pre-1.7.1 Cygwin. I've captured log and is attached. Has any one else come across this? I've seen this a lot, and at the time I thought it might be related to clicking on a commit that contains a file that no longer exists in the working tree. Throughout some of our repositories we had 'mass renaming' commits, and I have noticed that it seems to happen quite often if I quickly click commits on the far side of such a commit. That said, it didn't seem particularly consistent and I am not able to definitely point at that as a cause. It has the feel of a race condition. I don't see it happen in Linux at all. I've also seen gitk on 1.7.1 Cygwin become intolerably slow within seconds of opening within a (very small, 10 commits) repository with many renames in it. This caused us to rebuild the repository again, only to see the same problem. But I'm not sure if this is related. -- David. -- 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: git stopped working with 1.7.1
On Mon, Jan 4, 2010 at 15:06, Kevin Layer wrote: I'm not using the git protocol. Note the single slash. The machine is named `git', which is what is confusing you. Anything of the form foo:/path uses SSH, which is what this is using. Yes, you're right, I'm so used to seeing git://server syntax that I was a bit thrown by the git:/path syntax. -- David. -- 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: git stopped working with 1.7.1
On Thu, Dec 24, 2009 at 07:55, Kevin Layer la...@franz.com wrote: la...@hobart128 /c/tmp $ git clone git:/repo/git/acl acl.test Initialized empty Git repository in /c/tmp/acl.test/.git/ remote: Counting objects: 9205, done. remote: Compressing objects: 100% (3300/3300), done. fatal: The remote end hung up unexpectedly fatal: early EOFs: 62% (5708/9205) fatal: index-pack failed I'm no git expert, but that looks to me like the remote side (where the repository is stored) is experiencing the error while it's preparing data for transfer, and your local git is simply reporting the remote error. It also looks like the remote side is actually the same machine but you're using the git:// protocol to access it without specifying a remote server. I've never tried this and would have expected instead to see something like: $ git clone git://localhost/repo/git/acl acl.test or $ git clone some-path/repo/git/acl acl.test I.e. there's something about your command that *I* don't understand. It's probably perfectly fine though, and the problem is with me. Are you intending to clone a repository on the same machine but via the git:// protocol? What if you just do this instead: $ git clone some-path/repo/git/acl acl.test Do you get the same error? Since it looks like the remote is on the same machine as your shell, do you have write access to the actual repository? If so, you could run git-fsck on the repository to make sure it's intact. What about other repositories, do they behave the same way, or is your problem restricted to this one? -- David. -- 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: git stopped working with 1.7.1
On Mon, Dec 28, 2009 at 14:13, Kevin Layer wrote: This seems serious. Do people just not use cygwin git? It sounds very serious. I am a very interested user of git on Cygwin and I'm watching this thread with interest. However It may be a 64-bit issue, so I'll try a 32-bit machine, if I can scrounge one up. We are using WinXP 32-bit and have not seen this problem (yet). It would be really helpful (to me at least) to know whether you can reproduce the issue with 32-bit Windows... I imagine there are a fair number of people using git in Cygwin because the Windows alternatives (msys, etc) do not provide a POSIX-like toolchain environment. Using Cygwin also allows scripts around git to operate on Linux with no modifications. That is why we use Cygwin anyway, and Cygwin + git is very important to us, FWIW. -- David. -- 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 git - Configuration Problem? [was Re: BASH Shell - Configuration Problem?]
On Tue, Dec 15, 2009 at 02:01, Eric Blake wrote: The upstream git list may be a better list to complain at, since they are the folks that implemented whitespace munging in the first place. Ok, I posed a question or two there: http://thread.gmane.org/gmane.comp.version-control.git/135305 I'm really starting to wonder if core.autocrlf=true was such a good idea. It's going to be really hard to switch back if the evidence suggests I should. -- David. -- 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: BASH Shell - Configuration Problem?
On Sat, Dec 12, 2009 at 15:49, Gary Johnson garyj...@spocom.com wrote: On 2009-12-11, rgc3679 wrote: Any ideas? Thanks for all the details. That really helps. It looks to me as though your script file has CR-LF (DOS) line endings rather than LF (Unix) line endings. The current version of Cygwin's bash sees only the LF line endings and includes the CR as part of the script. You can use the d2u utility to fix this. Also, if this is the cause, you can use the Cygwin-specific igncr option in bash to ignore CR characters: $ bash -O igncr ... Note that this has to be set at the time an instance of bash is started (-O igncr), and AFAIK cannot be set afterward (e.g. via shopt). I've set this in Cygwin.bat and used it successfully to allow users to run bash scripts that are in DOS text-file format. This turns out to be really important when using git with core.autocrlf=true... -- David. -- 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 git - Configuration Problem? [was Re: BASH Shell - Configuration Problem?]
On Mon, Dec 14, 2009 at 04:53, Dave Korn dave.korn.cyg...@googlemail.com wrote: David Antliff wrote: I've set this in Cygwin.bat and used it successfully to allow users to run bash scripts that are in DOS text-file format. This turns out to be really important when using git with core.autocrlf=true... Say, do you mean This turns out to be really important when using native win32 git instead of cygwin git, or do you mean that cygwin git use CRLF as the system's default eol rather than LF as it probably ought? Hmm, I hadn't thought of it like that, but I suppose what I mean is that cygwin git uses CRLF as the system's default eol. So to doubly-confirm: I'm using Cygwin-1.5's git and text files appear after a fresh clone with CR characters. Same behaviour with Cygwin-1.7's git-1.6.4.2. But I'm not sure what the implications are of changing this though. I just know that we couldn't get bash scripts to work properly until we made this igncr setting for everyone. I seem to recall it wasn't consistently broken either, but it certainly threw a spanner in the works until I discovered that igncr setting. For the record, core.autocrlf=true on Cygwin is an absolute PITA ;) Hmm, actually, maybe you can help me work out why a file with trailing whitespace on the end of one or more lines causes cygwin's git to flag the file as locally modified when the file hasn't been touched at all. A 'git diff' shows the entire file as being different, due to the line endings switching over. Most annoying. I can write more if you're interested and want to hear about it :) -- David. -- 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
[1.7] git-difftool paths unusable by win32 kdiff3
My subject keeps getting blocked due to spam-like keywords, perhaps it will work this time: I'd like to report this here but I don't really have a general solution. Perhaps someone who knows better can comment. In git-1.6.1.2 [1.5] and git-1.6.4.2 [1.7] there is a command called 'git-mergetool' that is used as a wrapper for various graphical merging tools, such as kdiff3. It makes local copies of the relevant commits and brings up an interactive gui for resolving merge conflicts. In git-1.6.4.2 there is a new command called 'git difftool' that does a very similar thing, except it's designed to show the output of 'git diff' in a graphical tool, rather than a merge. git-mergetool works very well with a native Windows (i.e. not Cygwin) installation of kdiff3 because it creates its working files in the current working directory, usually called: ./original-file.LOCAL..ext and ./original-file.REMOTE..ext. Because these paths are relative to the CWD, the non-Cygwin version of kdiff3 handles this fine. E.g: kdiff3 --auto --L1 build.xml (Base) --L2 build.xml (Local) --L3 build.xml (Remote) -o build.xml ./build.xml.BASE.5512.xml ./build.xml.LOCAL.5512.xml ./build.xml.REMOTE.5512.xml But git-difftool does something slightly different - it creates the temporary versions of the file in /tmp with a random prefix, e.g. /tmp/Vc0BZy_original-file. This causes the Windows version of kdiff3 to fail to open the file, because the path /tmp/ is invalid. In my case, the path that would work is c:/cygwin-1.7/tmp/... instead: kdiff3 --auto --L1 build.xml (A) --L2 build.xml (B) /tmp/Vc0BZy_build.xml build.xml It's the /tmp/... bit that kdiff3 can't understand. On the other hand, this command does work: kdiff3 --auto --L1 build.xml (A) --L2 build.xml (B) c:/cygwin-1.7/tmp/Vc0BZy_build.xml build.xml Perhaps git-difftool should create the temporary file in CWD just like git-mergetool, rather than the Cygwin-specific path /tmp? I'm using the Windows version of kdiff3 to avoid dependency on the graphical X libraries that Cygwin's kdiff3 would require. I think it's a fairly common thing to do when working with git on Windows. I can see that the Cygwin version of kdiff3 would probably not exhibit this problem. I imagine the same problem will occur with other Windows versions of merge/diff tools. I also understand if there's no intention by the Cygwin git maintainer to support non-Cygwin gui merge tools, but I don't think I'm the only person using them extensively. -- David. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [1.7] git-difftool paths unusable by win32 kdiff3
On Wed, Dec 2, 2009 at 10:11, Jeremy Bopp wrote: David Antliff wrote: On the other hand, this command does work: kdiff3 --auto --L1 build.xml (A) --L2 build.xml (B) c:/cygwin-1.7/tmp/Vc0BZy_build.xml build.xml As a fairly simple workaround, you could create a wrapper script which takes the same set of arguments git difftool gives to kdiff3 and converts the given file paths using cygpath -w before exec'ing the real kdiff3. Then you can point to that wrapper by setting the git configuration variable difftool.kdiff3.path to the path for the wrapper script. Run git difftool --help for more information. Jeremy, thank you for your reply. It's slightly more complicated than this, because I need a way to translate /tmp to the Cygwin installation directory. I.e. it's not a simple case of replacing /tmp with c:/tmp but rather $CYGWIN_INSTALL_DIR/tmp and I'm not sure CYGWIN_INSTALL_DIR or anything similar exists. This is because my users have cygwin installed in different places. For example, some have it on c:\cygwin, others d:\cygwin and even c:\cygwin-1.5 or c:\cygwin-1.7. I need a general way to determine the Cygwin installation path. Any ideas? Is there a supported way for a script to determine the Cygwin installation directory, perhaps relative to /cygdrive or as a DOS path? -- David. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [1.7] git-difftool paths unusable by win32 kdiff3
On Wed, Dec 2, 2009 at 10:58, Jeremy Bopp jer...@bopp.net wrote: There is a purpose built tool specifically to handle this which I mentioned in my reply. My apologies - I am familiar with the cygpath tool but I had never realised that it treats paths in the cygwin directory like that. I had always thought it just converted /cygdrive/X/ to X:/ and vice-versa. It does what I need. Thanks. -- David. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [1.7] git checkout or clean fails to unlink submodule
On Mon, Nov 23, 2009 at 17:26, Eric Blake wrote: According to David Antliff on 11/22/2009 9:20 PM: Any suggestions how to investigate this further? Is there some way that Windows or Cygwin is somehow preventing the deletion of this directory? More likely, this is due to the fact that git submodule is still an interface in progress, and this is likely to be an upstream limitation. I'd see if you can reproduce it on Linux, and if so, report it upstream. Which reminds me, I need to package a newer version of git soon. Ok, I'll see if I can reproduce in Linux in the next day or two. I would be happy to test (as in, use day to day) a newer version of git on Cygwin if you do package a new one for 1.7 :) -- David. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [1.7] git checkout or clean fails to unlink submodule
On Mon, Nov 23, 2009 at 17:26, Eric Blake wrote: According to David Antliff on 11/22/2009 9:20 PM: Any suggestions how to investigate this further? Is there some way that Windows or Cygwin is somehow preventing the deletion of this directory? More likely, this is due to the fact that git submodule is still an interface in progress, and this is likely to be an upstream limitation. I'd see if you can reproduce it on Linux, and if so, report it upstream. Which reminds me, I need to package a newer version of git soon. I've built git-1.6.4.2 from source on Linux (Ubuntu 8.04.3) and tried the same test case. In this situation I get the following warning: $ git checkout -f master warning: unable to unlink build: Is a directory This seems like a much more sensible warning message than Operation not permitted on Cygwin - perhaps there's something that can be improved there? The fact that it doesn't delete the directory is OK with me, and is certainly not a Cygwin issue. However I note that the 'build' directory is still not removed by 'git clean -fdx' so it looks like that is a real-git problem, not a Cygwin-git problem. I tried the same thing with the latest release tagged version of git, 1.6.5.3, on Linux and it behaves the same way as 1.6.4.2. So as this thread was really triggered by the ominous Operation not permitted warning, I'm not sure there's a Cygwin issue here, except perhaps that warning could be the same as the Linux warning - Is a directory - instead? Perhaps this message comes from the Cygwin OS in which case it might not be fixable in git. -- David. -- 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
[1.7] git checkout or clean fails to unlink submodule
I've noticed that git-1.6.4.2 in Cygwin-1.7 exhibits some unusual behaviour and although I don't know if it's a Cygwin issue. I really don't have a way to check, so I'll simply report it here. I've compared this behaviour with git-1.6.1.2 from Cygwin-1.5, and it does not occur, so it's new behaviour in git-1.6.4.2. The problem concerns sub-modules. With git-1.6.1.2, when using 'git checkout' to move away from a branch that has a submodule (build) associated to a branch that does not have that submodule associated, I get the following warning message: $ git checkout -f master warning: unable to unlink build: Operation not permitted The concerned directory remains undeleted. I note with the older git that it also doesn't remove the directory, but no warning is displayed. But what is concerning is that a subsequent 'git clean -fdx' does not remove the submodule directory either. With git-1.6.1.2 the directory would be deleted by: $ git clean -fdx But with 1.6.4.2 it instead says: $ git clean -fdx Removing build $ ls -l ... drwxr-x---+ 1 dantliff Domain Users 0 2009-11-23 17:01 build The 'build' directory is untracked so 'git clean -d' should remove it, but it doesn't. Any suggestions how to investigate this further? Is there some way that Windows or Cygwin is somehow preventing the deletion of this directory? Note that I do not have any other processes accessing this directory or any files within the directory, and I have a file locking application (Unlocker Assistant) that seems to confirm this. -- David. -- 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: symlinks show .exe
2009/10/5 Vincent Rivière vincent.rivi...@freesbee.fr: Do you agree this is a bug and it should be fixed ? I've got nothing to do with the code, but I am an interested observer. In my experience, it should be possible to create symlinks to any arbitrary target, regardless of whether it actually exists or not. Therefore, if I create a symlink to /bin/ls then I'd expect that to be the content of the symlink - the automatic behaviour of rewriting it to /bin/ls.exe is unexpected and therefore probably incorrect according to some standard somewhere. Perhaps the 'shortcut' of omitting the .exe extension is getting in the way here - it's preventing unambiguous identification of the symlink target. But maybe I misunderstand the scope of symlinks and something somewhere says the system can rewrite them to point at valid targets if it wishes? -- David. -- 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 mintty error - cannot run mintty more than once at a time
On Thu, Oct 1, 2009 at 07:24, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: This is probably one of those cases where 1.5 and 1.7 can't coexist. If you're running pty processes from each then you'll have this problem. Today I had a lull in work so I was able to close all my apps and reboot my PC - an event I often have to plan days in advance for I'm afraid. Upon resurrection, I now note that this problem seems to no longer occur. I can open multiple 1.5 and 1.7 mintty sessions without any apparent problems. I'm still not able to launch 1.7's apache2 however - but that's the subject of another email. Thanks for everyone's responses. -- David. -- 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: Apache2 on Cygwin 1.7 does not start (cygserver is running)
On Tue, Sep 29, 2009 at 17:01, David Antliff david.antl...@gmail.com wrote: So there must be something different with 1.7 that isn't covered by those instructions - does anyone know what this might be, please? I still haven't made any progress with this - I suspect it's something to do with cygserver. Perhaps a conflict with 1.5? It would be great to get apache working in 1.7... -- David. -- 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
Installing 1.7 alongside 1.5 - can it be done safely?
I have found some serious issues with Cygwin 1.5 that I want to test against in the 1.7 beta, before I commit to abandoning 1.5. Is it possible to install Cygwin 1.7 on the same PC/filesystem as Cygwin 1.5, yet maintain absolute independence between the two versions? I don't want the 1.7 install to change anything in my existing 1.5 install, as I need my 1.5 functional for other purposes. Is it a simple matter of installing to a different path (e.g. c:\cygwin1.7), or will the 1.7 install overwrite anything (e.g. environment variables, registry entries) that 1.5 might require? -- David. -- 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: Installing 1.7 alongside 1.5 - can it be done safely?
On Tue, Sep 29, 2009 at 14:08, Chris Cormie cjcor...@gmail.com wrote: I followed this sage advice and so far my parallel 1.5 / 1.7 installs are not interfering with each other. Thanks Chris, and DaveK. I shall proceed with caution :) -- David. -- 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
Apache2 on Cygwin 1.7 does not start (cygserver is running)
Today I was able to get Apache2 running on Cygwin *1.5* using these instructions: http://www.issociate.de/board/goto/895433/apache2_does_not_start_in_cygwin.html The CYGWIN=server variable was critical. I now have Cygwin 1.7 installed side-by-side with 1.5, and as far as I can tell, the two do not interfere. However, I am unable to launch apache2 in Cygwin 1.7. Initially I followed the same directions, and got this: $ echo $CYGWIN $ export CYGWIN=server $ cygserver-config ... $ net start cygserver The CYGWIN cygserver service is starting. The CYGWIN cygserver service was started successfully. $ /usr/sbin/apachectl2 start /usr/sbin/apachectl2: line 78: 1372 Bad system call $HTTPD -k $ARGV Hmmm. I checked the 1.7 change log and it says that the CYGWIN=server setting is now obsolete. However leaving this out doesn't help either. Note that I made sure I shut down cygserver from 1.5 before I tried it with 1.7, and I also have apache2 configured to listen on different ports, just in case they were both running at the same time (which I didn't allow anyway). So there must be something different with 1.7 that isn't covered by those instructions - does anyone know what this might be, please? -- David. -- 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
Cygwin 1.7 mintty error - cannot run mintty more than once at a time
I've been using Cygwin 1.7 alongside Cygwin 1.5 quite happily for the last few hours, however all-of-a-sudden when I try and run mintty (from cygstart or from a cmd.exe shell) I get a new window with this error message: Failed to create child process: No such file or directory Hitting enter makes the window close. I messed around with this for a while until I discovered something very obvious - I already had a mintty running. It appears that in Cygwin 1.7 I cannot run more than one instance of mintty at a time. In 1.5, I have happily run many, many instances simultaneously. However I can run bash.exe without a problem, and in doing so I tried an strace: ... 115 166255 [main] mintty 4336 tty_list::allocate: tty1 allocated 91 166346 [main] mintty 4336 fhandler_pipe::create_selectable: CreateNamedPipe: name \\.\pipe\cygwin-tty1-from-master, size 131072 144 166490 [main] mintty 4336 fhandler_pipe::create_selectable: pipe read handle 0x6C4 82 166572 [main] mintty 4336 fhandler_pipe::create_selectable: CreateFile: name \\.\pipe\cygwin-tty1-from-master 103 166675 [main] mintty 4336 fhandler_pipe::create_selectable: pipe write handle 0x6CC 85 166760 [main] mintty 4336 fhandler_pipe::create_selectable: CreateNamedPipe: name \\.\pipe\cygwin-tty1-to-master, size 131072 242 167002 [main] mintty 4336 fhandler_pipe::create_selectable: pipe busy 77 167079 [main] mintty 4336 seterrno_from_win_error: /netrel/src/cygwin-1.7.0-61/winsup/cygwin/fhandler_tty.cc:1439 windows error 231 79 167158 [main] mintty 4336 geterrno_from_win_error: windows error 231 == errno 16 73 167231 [main] mintty 4336 __set_errno: void seterrno_from_win_error(const char*, int, DWORD):319 val 16 84 167315 [main] mintty 4336 fhandler_pty_master::setup: tty1629019509 open failed - failed to create (null) 89 167404 [main] mintty 4336 open: -1 = open (/dev/ptmx, 0x8002) 83 167487 [main] mintty 4336 __set_errno: int openpty(int*, int*, char*, termios*, winsize*):128 val 2 Looks like there's a busy pipe that is causing mintty to abort? Is this a bug with mintty? -- David. -- 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: bash pipeline exit code - possible race condition?
On Thu, Jul 30, 2009 at 11:31, Christopher Faylorcgf-use-the-mailinglist-ple...@cygwin.com wrote: On Wed, Jul 29, 2009 at 05:16:24PM +1200, David Antliff wrote: I've noticed a strange problem with bash pipelines in Cygwin that might indicate some sort of race condition. I cannot reproduce the problem on a Linux system, but it seems easy to reproduce in Cygwin. This doesn't appear to be a cygwin problem. I get occasional errors on linux as well. I tried to reproduce on Linux but without success - did you simply run my script or perhaps something else? Do you see error 141 as well? If that is the case, then I might take this to... the bash people? the make people? Hmmm -- David. -- 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
bash pipeline exit code - possible race condition?
I've noticed a strange problem with bash pipelines in Cygwin that might indicate some sort of race condition. I cannot reproduce the problem on a Linux system, but it seems easy to reproduce in Cygwin. I'm running the following command in a bash script that builds some software: /usr/bin/make --version | head -1 I then test the exit code ($?) against zero and abort if it's non-zero. Before this executes I have set: set -o pipefail This is to ensure that if any command in a pipeline fails, the entire command will return a failed error code. I.e. if make returns non-zero, then $? will be non-zero. Without pipefail, $? is set to the exit code of the last process in the pipeline (head), regardless of the error code of preceding programs (make). I am doing this because I want the script to log the version of Make that it is using, as well as verify that the make binary is present. Most of the time this works fine, $? is zero, and the script continues happily. However occasionally $? comes back as the value 141. I think that this value is coming from make because if I turn pipefail off, the error code is always zero and never 141, and there's nothing else in the pipeline. QED. This is very curious (and causes my script to break occasionally) so I wrote a little script to test this out: #!/bin/bash set -o pipefail err_count=0 count=0 while : ; do count=$((count + 1)) /usr/bin/make --version | head -1 /dev/null EC=$? if (( EC != 0 )) ; then err_count=$((err_count+1)) echo $count : $EC ($err_count) fi done This prints results like this: $ ./test-make.sh 84 : 141 (1) 2686 : 141 (2) 10762 : 141 (3) 10767 : 141 (4) 10768 : 141 (5) 10769 : 141 (6) 10770 : 141 (7) 29849 : 141 (8) 30003 : 141 (9) 30004 : 141 (10) 30005 : 141 (11) 30154 : 141 (12) As you can see, it's not very common, but it does happen - about 1 in every 3000 in that run. But I noticed after my screensaver came on that the number of incidents rockets up to a much higher rate: 30307 : 141 (13) 30523 : 141 (14) 30524 : 141 (15) 30587 : 141 (16) 30588 : 141 (17) 30759 : 141 (18) 30912 : 141 (19) 30914 : 141 (20) 31064 : 141 (21) 31455 : 141 (22) 31519 : 141 (23) 31522 : 141 (24) 31611 : 141 (25) 31612 : 141 (26) 31613 : 141 (27) 31824 : 141 (28) 31972 : 141 (29) 32062 : 141 (30) 32128 : 141 (31) 32669 : 141 (32) 33340 : 141 (33) 33490 : 141 (34) 33579 : 141 (35) 33580 : 141 (36) 33946 : 141 (37) etc etc etc I suspected that high system load might exacerbate the problem, so to test this I tried running a high-CPU-load compilation process (FPGA synthesis) in parallel, and yes I can confirm that this seems to cause the incidence rate to increase dramatically. I don't know what error code 141 means because I'm not really sure where it's coming from. I downloaded and browsed the GNU make source but I wasn't able to find anything obvious. If it's any help, I noticed that hitting ctrl-c sometimes generates error code 130 just before termination. Maybe it's related to a broken pipe or something. So it looks like this might be some sort of race condition involving the bash pipe, since it seems timing-affected. I've tried this under Linux (Ubuntu 8.04, GNU make 3.81, bash 3.2.39(1)-release, head (GNU coreutils) 6.10) and it does not happen at all, as far as I can see. I am running Cygwin on Windows XP (service pack 3). $ uname -srv CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2008-06-12 19:34 $ /usr/bin/make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i686-pc-cygwin $ bash --version GNU bash, version 3.2.49(22)-release (i686-pc-cygwin) Copyright (C) 2007 Free Software Foundation, Inc. $ head --version head (GNU coreutils) 6.10 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie and Jim Meyering. -- 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
