Fwd: struct tm problem

2014-03-06 Thread Irfan Adilovic
On Wed, Mar 5, 2014 at 3:05 PM, Corinna Vinschen wrote: > On Mar 5 06:52, Eric Blake wrote: >> On 03/05/2014 03:45 AM, Irfan Adilovic wrote: >> > If it is recognized that the executable was compiled against a >> > different sized struct tm, how would you instruct cygwin1.dll code not >> > to write

setup-x86.exe exits before installation is complete

2014-03-06 Thread Jon Beniston
Hi, It seems recent versions of setup-x86.exe exit before the installation is complete. Without the --no-admin option, the main installation is run as a child process, and the parent doesn't wait for the child to complete. This can cause a bit of a problem for other installers that install Cygwin

Re: Fwd: struct tm problem

2014-03-06 Thread Marco Atzeri
On 06/03/2014 13:17, Irfan Adilovic wrote: On Wed, Mar 5, 2014 at 3:05 PM, Corinna Vinschen wrote: On Mar 5 06:52, Eric Blake wrote: On 03/05/2014 03:45 AM, Irfan Adilovic wrote: If it is recognized that the executable was compiled against a different sized struct tm, how would you instruct

bash adds dot to $PATH (was: Re: $PATH contains dot but unclear where it comes from)

2014-03-06 Thread Robert Klemme
Folks, sorry for the delay, I was sick in the meantime. Now, I try to summarize all my finding in the hopes that bash package maintainer can pick up from here. When starting a terminal on my Windows 7 64 bit system $PATH contains a dot at the end. The dot is not present in my Windows environment

Re: bash adds dot to $PATH (was: Re: $PATH contains dot but unclear where it comes from)

2014-03-06 Thread Eliot Moss
If it is of any use, the versions I have installed, bash/sh 4.1.10(4), have the same length and differ in two byte positions, by one bit in each case. These differences may just reflect the different name or a slightly different time at which the .exe was constructed as part of a build process.

Bash scripts give no output

2014-03-06 Thread Jostein Berntsen
I have fiddled around in my cygwin to get ledger installed with not much luck. When I got it running it gives not outpu, The same goes for bash scripts as well as taskwarrior. I tried to reinstall some cygwin components, but that did not work. The scripts run but gives no output and no errors. Any

1.7.28, Windows 7: some commands very slow - especially the git prompt

2014-03-06 Thread Tom Bujok
Hi guys I am using the newest version of cygwin (1.7.28) on my Lenovo Windows 7 machine (4 cores, SSD disk, 12GB RAM) I have installed oh-my-zsh and the prompt is extremely slow. I've executed a simple test "time git branch" in a folder with a sample git repo - and it takes around 100 - 150 ms - w

Re: Cygwin64 ignoring /etc/passwd shell field?

2014-03-06 Thread Ken Brown
On 3/3/2014 10:05 AM, Corinna Vinschen wrote: On Mar 3 08:55, Charles Wilson wrote: On 2/26/2014 5:07 AM, Corinna Vinschen wrote: Weird, I was pretty sure we already have an /etc/shells file installed by default. Apparently not. So, shan't we add one? /bin/sh /bin/bash /bin/dash

Re: Win32 error 109

2014-03-06 Thread David Conrad
On Tue, Mar 4, 2014 at 6:44 PM, Wm. David Bentlage wrote: > I occasionally get errors like the following and don't understand > what's going on. Is there a way to correct this? > > user@machine /w/dir > $ tail -n1 safe*i | grep -i root | wc > 6 24 534 > 70 [main] bash 7012 sig_

Re: 1.7.28, Windows 7: some commands very slow - especially the git prompt

2014-03-06 Thread Larry Hall (Cygwin)
On 3/6/2014 2:25 PM, Tom Bujok wrote: My question is: could these network drives cause the git.exe to be slow and if yes, what's the best way to umount/disable these network drives so that my prompt is quick again. Unless the network drives are in your path before any Cygwin executables that yo

Re: Win32 error 109

2014-03-06 Thread Christopher Faylor
On Thu, Mar 06, 2014 at 05:09:18PM -0500, David Conrad wrote: >On Tue, Mar 4, 2014 at 6:44 PM, Wm. David Bentlage wrote: >> I occasionally get errors like the following and don't understand >> what's going on. Is there a way to correct this? >> >> user@machine /w/dir >> $ tail -n1 safe*i | grep -i