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 ham
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 127.0.0.1:/nfs.
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 start
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 use
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
>> >
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 authentic
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: http://cyg
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.
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 compati
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 w
I use this:
userchar='$'
if [ "${WINDIR-}" ]; then
if net session > /dev/null 2>&1; 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 o
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: http://cygwin.c
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 use
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
>> >
Also, strace'ing startxwin was not fruitful--the program hangs without
putting up any windows or doing much work at all.
I'm open to more suggestions...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.c
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
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 "xte
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.
>> >
>> >
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
>&g
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
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
>> >
>>
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 fil
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 variation
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
>> >
>>
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 can
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 WINP
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: http://cygwin.com/ml/#unsubscribe-si
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 cygw
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 w
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 yo
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: ht
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: http://cygwi
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/
Docu
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
Un
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 i
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 outbo
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
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
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
C:\cygwin\usr\loca
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 p
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:
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 ca
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 ca
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 ha
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 - could
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
Jav
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: f
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 fi
Mar 23, 2011 at 09:08:48PM +0100, Corinna Vinschen 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.
>> &g
Mar 23, 2011 at 09:08:48PM +0100, Corinna Vinschen 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.
>> &g
I'm going to start a new thread, since I don't want the previous
thread subject to make people miss it.
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
Chris Sutcliffe 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.
>> >>
>&g
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.
>>
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 in
>> 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: http://cygw
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 authent
Eric Blake 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\system
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 61027
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
Unsubscri
Eric Blake 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, d
Brian L. 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 the o
Eric Blake 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 regarding
Eric Blake 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
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
Brian L. 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 seem
David Antliff wrote:
>> On Thu, Dec 24, 2009 at 07:55, Kevin Layer 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, do
David Antliff 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 32-bit Windows
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% (3300/
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
/usr/local/libexec/git
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/9
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/9
type 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:
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 i
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
0.12.1-3
libintl3 0.14.5-1
libintl8 0.15-1
libncurses5 5.2-1
libncurses6 5.2-8
libncurses7 5.3-4
libncurses8 5.5-3
libpcre0 6.6-1
libpopt0 1.6.4-4
libreadline4 4.1-2
libreadline5 4.3-5
libreadline6
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 comm
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 l
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 *ar
output
result = 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:
/* demonstrate a bug in capturing the exit code from shell */
#include
#include
#include
#include
#include
#include
#define _POSIX_
#include
#include
#include
main (int argc, char *argv[])
{
exit(1);
}
/* demonstrate a bug in capturing the exit code from shell */
#include
#include
Found the problem: I had a file named `rm':
D:\acl62\src\cl\src>ls -l rm
-rw-r--r--1 layerNone0 Jan 28 15:47 rm
D:\acl62\src\cl\src>getfacl 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
An easier way of reproducing it:
d:\acl62\src\cl\src>ls -l foo.out
-rw-r--r--1 layerNone6 Jan 28 14:39 foo.out
d:\acl62\src\cl\src>sh -c 'rm foo.out'
d:\acl62\src\cl\src>ls -l foo.out
-rw-r--r--1 layerNone6 Jan 28 14:39 foo.out
d:\
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, i
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\cl>cygcheck -s -h
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
>> 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
>> 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, g
>> 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\bi
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:\bug>PATH C:\Cygwin\bin;c:\cygwin\usr\bin;C:\Cygwin\u
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$ ech
91 matches
Mail list logo
