I didn't include the cygwin version info. I updated recently. I used
the 64-bit installer. This problem has been happening for years.
It's just worse recently. I used to be that it was very intermittent,
but now I can't get through a complete test iteration (which is about
80 invocations of
I have a C program (attached) that I run to test a Windows NFS server
(built in Lisp, https://github.com/franzinc/nfs).
I can run this program on Linux and I've never had a problem with it.
On Windows, I randomly get errors like this:
./hammernfs.exe -i 3 -v 2 -t 60 -b 8192 -p tcp
Here's what worked for me:
Ran ssh-host-config as administrator and took defaults, except
priviledge separation => no
install as a service => no
Then, I chown'd /var/empty to Administrator and was able to run
"sshd -p 8100" and ssh into the box.
More importantly, other users were able to
I need to be able to SSH into a Windows machine with Cygwin installed
and be able to run Windows programs and see the Windows they create.
That is, when I run "notepad" I need to see the Window it creates.
And, I need multiple users to be able to do this.
In the past, I did this by having each
Achim Gratz wrote:
>> Kevin Layer writes:
>> > I've tried various ssh-host-config permutations, but I just ran
>> >
>> > cygrunsrv.exe -R sshd
>> >
>> > and ran ssh-host-config with the defaults. I started the sshd service
>> > and
I've tried various ssh-host-config permutations, but I just ran
cygrunsrv.exe -R sshd
and ran ssh-host-config with the defaults. I started the sshd service
and when I ssh to it:
@freon[git:master]$ ssh -vv4 thunder
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
...
debug1: Next
I'm running sshd on Windows (Server 2008 R2). When I run Windows
programs via ssh the windows are not visible. I realize this is a
long shot, but is there any fix or workaround or hack to this?
We run sshd under the cyg_server domain account.
Thanks.
Kevin
--
Problem reports:
Gaspare Argento wrote:
Hi,
i have a question about the Google Command Line Tool present in Cygwin.
I used googlecl to manage my Google Calendar Events until last
November. Due to the deprecation of the Calendar GData API (v1, v2)
made by Google this service now doesn't work. A good
Richard H. McCullough wrote:
I have an iMac 27 64-bit words running OS X Mavericks.
Can I install Cygwin on my iMac?
I know it's not necessary, but I thought it might be helpful
for working on system porting/compatibility problems.
Try macports.org if you need programs compatible with
I forgot to attach my XWin.0.log. Here it is:
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.14.4.0
OS: CYGWIN_NT-6.3-WOW64 hobart256 1.7.27(0.271/5/3) 2013-12-07 16:27 i686
OS: Windows 8 [Windows NT 6.2 build 9200] (WoW64)
Package: version 1.14.4-1 built 2013-11-11
XWin
I use this:
userchar='$'
if [ ${WINDIR-} ]; then
if net session /dev/null 21; then
userchar='#'
fi
fi
export PS1=$PS1$userchar
I don't remember where I saw it, but it works well for me.
I don't know if it's worse or better, but I'll throw it out
I noticed this, too, recently. I worked around it by running rsync
over ssh, and that solved it for me.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
Earnie Boyd wrote:
Then what is the value of $SHELL?
/bin/bash
What user actually starts the session? I've seen this type of thing
when the cron daemon starts a session. The profile files are never
read.
Don't have cron running. I start it as me, the logged in user, from a
mouse
Earnie Boyd wrote:
On Wed, Feb 27, 2013 at 5:16 PM, Kevin Layer wrote:
Did you read the original report and all the replies in the chain?
...it requires my .bashrc to be sourced (.bash_profile merely sources
.bashrc).
Then what is the value of $SHELL?
/bin/bash
Robert Pendell wrote:
Commonly .bash_profile does source in .bashrc so that it gets executed too.
Exactly what mine does. I just want to be clear: I have not been able
to get bash to source *anything* when started from startxwin.exe.
I've done hours of experimentation and done many variations
Eliot, thanks for the reply.
The passwd/group was an interesting thought. Unfortunately:
@oob2$ mkpasswd -l passwd.new
@oob2$ diff passwd passwd.new
@oob2$ mkgroup -l group.new
@oob2$ diff group group.new
@oob2$
It's not just mintty. When I run xterm, it doesn't source any of my
init
Jon TURNEY wrote:
On 27/02/2013 00:08, Kevin Layer wrote:
If I put this into .startxwinrc:
mintty /usr/bin/bash.exe --login -i
the resulting shell does not read .bash_profile. If I put
mintty /usr/bin/bash.exe -i
it doesn't read .bashrc.
I've tried to reproduce
K Stahl wrote:
I normally start a terminal in my .xinitrc file (Place it in your home
directory):
Example:
#!/usr/bin/sh
urxvt -e bash -l wmpid=$!
wait ${wmpid}
Bash started via .xinitrc *does* read my .bashrc. Interesting!
I'll play more with this tonight to see if I can get my
Andrey Repin wrote:
Greetings, Kevin Layer!
I know ~/.bashrc hasn't been read because my prompt is not changed and
my aliases are not there.
That's just assumption. Not the first-hand knowledge. It may be true, or
not... Best way to know is to place
set -x
around the start
Earnie Boyd wrote:
On Wed, Feb 27, 2013 at 3:15 PM, Kevin Layer wrote:
That was one of the experiments I did, and I saw no evidence that any
commands were executed. I even passed it as the argument to the
invocation.
As for the assumption, I understand that an error could have
short
K Stahl wrote:
I normally start a terminal in my .xinitrc file (Place it in your home
directory):
Example:
#!/usr/bin/sh
urxvt -e bash -l wmpid=$!
wait ${wmpid}
Turns out, I'm mistaken, but I found out something interesting.
I had created a .xinitrc with a single xterm call in it,
Btw, this happens on my home and work systems. Both Windows 7
Ultimate x64.
--
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
Also, strace'ing startxwin was not fruitful--the program hangs without
putting up any windows or doing much work at all. sigh
I'm open to more suggestions...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
If I put this into .startxwinrc:
mintty /usr/bin/bash.exe --login -i
the resulting shell does not read .bash_profile. If I put
mintty /usr/bin/bash.exe -i
it doesn't read .bashrc.
I've been beating my head against this wall for hours, over a few
days. I've googled my ass off, but I
Arthur Tu wrote:
On 2/27/2013 8:08 AM, Kevin Layer wrote:
If I put this into .startxwinrc:
mintty /usr/bin/bash.exe --login -i
the resulting shell does not read .bash_profile. If I put
mintty /usr/bin/bash.exe -i
it doesn't read .bashrc.
I've been beating my head
I have scripts to fetch and rebase a list of 50+ repos. I run this on
a 16-core AMD Windows Server 2008 R2 machine. In about 1 out of 10
times, I get a git fetch origin that uses 100% of a core until
killed.
It just happened again a few minutes ago:
$ ps aux
PIDPPIDPGID
Corinna Vinschen wrote:
On Feb 1 11:44, Kevin Layer wrote:
Larry Hall (Cygwin) wrote:
On 1/30/2012 5:53 PM, Kevin Layer wrote:
Well over 200 clones with no error with the stock 1.7.9 cygwin1.dll,
changing nothing else on the machine.
Can you check for the most
More than 2600 iterations. I'd say this snapshot doesn't have this
particular bug.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
Larry Hall (Cygwin) wrote:
On 1/30/2012 5:53 PM, Kevin Layer wrote:
Well over 200 clones with no error with the stock 1.7.9 cygwin1.dll,
changing nothing else on the machine.
Can you check for the most recent snapshot that does work for you?
It took a while, but it works
Larry Hall (Cygwin) wrote:
On 1/27/2012 5:32 PM, Kevin Layer wrote:
This is the failure mode:
$ rm -fr test; git clone git:/repo/git/composer test
Cloning into test...
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
Is this failure new
Christopher Faylor wrote:
On Fri, Jan 27, 2012 at 02:32:54PM -0800, Kevin Layer wrote:
I don't know what happened to the email in transit, but much
information at the head of the email was chopped off. From my outbox,
here's the missing bit:
*
This is the failure mode
Christopher Faylor wrote:
On Mon, Jan 30, 2012 at 08:05:46AM -0800, Kevin Layer wrote:
Christopher Faylor wrote:
Is this new behavior just seen with this snapshot or is it something you
noticed in 1.7.9? If you've just seen it in the latest snapshot it
would be useful (as I've previously
I've reverted the cygwin1.dll to the released 1.7.9 version. I will
do a bunch of testing to see if I get clone failures, and report back.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
I already got through one iteration of cloning all 52 repos, and I
wasn't able to do that with the 1/23 snapshot in place.
I'll keep running it, in a loop, to see if I ever get a failure.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Well over 200 clones with no error with the stock 1.7.9 cygwin1.dll,
changing nothing else on the machine.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
I swapped back in the 1/23 cygwin1.dll and ran the test. It failed on
the first clone.
I'm done with my testing. Let me know if there's something else you
want done.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
Larry Hall (Cygwin) wrote:
On 1/30/2012 5:53 PM, Kevin Layer wrote:
Well over 200 clones with no error with the stock 1.7.9 cygwin1.dll,
changing nothing else on the machine.
Can you check for the most recent snapshot that does work for you?
It took a while, but it works in 11/24
Cygwin Configuration Diagnostics
Current System Time: Fri Jan 27 14:24:45 2012
Windows 7 Ultimate Ver 6.1 Build 7601 Service Pack 1
Running under WOW64 on AMD64
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Perl64\site\bin
C:\Perl64\bin
.
C:\bin
C:\sbin
C:\cygwin\bin
I don't know what happened to the email in transit, but much
information at the head of the email was chopped off. From my outbox,
here's the missing bit:
*
This is the failure mode:
$ rm -fr test; git clone git:/repo/git/composer test
Cloning into test...
fatal: The remote end
Christopher Faylor wrote:
On Tue, Jan 24, 2012 at 10:03:05PM -0800, Kevin Layer wrote:
Larry Hall (Cygwin) wrote:
This problem is killing me. I'm currently looking msysgit + GnuWin32
because I just can't take the crashes of bash.exe and git.exe anymore.
In my testing, so far, I've
Christopher Faylor wrote:
On Tue, Jan 24, 2012 at 10:03:05PM -0800, Kevin Layer wrote:
Larry Hall (Cygwin) wrote:
This problem is killing me. I'm currently looking msysgit + GnuWin32
because I just can't take the crashes of bash.exe and git.exe anymore.
In my testing, so far, I've
I now have several hours of intense use, and I haven't seen one
crash. Kudos to all that have contributed to this fix.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
Robert Miles wrote:
NOTE: I run with CYGWIN=nodosfilewarning proc_retry:1 because I run
a lot of non-cygwin software from shell scripts, and during testing,
that can take 10's of minutes, I can't afford to have those programs
restarted if they crash on exit. Before setting proc_retry:1,
I wish I could report success like you.
Using 20120123, just printing my prompt, which runs git rev-parse
and git branch, I saw this (pd is an alias for pushd):
thor$ pd
/home/scm/acl90b.64 /home/scm/acl90b.64/src/cl/src
7 [main] bash 1732 c:\cygwin\bin\bash.exe: *** fatal error - couldn't
Larry Hall (Cygwin) wrote:
This problem is killing me. I'm currently looking msysgit + GnuWin32
because I just can't take the crashes of bash.exe and git.exe anymore.
In my testing, so far, I've never seen msysgit or the bash that comes
with it crash. Why is it that cygwin has this
I want to go on record that it happening to us, too. And, I can say
that it is happening *much* more since I moved to this machine:
2x AMD Opteron 6134 (16 cores total)
Server 2008 R2 Enterprise, Service Pack 1
Software we have installed on the machine:
ActivePerl
AVG 9.0
Chrome
I'm testing a new machine. It's running Server 2008 R2 (64-bit) on a
dual AMD Opteron 6134. The machine has 48GB of RAM and is nowhere
near being used up. cygcheck -s at end.
When running make, which spawns shell scripts from time to time, I see
this:
making testxgc.dll
../../version.sh:
I'm rsync'ing some files from a Windows XP SP3 box running the latest
cygwin to a local disk on a linux box running Fedora 13. Here's the
message:
+ rsync -qa --delete --delete-before rsync://hobart/src/
/backups/hobarts/hobart/c/src/2011.05.02-14:48:10
rsync: readdir(/. (in src)): No such
wrote:
On Mar 23 11:51, Kevin Layer wrote:
On 03/22/2011 06:24 PM, Kevin Layer wrote:
This is on Windows 7 64-bit.
[...]
CYGWIN_NT-5.2-WOW64 hobart128 1.7.9s(0.236/5/3) 20110323 01:32:07 i686
Cygwin
Er... this isn't W7, that's XP or 2K3.
Yeah, it would make sense if this was 64
wrote:
On Mar 23 11:51, Kevin Layer wrote:
On 03/22/2011 06:24 PM, Kevin Layer wrote:
This is on Windows 7 64-bit.
[...]
CYGWIN_NT-5.2-WOW64 hobart128 1.7.9s(0.236/5/3) 20110323 01:32:07 i686
Cygwin
Er... this isn't W7, that's XP or 2K3.
Yeah, it would make sense if this was 64
Eric Blake ebl...@redhat.com wrote:
On 03/22/2011 06:24 PM, Kevin Layer wrote:
This is on Windows 7 64-bit.
The crash at the end left an index.lock file.
Please let me know what I can do to help track down the problem.
It's already tracked down - it's a bug in Microsoft's
Chris Sutcliffe ir0nh...@gmail.com wrote:
On 22 March 2011 21:33, Eric Blake wrote:
On 03/22/2011 06:24 PM, Kevin Layer wrote:
This is on Windows 7 64-bit.
The crash at the end left an index.lock file.
Please let me know what I can do to help track down the problem.
It's already
I'm going to start a new thread, since I don't want the previous
thread subject to make people miss it.
Eric Blake ebl...@redhat.com wrote:
On 03/22/2011 06:24 PM, Kevin Layer wrote:
This is on Windows 7 64-bit.
The crash at the end left an index.lock file.
Please let me know what I
I see this on my XP32 system:
+ git fetch
Warning: No xauth data; using fake authentication data for X11 forwarding.
From git:/repo/git/cl
75d375e..4ed5ea6 acl82 - origin/acl82
a5421cc..f0ac11c master - origin/master
+ git fetch --tags
Warning: No xauth data; using fake
When I look in the .git directory, the file index.lock is *not* there.
Nevermind. I was looking in the wrong .git directory. There is a
lock file there, presumably from before I started using the snapshot
that fixed the git crashes.
Sorry for the noise.
--
Problem reports:
This is on Windows 7 64-bit.
The crash at the end left an index.lock file.
Please let me know what I can do to help track down the problem.
Kevin
+ git rebase --whitespace=nowarn private/layer-scm
First, rewinding head to replay your work on top of it...
Applying: add regression files
Using
Anyone else seen this?
hobart$ git reset --hard a000933
5 [main] git 2832 C:\cygwin\bin\git.exe: *** fatal error - could not load
C:\WINDOWS\system32\winmm.dll, Win32 error 487
Stack trace:
Frame Function Args
0022AAF4 6102792B (0022AAF4, , , 28602020)
0022ADE4
Eric Blake ebl...@redhat.com wrote:
On 03/15/2011 06:40 PM, Kevin Layer wrote:
Anyone else seen this?
hobart$ git reset --hard a000933
5 [main] git 2832 C:\cygwin\bin\git.exe: *** fatal error - could not
load C:\WINDOWS\system32\winmm.dll, Win32 error 487
Yes. Multiple
I just installed it from source the other day, after checking to see
if it was in cygwin.
http://www.cipherdyne.org/fwknop/download/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Eric Blake ebl...@redhat.com wrote:
On 03/11/2010 04:03 PM, Charles Wilson wrote:
If it is not being worked on... I agree with Brian. This is a serious
impediment to using Cygwin 1.7. I would think it would be of top
priority.
Only people who experience the problem can diagnose,
Brian L. br...@blucz.com wrote:
From this thread I gather that little or no progress has been made on
addressing the root cause of this issue. It still seems to be broken
with the latest 1.7 series packages.
What is the proper method for getting this bug in front of the guys
who maintain
Eric Blake e...@byu.net wrote:
According to Kevin Layer on 1/8/2010 11:01 AM:
Has anyone in the cygwin group reproduced this?
Yes, as maintainer of the git package on cygwin, I've seen sporadic
failures of the git protocol, which I have always ended up working around
by switching over
Eric Blake e...@byu.net wrote:
Yes, as maintainer of the git package on cygwin, I've seen sporadic
failures of the git protocol, which I have always ended up working around
by switching over to an http protocol. I'm assuming that it might either
be BLODA or an actual bug in cygwin1.dll
Has anyone in the cygwin group reproduced this?
--
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
David Antliff david.antl...@gmail.com wrote:
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
Brian L. br...@blucz.com wrote:
I'm seeing very similar bad behavior from cygwin+git on win7 x64 as
well as winxp x86. This bug is not confined to 64 bit platforms. This
bug is new in 1.7.x--I have cygwin 1.5 installs on both of these
machines that do not exhibit this failure.
The problem
David Antliff david.antl...@gmail.com wrote:
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
crickets
I'm a little surprised there are *no* replies to this thread, other
than mine. (It's not like there is no traffic on the mailing list.)
Can someone tell me what I need to do to interest people in this?
Let me summarize: git clone fails with this:
remote: Compressing objects: 100%
smbfs (binary,posix=0,user,noumount,auto)
la...@hobart128 /c/tmp
$
At this point I have no idea what to do. Ideas would be appreciated.
Thanks.
Kevin Layer
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http
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%
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%
I tried to install 1.6.1.2 on 1.7.1, but it didn't work. The clone
complained that the index-pack program was missing. I did the usual
./configure make make install
so I'm not sure what else to try.
I copied git-index-pack.exe from the build directory to
Eric Blake [EMAIL PROTECTED] wrote:
read version foo1.out
I prefer this to the echo -n, because the latter isn't supported on
all the platforms I run on (aix, for one).
Thanks for the help. You guys rock.
Kevin
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem
Mark Fisher [EMAIL PROTECTED] wrote:
if you change the echo's to echo -n you don't get the ^M chars, as
it surpresses the CR in the output.
is this possible on the real scripts you talk about, or is the
version generating script/app not changeable?
The only restriction is that it work on all
6.8.99.901-1
xorg-x11-fnts6.8.99.901-1
xorg-x11-libs-data 6.8.99.901-1
xorg-x11-xwin6.8.99.901-1
xterm202-1
zip 2.32-2
zlib 1.2.3-2
Use -h to see help about each section
--
Kevin Layer [EMAIL PROTECTED]http
Larry Hall (Cygwin) [EMAIL PROTECTED] wrote:
version=`cat foo1.out`
...
Time to adjust your expectations. ;-) Text mounts write CRNL as EOLs
for all files that are not explicitly opened as binary (or text for
that matter). Text mounts remove the CR from EOLs read from files that
are not
Corinna Vinschen [EMAIL PROTECTED] wrote:
I just applied a patch which should return the correct error code.
Ah, yes, I forgot: Please test the next snapshot from
http://cygwin.com/snapshots/
The problem is fixed. Thank you very much, Corinna.
I'd like to second William's comments:
Corinna Vinschen [EMAIL PROTECTED] wrote:
On Feb 6 14:49, Kevin Layer wrote:
I'm running the latest cygwin (1.5.19, see cygcheck below).
My application is a native Windows app (64 and 32-bit). It includes
no cygwin libraries and is not compiled with cygwin's gcc. When I
execute
/* demonstrate a bug in capturing the exit code from shell */
#include stdlib.h
#include stdio.h
#include stdarg.h
#include signal.h
#include string.h
#include errno.h
#define _POSIX_
#include windows.h
#include winsock.h
#include limits.h
main (int argc, char *argv[])
{
exit(1);
}
/*
Below are the files.
Is this a known issue? Any chance of a fix?
--
Kevin Layer [EMAIL PROTECTED]http://www.franz.com/
Franz Inc., 555 12th St., Suite 1450, Oakland, CA 94607, USA
Phone: (510) 452-2000 FAX: (510) 452-0182
--
Unsubscribe info: http://cygwin.com/ml
Samuel Thibault [EMAIL PROTECTED] wrote:
Hi,
Kevin Layer, le Mon 06 Feb 2006 14:37:00 -0800, a écrit :
Content-Description: bug.c
/* demonstrate a bug in capturing the exit code from shell */
main (int argc, char *argv[])
{
int docommand(char *), res;
if (argc 1
I just found a case of `rm' failing in a makefile. I added
SHELL = bash
and the rm worked. Looks like the same deal. This seems pretty
broken. I'm really wondering if anyone else
Note: I have CYGWIN defined as nontsec.
Also, I forgot to include a cygcheck:
D:\acl62\src\clcygcheck -s -h -r
I'm on Windows 2000sp3.
I've seen this bug before, but it disappeared. Now, it's back. I
recently updated to cygwin 1.3.19. Nothing else on my system has
changed in a really long time. I rebooted, and that didn't fix it.
Here's bug2.sh:
ls -l $2
echo removing $2...
rm $2
ls -l $2
First, it
An easier way of reproducing it:
d:\acl62\src\cl\srcls -l foo.out
-rw-r--r--1 layerNone6 Jan 28 14:39 foo.out
d:\acl62\src\cl\srcsh -c 'rm foo.out'
d:\acl62\src\cl\srcls -l foo.out
-rw-r--r--1 layerNone6 Jan 28 14:39 foo.out
Found the problem: I had a file named `rm':
D:\acl62\src\cl\srcls -l rm
-rw-r--r--1 layerNone0 Jan 28 15:47 rm
D:\acl62\src\cl\srcgetfacl rm
# file: rm
# owner: layer
# group: None
user::rw-
group::r--
other:r--
mask:rwx
D:\acl62\src\cl\src
Now, it seems odd that `sh' (but
Peter Davis [EMAIL PROTECTED] wrote:
On Sat, Jan 04, 2003 at 02:14:04AM +0900, Stephen J. Turnbull wrote:
Peter == Peter Davis [EMAIL PROTECTED] writes:
The procedure entry point _ctype_ could not be located in the
dynamic link library cygwin1.dll
Peter So why is
Just to make sure I understand. After doing a complete reinstall with the
latest setup.exe, the mounts are now correct? Please confirm that with
'cygcheck -s' so I can put this to bed in my mind at least.
Yes, reinstall with cleaning the registry. I've been a long time
cygwin user, going
Your /usr/bin and /usr/lib mounts are incorrect. There were some problems
with that with some versions of setup.exe, but I think that has been fixed
now.
I had the latest version of setup.exe (as of yesterday). I decided to
remove cygwin, even cleaning out `cygwin' references in the
I noticed that my windows programs see a strange and bogus PATH.
It is demonstrated here, from cmd.exe:
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
c:\PATH C:\Cygwin\bin;c:\cygwin\usr\bin;C:\Cygwin\usr\local\bin
c:\bash -i
bash-2.05a$ echo
It's worse than I suspected originally, when I thought I could get
around it by not using bash. Now, without bash:
makefile:
SHELL = sh
default: FORCE
echo $(PATH)
/c/winnt/system32/cmd
FORCE:
and now:
D:\bugPATH
What does cygcheck -s say?
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Tue May 21 20:37:06 2002
Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 2
Path: C:\ODI\OStore\bin
.
c:\bin
C:\Perl\bin
C:\Cygwin\bin
c:\cygwin\usr\bin
91 matches
Mail list logo
