How to build dll using libtool-devel (bug?)

2003-01-21 Thread Marcel Telka
Hi.

Problem summary:
I'm unable to build shared library (dll) using current libtool-devel.

Here is a fragment from my build log:

/bin/bash ../libtool --mode=link gcc  -g -O2 -Wall   -o libioperm.la -rpath /usr/lib  
ioperm.lo
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared 
libraries
ar cru .libs/libioperm.a  ioperm.o
ranlib .libs/libioperm.a
creating libioperm.la
(cd .libs && rm -f libioperm.la && ln -s ../libioperm.la libioperm.la)


Problem is probably in my configure script:

cygwin* | mingw* | pw32*)
  # _LT_AC_TAGVAR(hardcode_libdir_flag_spec, ) is actually meaningless,
  # as there is no search path for DLLs.
  hardcode_libdir_flag_spec='-L$libdir'
  allow_undefined_flag=unsupported
  always_export_symbols=no
  enable_shared_with_static_runtimes=yes

If I remove the line with "allow_undefined_flag=unsupported" from the configure
script, dll build works (here is the log):

/bin/bash ../libtool --mode=link gcc  -g -O2 -Wall   -o libioperm.la -rpath /usr/lib  
ioperm.lo
gcc -shared  .libs/ioperm.o   -o .libs/cygioperm-0.dll -Wl,--image-base=0x1000 
-Wl,--out-implib,.libs/libioperm.dll.a
Creating library file: .libs/libioperm.dll.a
ar cru .libs/libioperm.a  ioperm.o
ranlib .libs/libioperm.a
creating libioperm.la
(cd .libs && rm -f libioperm.la && ln -s ../libioperm.la libioperm.la)


Historical info:
Same configuration (same Makefile.am, same sources) built on September 2002
worked ok.
... and configure script was without "allow_undefined_flag=..." line for cygwin.

Questions:
1. How to build dlls using current libtool-devel?
2. Is this a bug in my configuration?
3. Is this a bug in libtool-devel?

Here is my Makefile.am file:
lib_LTLIBRARIES = libioperm.la
libioperm_la_SOURCES = ioperm.c


Thank you.

-- 
+---+
| Marcel Telka   e-mail:   [EMAIL PROTECTED]  |
|homepage: http://telka.sk/ |
|jabber:   [EMAIL PROTECTED] |
+---+

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: How to build dll using libtool-devel (bug?)

2003-01-21 Thread Max Bowsher
Marcel Telka wrote:
> Problem summary:
> I'm unable to build shared library (dll) using current libtool-devel.
> 
> Here is a fragment from my build log:
> 
> /bin/bash ../libtool --mode=link gcc  -g -O2 -Wall   -o libioperm.la
> -rpath /usr/lib  ioperm.lo 
> libtool: link: warning: undefined symbols not allowed in
> i686-pc-cygwin shared libraries 

You need the libtool -no-undefined option, I think.


Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: How to build dll using libtool-devel (bug?)

2003-01-21 Thread Marcel Telka
On Tue, Jan 21, 2003 at 08:26:21AM -, Max Bowsher wrote:
> Marcel Telka wrote:
> > Problem summary:
> > I'm unable to build shared library (dll) using current libtool-devel.
> > 
> > Here is a fragment from my build log:
> > 
> > /bin/bash ../libtool --mode=link gcc  -g -O2 -Wall   -o libioperm.la
> > -rpath /usr/lib  ioperm.lo 
> > libtool: link: warning: undefined symbols not allowed in
> > i686-pc-cygwin shared libraries 
> 
> You need the libtool -no-undefined option, I think.

Yes! Thank you! :-)

-- 
+---+
| Marcel Telka   e-mail:   [EMAIL PROTECTED]  |
|homepage: http://telka.sk/ |
|jabber:   [EMAIL PROTECTED] |
+---+

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: sshd: server refused our key

2003-01-21 Thread Manfred Köhler
...


> > >The permissions and ownership of:
> > >- your home directory
> > drwxr-xr-x  138 mk   group 24576 Nov 20 11:48 .
> > >- your home/.ssh directory
> > drwxr-xr-x2 mk   group  4096 Nov 19 13:44 .ssh
> >- your home/.ssh files
> > seen on UNIX:
> > -rw-r--r--1 mk   group 545 Nov 20 08:48 
> > authorized_keys
> > -rw-r--r--1 mk   group 546 Nov 20 08:48 
> > authorized_keys2
> > -rw---1 mk   group 887 Nov 19 13:44 id_rsa
> > -rw-r--r--1 mk   group 218 Nov 19 13:44 id_rsa.pub
> > -rw---1 mk   group 523 Nov 19 13:44 identity
> > -rw-r--r--1 mk   group 327 Nov 19 13:44 identity.pub
> > -rw-r--r--1 mk   group1442 Nov 20 11:50 known_hosts
> > -rw---1 mk   group 512 Nov 20 11:50 random_seed


are perfectly fine.  What irritates me is the "seen on UNIX"
and "seen inside ssh session".  What does that mean?  From the
cygcheck output I would think the home dir is on the local NTFS
drive C:.  So how can you see anything from UNIX?  You know that
the permission translation between UNIX and NT via Samba doesn't
work flawlessly, don't you?  Could you please enlighten us what
the above wording is trying to say?  And especially interesting
are the permissions on these files seen in a *local* NT session
on that very machine you're trying to connect via ssh.


-	mk is a user on a UNIX host.
-	mk has a domain account on Windows.
-	When mk logs on on Windows, his UNIX home directory is mounted on Windows.
-	mk has a PC with CYGWIN and a runnig ssh demon.
-	When mk is logged in on a UNIX console window and trys to get a secure shell on the
PC with the ssh demon, he is prompted for a password
-	When mk is logged in on a UNIX console window and trys to get a secure shell on 
another UNIX host he is not prompted for a password

I have setup ssh demon using ssh-user-config -y, CYGWIN will be set to "binmode ntsec tty".
/etc/group, /etc/passwd "know" mk as domain user with home directory on a net mounted host.

How can I set up CYGWIN and/or sshd that key authentification works fine?

Manfred





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



configuring xgrafix2.40 on Cygwin 1.3.18-1

2003-01-21 Thread Josh Rembaum
Hi,

I'm trying to install the xgrafix2.40 library (which works under X11) on my 
Win98 computer, using the latest Cygwin version (1.3.18-1) and during the 
configuration it tries to find `libtcl8.3.a', `libtcl8.3.so', `libtk8.3.a', 
and `libtk8.3.so'.

1)  Am I right that the .a files exist as `libcygtcl83.a' and `libcygtk83.a'?

2)  What are the .so files?

3)  Is there something I can do besides downloading and installing tcl/tk 
from its website to get the configure script to recognize the tcl/tk 
libraries as named by Cygwin?

Thank you,

Josh


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Bug in rm -r with locked files

2003-01-21 Thread Gael Mulat
   Hi,

   This is a bug report about rm (package fileutils, version 4.1-1) on W2K.

   Test case: take 2 cygwin shells.
shell 1:
   mkdir /tmp/directory
   vi /tmp/directory/file

shell 2:
   /bin/rm -rf /tmp/directory

   The shell2 doesn't manage to remove the directory and goes into an 
infinite loop, taking 100% of the CPU.
   All is then OK if we go out of vi in the shell1.

   Doing the same thing (deleting the directory) directly in Windows 
produces an error message: "cannot delete directory: Access is denied. 
The source file may be in use" and we can notice in the directory a file 
named .file.swp that is also visible under Cygwin with ls -la.

   The example I have just given uses vi, but it is the same with all 
processes that open the file, as W2K puts a lock on it.

Gael Mulat




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Bug in rm -r with locked files

2003-01-21 Thread David Means




Yep, I concur.  If windows has a lock on the file, rm just hangs.  I've seen it hang on directories when doing an 'rm -rf yada/*"

On Tue, 2003-01-21 at 06:50, Gael Mulat wrote:

Hi,

This is a bug report about rm (package fileutils, version 4.1-1) on W2K.

Test case: take 2 cygwin shells.
shell 1:
mkdir /tmp/directory
vi /tmp/directory/file

shell 2:
/bin/rm -rf /tmp/directory

The shell2 doesn't manage to remove the directory and goes into an 
infinite loop, taking 100% of the CPU.
All is then OK if we go out of vi in the shell1.

Doing the same thing (deleting the directory) directly in Windows 
produces an error message: "cannot delete directory: Access is denied. 
The source file may be in use" and we can notice in the directory a file 
named .file.swp that is also visible under Cygwin with ls -la.

The example I have just given uses vi, but it is the same with all 
processes that open the file, as W2K puts a lock on it.

Gael Mulat




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




-- 
David Means

Different all twisty a of in maze are you, passages little.








signature.asc
Description: This is a digitally signed message part


Re: cvs wont connect to remote

2003-01-21 Thread Max Bowsher
Patrick Nelson wrote:
>  cvs login: authorization failed: server cvs.npn rejected access to
>  for user pnelson
> 
> I have tried everything that I can think of to get this working but
> it just will not log in.   does exist on the
> remote system. I did notice that my Linux clients display something a
> little different when entering "cvs login":
> 
>  Logging in to :pserver:pnelson@:2401/  repos> CVS password:
> 
> and entering the correct password allows all other cvs commands to
> work. I'm not sure why cygwin cvs doesn't display the pserver stuff
> after you enter "cvs login" or even if it matters.  I just don't see
> anything else. Any ideas?

cvs -t login ?


Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Corinna Vinschen
On Tue, Jan 21, 2003 at 12:50:18PM +0100, Gael Mulat wrote:
>Hi,
> 
>This is a bug report about rm (package fileutils, version 4.1-1) on W2K.
> 
>Test case: take 2 cygwin shells.
> shell 1:
>mkdir /tmp/directory
>vi /tmp/directory/file
> 
> shell 2:
>/bin/rm -rf /tmp/directory
> 
>The shell2 doesn't manage to remove the directory and goes into an 
> infinite loop, taking 100% of the CPU.
>All is then OK if we go out of vi in the shell1.

Which version of Cygwin and Vim are you using?  I'm getting this:

  shell 1:
 mkdir /tmp/foo
 vi /tmp/foo/bar
 :w <= To create file `bar'

  shell 2:
 rm -rf /tmp/foo<= returns immediately, having foo removed.

Vim doesn't lock the file, so I wonder what you are discribing here.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Brian . Kelly

YES!  I too concur BIG TIME! In fact, I do not use rm -r in my
scripts because of this problem. In perl scripts I use the Windows command
$output=`cmd /c del /s *.* > 2>&1` (or similar) and examine the output for
ACCESS DENIED, where I can then do an attrib and continue.

AN . since we're on the topic of rm  I have spent a limited
amount of time trying to isolate a NASTY memory leak in NT4.0 SP6 when running
commands via telnet. I have 512 MB of ram and if do a lot of rm's or ls -sh
over a telnet connection, I can actually deplete the memory till the box locks -
usually in as little as 20 minutes. I haven't reported this problem till now
because without more specifics, my experience has been that such posts usually
end up being ignored. And specifics take time and effort to isolate and enumerate.
But, since rm is the topic, I thought I'd piggy-back this issue in case someone
actually does take the time to poke around the source code. In that vein, I've
attached an "overlooked" (or ignored - I expect a "MEAN" response for this -
so FIRE AWAY! \\-> ((o))  ;-) )  post from the archives that addresses an
rm memory leak. I tested it a couple of days ago and YEP - it's still there!!!

Brian Kelly

###

> memory leak? (was: 1.3.9: "fork: Permission denied" (Windows 2000))
> From: "Reddie, Steven" 
> To: cygwin at cygwin dot com
> Date: Thu, 28 Feb 2002 15:30:26 +1100
> Subject: memory leak? (was: 1.3.9: "fork: Permission denied" (Windows 2000))

> 

> There's a memory leak, but I can't work out what is causing it.  None of the
> processes in Task Manager own up to it, so does that mean it's the OS?

> I have been able to reproduce this leak using the scripts included below.
> mkfiles creates 1000 files.  rmfiles removes those 1000 files.  Executing
> mkfiles results in about 5MB being leaked, whilst rmfiles leaks about 30MB
> each time.  Below are stats from the Performance tab of Task Manager whilst
> running these scripts.  Handles don't seem to be leaked.

> It takes about 4 seconds to create the 1000 files, but about 70 seconds to
> remove those 1000 files.  Does this seem normal?

> TimeHandles, Available Physical Memory, Total Commit Charge
> 2:003870, 149.4M,  95.9MBefore running mkfiles
> 2:053719, 143.1M,  97.5MBefore running rmfiles
> 2:103679, 115.4M, 125.4MBefore running mkfiles
> 2:153673, 110.4M, 130.0MBefore running rmfiles
> 2:203661,  80.7M, 159.6MBefore running mkfiles
> 2:253689,  76.5M, 163.6MBefore running rmfiles
> 2:303686,  49.4M, 191.1MBefore running mkfiles
> 2:353718,  44.9M, 194.1MBefore running rmfiles
> ./rmfiles: line 5: 30312 Segmentation fault  (core dumped) rm -f
> files/file$a
> 2:373717,  16.3M, 222.6MAfter running rmfiles

> After this, I ran each of the commands again.  rmfiles failed with an error
> message simiar to the following.  This following error message was displayed
> when trying to open a new bash window after this failure:
>   0 [main] bash 28900 sync_with_child: child 37868(0x1A8) died before
> initialization with status code 0x80
>6476 [main] bash 28900 sync_with_child: *** child state waiting for
> longjmp
> bash: fork: Resource temporarily unavailable

> This appears to be the same problems as I was getting whilst doing a
> recursive make.
> NOTE: I don't get this problem on my desktop, only on the notebook, but then
> I was only getting the recursive make problem on the notebook.  If anyone
> out there is also having the recursive make or "fork: Permission denied"
> problems could you please try running these scripts and watching the stats
> in the Performance tab of Task Manager.  It would be good to know if this is
> just me (maybe corrupt Windows 2000), or a more common problem.

> Regards,

> Steven


> mkfiles
> ===
> #!/bin/bash
> mkdir files
> for ((a=0; a<1000; a++)) do
> echo foo > files/file$a
> done


> rmfiles
> ===
> #!/bin/bash
> for ((a=0; a<1000; a++)) do
> rm -f files/file$a
> done
> rmdir files

##


> Yep, I concur.  If windows has a lock on the file, rm just hangs.  I've
> seen it hang on directories when doing an 'rm -rf yada/*"

>> On Tue, 2003-01-21 at 06:50, Gael Mulat wrote:

>> Hi,
>>
>> This is a bug report about rm (package fileutils, version 4.1-1) on
W2K.
>>
>> Test case: take 2 cygwin shells.
>> shell 1:
>> mkdir /tmp/directory
>> vi /tmp/directory/file
>>
>> shell 2:
>> /bin/rm -rf /tmp/directory
>>
>> The shell2 doesn't manage to remove the directory and goes into an
>> infinite loop, taking 100% of the CPU.
>> All is then OK if we go out of vi in the shell1.
>>
>> Doing the same thing (deleting the directory) directly in Windows
>> produces an error message: "

Re: telnet

2003-01-21 Thread H.Merijn Brand
On Mon 20 Jan 2003 11:14, "Gerrit P. Haase" <[EMAIL PROTECTED]> wrote:
> H.Merijn schrieb:
> 
> > Given that cygwin is installed on a Win2k/sp3 target, is there an easy way to
> > enable telnet from another machine?
> 
> Use inetd, this is in the package inetutils.
> It is installed via cygrunsrv as service.

There might be a Cygwin bug here. If I do:

# cygrunsrv -I inetd -p C:/cygwin/usr/sbin/inetd.exe -o

I indeed see a new service, but the service is

Display name:   inetd
Description:
Path to executable: C:\Cygwin\bin\cygrunsrv.exe
Startup type:   Automatic

If I then use regedit to change it to

Display name:   inetd
Description:
Path to executable: C:\Cygwin\usr\sbin\inetd.exe
Startup type:   Automatic

I get an error that the service cannot find cygwin1.dll
When I copy it to /usr/sbin, all works (though I find multiple warnings in the
system application log)

C:\Cygwin\bin is in the system environment's PATH (not in the user's
environment, so all users get it)

Please keep me Cc'd, I'm not subscribed.

> Or use sshd, this is in the openssh package,
> a little more secure since all transfer is
> encrypted.

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: [EMAIL PROTECTED]
http:[EMAIL PROTECTED]/   [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




RE: telnet

2003-01-21 Thread Vince Hoffman
Umm if you read the inetutils-1.3.2.README in /usr/doc/Cygwin it recomends
installing as a service with the command  inetd --install-as-service rather
than using cygrunsrv. also are your mounts system wide rather than user ?

> -Original Message-
> From: H.Merijn Brand [mailto:[EMAIL PROTECTED]]
> Sent: 21 January 2003 13:48
> To: Gerrit P. Haase
> Cc: Cygwin Development
> Subject: Re: telnet
> 
> 
> On Mon 20 Jan 2003 11:14, "Gerrit P. Haase" 
> <[EMAIL PROTECTED]> wrote:
> > H.Merijn schrieb:
> > 
> > > Given that cygwin is installed on a Win2k/sp3 target, is 
> there an easy way to
> > > enable telnet from another machine?
> > 
> > Use inetd, this is in the package inetutils.
> > It is installed via cygrunsrv as service.
> 
> There might be a Cygwin bug here. If I do:
> 
> # cygrunsrv -I inetd -p C:/cygwin/usr/sbin/inetd.exe -o
> 
> I indeed see a new service, but the service is
> 
>   Display name:   inetd
>   Description:
>   Path to executable: C:\Cygwin\bin\cygrunsrv.exe
>   Startup type:   Automatic
> 
> If I then use regedit to change it to
> 
>   Display name:   inetd
>   Description:
>   Path to executable: C:\Cygwin\usr\sbin\inetd.exe
>   Startup type:   Automatic
> 
> I get an error that the service cannot find cygwin1.dll
> When I copy it to /usr/sbin, all works (though I find 
> multiple warnings in the
> system application log)
> 
> C:\Cygwin\bin is in the system environment's PATH (not in the user's
> environment, so all users get it)
> 
> Please keep me Cc'd, I'm not subscribed.
> 
> > Or use sshd, this is in the openssh package,
> > a little more secure since all transfer is
> > encrypted.
> 
> -- 
> H.Merijn BrandAmsterdam Perl Mongers 
(http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: [EMAIL PROTECTED]
http:[EMAIL PROTECTED]/   [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: telnet

2003-01-21 Thread H.Merijn Brand
On Tue 21 Jan 2003 14:57, Vince Hoffman <[EMAIL PROTECTED]> wrote:
> Umm if you read the inetutils-1.3.2.README in /usr/doc/Cygwin it recomends
> installing as a service with the command  inetd --install-as-service rather

Ahh, thanks. BTW that option is /not/ in inetd's man page

Service started successfully, but I cannot connect (yet). Will investigate.
No priority. No hurry.

> than using cygrunsrv. also are your mounts system wide rather than user ?

All are system wide binary mounts.

> > -Original Message-
> > From: H.Merijn Brand [mailto:[EMAIL PROTECTED]]
> > Sent: 21 January 2003 13:48
> > To: Gerrit P. Haase
> > Cc: Cygwin Development
> > Subject: Re: telnet
> > 
> > 
> > On Mon 20 Jan 2003 11:14, "Gerrit P. Haase" 
> > <[EMAIL PROTECTED]> wrote:
> > > H.Merijn schrieb:
> > > 
> > > > Given that cygwin is installed on a Win2k/sp3 target, is 
> > there an easy way to
> > > > enable telnet from another machine?
> > > 
> > > Use inetd, this is in the package inetutils.
> > > It is installed via cygrunsrv as service.
> > 
> > There might be a Cygwin bug here. If I do:
> > 
> > # cygrunsrv -I inetd -p C:/cygwin/usr/sbin/inetd.exe -o
> > 
> > I indeed see a new service, but the service is
> > 
> > Display name:   inetd
> > Description:
> > Path to executable: C:\Cygwin\bin\cygrunsrv.exe
> > Startup type:   Automatic
> > 
> > If I then use regedit to change it to
> > 
> > Display name:   inetd
> > Description:
> > Path to executable: C:\Cygwin\usr\sbin\inetd.exe
> > Startup type:   Automatic
> > 
> > I get an error that the service cannot find cygwin1.dll
> > When I copy it to /usr/sbin, all works (though I find 
> > multiple warnings in the
> > system application log)
> > 
> > C:\Cygwin\bin is in the system environment's PATH (not in the user's
> > environment, so all users get it)
> > 
> > Please keep me Cc'd, I'm not subscribed.
> > 
> > > Or use sshd, this is in the openssh package,
> > > a little more secure since all transfer is
> > > encrypted.
> > 
> > -- 
> > H.Merijn BrandAmsterdam Perl Mongers 
> (http://amsterdam.pm.org/)
> using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
>   WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: [EMAIL PROTECTED]
> http:[EMAIL PROTECTED]/   [EMAIL PROTECTED]
> send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
> 
> 
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: [EMAIL PROTECTED]
http:[EMAIL PROTECTED]/   [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Gael Mulat
Corinna Vinschen wrote:

On Tue, Jan 21, 2003 at 12:50:18PM +0100, Gael Mulat wrote:
>Hi,
> 
>This is a bug report about rm (package fileutils, version 4.1-1) on W2K.
> 
>Test case: take 2 cygwin shells.
> shell 1:
>mkdir /tmp/directory
>vi /tmp/directory/file
> 
> shell 2:
>/bin/rm -rf /tmp/directory
> 
>The shell2 doesn't manage to remove the directory and goes into an 
> infinite loop, taking 100% of the CPU.
>All is then OK if we go out of vi in the shell1.

Which version of Cygwin and Vim are you using?  I'm getting this:

  shell 1:
 mkdir /tmp/foo
 vi /tmp/foo/bar
 :w <= To create file `bar'


  Cygwin 1.3.17
  VIM 6.1-2
  Windows 2000 SP2 / SP3

  Just to be precise if I was not clear: do not exit of vi !
  
  In fact, I have noticed that the problem happens with vi, but it happens also with some 
other processes. I just don't know which ones.
  I found several times my Windows 2000 with the CPU at 100%, all the CPU was taken
by a rm in my scripts on cygwin. I didn't found the process that held the lock, but I noticed
that vi did the same...

Gael.

  shell 2:
 rm -rf /tmp/foo<= returns immediately, having foo removed.

Vim doesn't lock the file, so I wonder what you are discribing here.

Corinna

--
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




[ANNOUNCEMENT] Updated: cygwin-doc-1.3-2

2003-01-21 Thread Joshua Daniel Franklin
A new version of the cygwin-doc package is now available.
My apologies for the two releases so close together.
This release fixes a postinstall script issue with the recent
1.3-1 release. 

  *** INFORMATION ON UPDATING CYGWIN ***

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

In the US,
ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/
is a reliable high bandwidth connection.

In Germany,
ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/
is usually pretty good.

In the UK,
http://programming.ccp14.ac.uk/ftp-mirror/programming/cygwin/pub/cygwin/
is usually up-to-date within 48 hours.

If one of the above doesn't have the latest version of this package
then you can either wait for the site to be updated or find another
mirror.

The setup.exe program will figure out what needs to be updated on your
system and will install newer packages automatically.

If you have questions or comments, please send them to the Cygwin
mailing list at: [EMAIL PROTECTED] .  This includes ideas and comments
about the setup utility or Cygwin in general.

If you want to make a point or ask a question, the Cygwin mailing list
is the appropriate place.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you have trouble, please use the resources at

http://cygwin.com/ml/

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: apache 1.3.27 binary install problems

2003-01-21 Thread Jason Tishler
George,

On Tue, Jan 21, 2003 at 12:17:26AM -0500, George Rypysc III wrote:
> I've sucessfully used the build of apache (1.3.24) that came with
> Cygwin on Windows 2000 (SP-2) but I've struggled getting it to work on
> Windows XP (SP-1) using the same install files.  I've read previous
> posts about the rebasing issue and they have helped get me past that
> error, but I still get this error quite often:
> 
> $ C:\cygwin\usr\sbin\httpd.exe: *** recreate_mmaps_after_fork_failed


Try the latest snapshot.  There was a recent change to mmap that *may*
fix your problem.


> Any ideas?

If the above does not work, then strace httpd to get the exact Win32
error that corresponds to the above error.

If you can post a small test case that reproduces this error, then the
chances of the problem getting fixed is good.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Bleadperl 18519 on Cygwin snapshot 19.01.2003

2003-01-21 Thread Gerrit P. Haase
Hallo Cygwin,

Bleadperl patchlevel 18519 builds fine on the latest Cygwin snapshot,
threaded Perl not tested:

All tests successful, 48 tests and 316 subtests skipped.
Files=755, Tests=70537, 1961 wallclock secs (441.50 cusr + 286.64 csys = 728.14 CPU)


Summary of my perl5 (revision 5.0 version 9 subversion 0 patch 18519) configuration:
  Platform:
osname=cygwin, osvers=1.3.19s(0.7132), archname=cygwin-multi-64int
uname='cygwin_nt-4.0 iokaste 1.3.19s(0.7132) 20030119 22:03:54 i686 unknown 
unknown cygwin '
config_args='-de -Dusedevel -Dmksymlinks -Uversiononly -Dinstallusrbinperl 
-Duse64bitint -Doptimize=-g -O2 -Dusemultiplicity -Dman3ext=3pm'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useithreads=undef usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=y, bincompat5005=undef
  Compiler:
cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing',
optimize='-g -O2',
cppflags='-DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing'
ccversion='', gccversion='3.2 20020927 (prerelease)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
alignbytes=8, prototype=define
  Linker and Libraries:
ld='ld2', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /lib
libs=-lgdbm -ldb -lcrypt -lutil
perllibs=-lcrypt -lutil
libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
gnulibc_version=''
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags=' -L/usr/local/lib'


Characteristics of this binary (from libperl): 
  Compile-time options: DEBUGGING MULTIPLICITY USE_64_BIT_INT USE_LARGE_FILES 
PERL_IMPLICIT_CONTEXT
  Locally applied patches:
DEVEL18374
  Built under cygwin
  Compiled at Jan 20 2003 17:09:07
  %ENV:
CYGWIN="ntsec tty nowinsymlinks notitle"
  @INC:
lib
/usr/lib/perl5/5.9.0/cygwin-multi-64int
/usr/lib/perl5/5.9.0
/usr/lib/perl5/site_perl/5.9.0/cygwin-multi-64int
/usr/lib/perl5/site_perl/5.9.0
/usr/lib/perl5/site_perl
.



-- 
=^..^=


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread [EMAIL PROTECTED]
You may find the 'handle' utility from www.sysinternal.com a handy
(no pun intended :-) ) tool for determining which files are opened
by which processes.  This might help you track down what's locking 
files on you.

In terms of the 'vim' issue, it piqued my interest enough that I did
some investigation.  Running Cygwin 1.3.17-1, 1.3.18-1, and today's
snapshot all reproduced the hang for me.  So I took a simple step 
and ran strace on the 'rm' process.  It showed an error code of 5
(Access is denied.) for 'C:\tmp\foo\.bar.swp'.  Conclusion: the 
problem I see here has to do with 'vim' locking the recovery file.  
Adding '-n' to the flags for 'vim' removed the hang.  Corinna, any
chance you have your recovery file directories set to something 
that doesn't include '.'?  If that explains the difference in behavior
we're seeing, then I think we'll have solved one mystery and at least
have a workaround to the problem.

Larry

Original Message:
-
From: Gael Mulat [EMAIL PROTECTED]
Date: Tue, 21 Jan 2003 15:49:02 +0100
To: [EMAIL PROTECTED]
Subject: Re: Bug in rm -r with locked files


Corinna Vinschen wrote:
> On Tue, Jan 21, 2003 at 12:50:18PM +0100, Gael Mulat wrote:
> >Hi,
> > 
> >This is a bug report about rm (package fileutils, version 4.1-1) on
W2K.
> > 
> >Test case: take 2 cygwin shells.
> > shell 1:
> >mkdir /tmp/directory
> >vi /tmp/directory/file
> > 
> > shell 2:
> >/bin/rm -rf /tmp/directory
> > 
> >The shell2 doesn't manage to remove the directory and goes into an 
> > infinite loop, taking 100% of the CPU.
> >All is then OK if we go out of vi in the shell1.
> 
> Which version of Cygwin and Vim are you using?  I'm getting this:
> 
>   shell 1:
>  mkdir /tmp/foo
>  vi /tmp/foo/bar
>  :w <= To create file `bar'
> 

   Cygwin 1.3.17
   VIM 6.1-2
   Windows 2000 SP2 / SP3

   Just to be precise if I was not clear: do not exit of vi !
   
   In fact, I have noticed that the problem happens with vi, but it happens
also with some 
other processes. I just don't know which ones.
   I found several times my Windows 2000 with the CPU at 100%, all the CPU
was taken
by a rm in my scripts on cygwin. I didn't found the process that held the
lock, but I noticed
that vi did the same...

Gael.

>   shell 2:
>  rm -rf /tmp/foo<= returns immediately, having foo removed.
> 
> Vim doesn't lock the file, so I wonder what you are discribing here.
> 
> Corinna
> 
> -- 
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Developermailto:[EMAIL PROTECTED]
> Red Hat, Inc.




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



mail2web - Check your email from the web at
http://mail2web.com/ .



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Randall R Schulz
Larry,

Typo alert. It's .

Lots of good information and utilities there!

Randall Schulz


At 08:35 2003-01-21, [EMAIL PROTECTED] wrote:

You may find the 'handle' utility from www.sysinternal.com a handy (no pun 
intended :-) ) tool for determining which files are opened by which 
processes.  This might help you track down what's locking files on you.

In terms of the 'vim' issue, it piqued my interest enough that I did some 
investigation.  Running Cygwin 1.3.17-1, 1.3.18-1, and today's snapshot 
all reproduced the hang for me.  So I took a simple step and ran strace on 
the 'rm' process.  It showed an error code of 5 (Access is denied.) for 
'C:\tmp\foo\.bar.swp'.  Conclusion: the problem I see here has to do with 
'vim' locking the recovery file. Adding '-n' to the flags for 'vim' 
removed the hang.  Corinna, any chance you have your recovery file 
directories set to something that doesn't include '.'?  If that explains 
the difference in behavior we're seeing, then I think we'll have solved 
one mystery and at least have a workaround to the problem.

Larry


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




RE: cvs wont connect to remote

2003-01-21 Thread Patrick Nelson
Max Bowsher wrote:
-
cvs -t login ?
-
This reveals:

 $cvs -t login
 cvs login: notice: main loop with
CVSROOT=:pserver:pnelson@:
 
 (Logging in to pnelson@: no such repository
 cvs login: authorization failed: server  rejected access to

  for user pnelson

Does this mean anything?  I sure seems like it understands CVSROOT
correctly, but it seems like it's looking for 
 and not able to find it.  Could this be a
permission issue?  Heck I' don't know. 

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: telnet

2003-01-21 Thread Gerrit P. Haase
H.Merijn schrieb:

> On Mon 20 Jan 2003 11:14, "Gerrit P. Haase" <[EMAIL PROTECTED]> wrote:
>> H.Merijn schrieb:
>> 
>> > Given that cygwin is installed on a Win2k/sp3 target, is there an easy way to
>> > enable telnet from another machine?
>> 
>> Use inetd, this is in the package inetutils.
>> It is installed via cygrunsrv as service.

> There might be a Cygwin bug here. If I do:

> # cygrunsrv -I inetd -p C:/cygwin/usr/sbin/inetd.exe -o

> I indeed see a new service, but the service is

> Display name:   inetd
> Description:
> Path to executable: C:\Cygwin\bin\cygrunsrv.exe
> Startup type:   Automatic

I'm sorry, was my fault to give you some wrong advice. There are two
ways of running a service.  Usual cygrunsrv is used, then it is correct
that as executable is shown cygrunsrv, there are also some parameters
then which tell cygrunsrv which executable to start as service.

In case of inetd, there is a built in setup routine, called with
inetd --install-as-service
but first see the paste from the README below, please.


> If I then use regedit to change it to

> Display name:   inetd
> Description:
> Path to executable: C:\Cygwin\usr\sbin\inetd.exe
> Startup type:   Automatic

See above & below, please.


All is in the README :-)
/usr/doc/Cygwin/inetutils-x.x.x.README

...

The important features in brief


- Before starting any program, be aware that all neccessary configuration
  files in /etc have to be generated first! Call

iu-config

  once after you installed the inetutils the first time. That
  generates some files:

/etc/inetd.conf  -  inetd configuration. See man pages.
/etc/shells  -  Allowed login shells.
/etc/ftpusers-  List of users not allowed to login.
Set to "ftp" and "anonymous" by default.
/etc/ftpwelcome  -  Message printed to welcome a user at the
ftp server before login.
/etc/motd-  "message of today", printed by ftp after
successful login. Also printed by `login(1)'
after successful login.

- To start interactive telnet/rsh/rlogin sessions you need /bin/login.exe
  which is a separate package (part of the Cygwin standard net distro).

- inetd:

  Under W9X inetd can be started from a shell prompt or from the
  autostart folder.

  Under NT/W2K inetd must be started from service manager. It
  must not be started via SRVANY but it has two new options
  to install or remove it as service:

inetd --install-as-service
inetd --remove-as-service

  When you already have an older version of inetd installed,
  please remove the service before installing the new one.
  
  After you have installed inetd it will be started automatically
  on reboot. Manually starting and stopping is possible via

net start inetd
net stop inetd

  Current caveat: inetd is visible twice in the process list.
  This is currently needed to work correctly with the service
  manager. This should be solved in a future release.

  If you don't start inetd as service under LocalSystem but under
  another account, you have to care that that account has several
  user rights set in the user manager resp. local/domain security
  policy mmc snap in:
"Act as part of the operating system"
"Replace process level token"
"Increase quotas"
"Logon as a service"
  Note that administrators do not have all that user rights set
  by default!

  For all application started via NT/W2K service manager under 
  LocalSystem account, the following restrictions apply:

  - The environment variable CYGWIN must be either set in the system
environment to be active from start on or you can set CYGWIN thru
the registry:
Under the key HKLM\Software\Cygnus Solutions\Cygwin\Program Options
create a REG_SZ (String) named like the full DOS path to the application,
eg. "C:\usr\bin\inetd.exe" and with the value equal to the preferred
CYGWIN settings, eg "binmode tty ntsec".

  - The system environment variable PATH must contain the path
to the directory which contains the cygwin1.dll.

  - No user mount point is valid anymore! You have to install all
your mount points in the system mount table. This doesn't
change after you have logged in to a normal user account eg.
via telnet/rlogin. It's possible that we can use the user
mounts as soon as somebody contributes a patch to login and
ftp that allows loading a user hive into the registry after
authentication.

- ftpd:

  Under NT/W2K ftpd is now able to change user context with the
  help of NT security. This is useful mostly when using all features
  of the ntsec option of cygwin. The 'S-' and 'U-' fields in
  pw_gecos are taken into account as it's described in
  the 'login.README' file.

  Anonymous ftp is 

Re: Bug in rm -r with locked files

2003-01-21 Thread [EMAIL PROTECTED]
Thanks Randall!

Larry

Original Message:
-
From: Randall R Schulz [EMAIL PROTECTED]
Date: Tue, 21 Jan 2003 09:03:16 -0800
To: [EMAIL PROTECTED]
Subject: Re: Bug in rm -r with locked files


Larry,

Typo alert. It's .

Lots of good information and utilities there!

Randall Schulz


At 08:35 2003-01-21, [EMAIL PROTECTED] wrote:
>You may find the 'handle' utility from www.sysinternal.com a handy (no pun 
>intended :-) ) tool for determining which files are opened by which 
>processes.  This might help you track down what's locking files on you.
>
>In terms of the 'vim' issue, it piqued my interest enough that I did some 
>investigation.  Running Cygwin 1.3.17-1, 1.3.18-1, and today's snapshot 
>all reproduced the hang for me.  So I took a simple step and ran strace on 
>the 'rm' process.  It showed an error code of 5 (Access is denied.) for 
>'C:\tmp\foo\.bar.swp'.  Conclusion: the problem I see here has to do with 
>'vim' locking the recovery file. Adding '-n' to the flags for 'vim' 
>removed the hang.  Corinna, any chance you have your recovery file 
>directories set to something that doesn't include '.'?  If that explains 
>the difference in behavior we're seeing, then I think we'll have solved 
>one mystery and at least have a workaround to the problem.
>
>Larry


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



mail2web - Check your email from the web at
http://mail2web.com/ .



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




SIGINT to bash behaves differently in rxvt as compared to console

2003-01-21 Thread duncan . loveday
I find on a Windows NT4 (SP6) platform with the latest versions (downloaded
today) of cygwin1.dll, rxvt, bash etc that if I run a windows command
script, say a.cmd, which in turn runs some other process (e.g. a pause), if
I hit ^C then the behaviour is different in rxvt as compared to the cygwin
console.

In the console, the process being run by the command script is always
interrupted and then sometimes the rest of the command script continues to
execute but sometimes it says 'Terminate batch job (Y/N)' in which case if I
answer 'Y' the whole command script stops.

In rxvt, the ^C returns me to a prompt but the process being run is not
interrupted and continues in the background.

What I'd really like is for the ^C to consistently abort the whole command
script.

Has anyone come across this and/or is able to offer advice/solutions ?

Duncan

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




RE: grep -r *.java doesn't work as expected

2003-01-21 Thread Wai-Yip Tung \(wtung\)
Thank you for all suggestions. I got it works now. I'm new to bash and
the * expansoin by bash kind of surprise me.

Wai-yip

-Original Message-
From: Max Bowsher [mailto:[EMAIL PROTECTED]] 
Sent: Sunday, January 19, 2003 8:27 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: grep -r *.java doesn't work as expected


Wai-Yip Tung (wtung) wrote:
> I try to grep all .java file recursively
>
> [/q/Workflow/AppAdmin/src/com/cisco/wf/admin] $ grep -rn systemRsrc 
> *.java
>
> Only files in the current directory is searched.
> What's wrong?

Nothing. This is the expected behaviour.
The shell expands *.java, and then runs grep -rn file1.java file2.java
file3.java - none of which are directories, so grep can't recurse into
them.

Try:
find -name '*.java' | xargs grep -n systemRsrc

Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




1.3.18: rlogin crash

2003-01-21 Thread Rob Siklos
I noticed that if you launch rlogin from within an rlogin session, you get a
segmentation fault.

i.e.  rlogin to computer A, then while logged in to computer A, rlogin to
computer B (both running cygwin).

Running 1.3.18 under windows 2000 pro workstation.

Rob.



cygcheck.out
Description: Binary data
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


Re: cvs wont connect to remote

2003-01-21 Thread Max Bowsher
Patrick Nelson wrote:
> Max Bowsher wrote:
> -
> cvs -t login ?
> -
> This reveals:
>
>  $cvs -t login
>  cvs login: notice: main loop with
> CVSROOT=:pserver:pnelson@:
>
>  (Logging in to pnelson@  CVS password:
>  : no such repository
>  cvs login: authorization failed: server  rejected access
> to 
>   for user pnelson
>
> Does this mean anything?  I sure seems like it understands CVSROOT
> correctly, but it seems like it's looking for
>  and not able to find it.  Could this be a
> permission issue?  Heck I' don't know.

Neither do I, sorry. It looks like there is something strange with your
server, because I use Cygwin's cvs with many servers, and no problems.

Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




List archive search broken?

2003-01-21 Thread Brian Ford
Recently, everything I search for in this list's archives returns "No
matches found".  Surely the search engine is broken, as a search for
Cygwin in the cygwin mailing list archive turns up empty.  Thanks.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Shankar Unni
[EMAIL PROTECTED] wrote:

You may find the 'handle' utility from www.sysinternal.com a handy
(no pun intended :-) ) tool for determining which files are opened
by which processes.  

I don't think that was the primary issue.  The issue was that if a 
process is using a directory as its working directory (chdir()'ed into 
it), "rm -rf" goes into an infinite loop attempting to remove the 
directory (rather than print an error and move on).

Definitely a bug, and still a bug.

NOTE: The "-f" flag is crucial to reproducing this - without the "-f", 
rm gives an error and exits.

Here's how to reproduce

From one bash:

  mkdir /cygdrive/c/temp/foo   (some path)
  vi /cygdrive/c/temp/foo/x.txt
  :w

From a second bash:

  rm -rf /cygdrive/c/temp/foo
  (Hangs, with rm.exe taking ~100% of the CPU)

My package versions:
   fileutils   4.1-1
   cygwin  1.3.18-1
   bash2.05b-8
   vim 6.1-2

This doesn't happen, by the way, if you simply "cd" into the directory 
in the first bash, and do nothing else - in that situation, the "rm -rf" 
just emits a "Permission denied" error and exits.  Does bash do 
something special to the directories it chdir()s to?



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Bug in rm -r with locked files

2003-01-21 Thread Max Bowsher
Shankar Unni wrote:
> I don't think that was the primary issue.  The issue was that if a
> process is using a directory as its working directory (chdir()'ed into
> it), "rm -rf" goes into an infinite loop attempting to remove the
> directory (rather than print an error and move on).

No. The thing that rm -rf gets stuck on is vim .swp recovery file.

Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Randall R Schulz
Shankar,

At 11:05 2003-01-21, Shankar Unni wrote:

[EMAIL PROTECTED] wrote:

You may find the 'handle' utility from www.sysinternal.com a handy
(no pun intended :-) ) tool for determining which files are opened
by which processes.


I don't think that was the primary issue.  The issue was that if a process 
is using a directory as its working directory (chdir()'ed into it), "rm 
-rf" goes into an infinite loop attempting to remove the directory (rather 
than print an error and move on).

Definitely a bug, and still a bug.


That, in fact, is a presumption. The Cygwin principals are aware of this 
behavior and it is not new. It is a trade-off required to get POSIX-like 
behavior from the "unlink" system call as emulated by Cygwin.

Please review the discussions under the subject "Infinite Loop In "rm -fr" 
When Busy File Encountered" on April 6, 2002 and "REPOST: unlink semantics" 
from April 10, 2002.

I'm not an expert, but this has come up more than once (I initiated the 
April 6 round of discussions) and the upshot is that given the mismatch of 
API semantics between Windows and POSIX, this is the best that can be done.


Randall Schulz 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: SIGINT to bash behaves differently in rxvt as compared to console

2003-01-21 Thread Igor Pechtchanski
On Tue, 21 Jan 2003 [EMAIL PROTECTED] wrote:

> I find on a Windows NT4 (SP6) platform with the latest versions (downloaded
> today) of cygwin1.dll, rxvt, bash etc that if I run a windows command
> script, say a.cmd, which in turn runs some other process (e.g. a pause), if
> I hit ^C then the behaviour is different in rxvt as compared to the cygwin
> console.
>
> In the console, the process being run by the command script is always
> interrupted and then sometimes the rest of the command script continues to
> execute but sometimes it says 'Terminate batch job (Y/N)' in which case if I
> answer 'Y' the whole command script stops.
>
> In rxvt, the ^C returns me to a prompt but the process being run is not
> interrupted and continues in the background.
>
> What I'd really like is for the ^C to consistently abort the whole command
> script.
>
> Has anyone come across this and/or is able to offer advice/solutions ?
>
> Duncan

Duncan,

You need to add "tty" to your CYGWIN environment variable.  Read
 for details.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Brian . Kelly

Interesting - It's more important to "force" a square into a circle and
uphold a "standard"
than it is to deliver common sense "usability". MSWin is inherently
"UN-posix"  by nature,
and while I applaud trying to make a "silk (posix) purse" out of it, if it
means rendering the most
basic of utilities fundamentally unusable - then what is the point??? As I
posted earlier, I cannot
use rm -rf in a script and must resort to the native "del" cmd because rm
-rf hangs when it encounters
a locked file. Most of the files can be recovered with either attrib or
chmod xxx * and then the
script can continue. But in order for that to happen, there has to be an
ERROR MSG - something
I can get from the MS del cmd - even though I'd rather use rm. It's all
lost on me ...

Brian Kelly





"Randall R Schulz" <[EMAIL PROTECTED]>@cygwin.com on 01/21/2003 02:25:19 PM

Sent by:[EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc: (bcc: Brian Kelly/WTC1/Empire)

Subject:Re: Bug in rm -r with locked files


Shankar,

At 11:05 2003-01-21, Shankar Unni wrote:
>[EMAIL PROTECTED] wrote:
>>You may find the 'handle' utility from www.sysinternal.com a handy
>>(no pun intended :-) ) tool for determining which files are opened
>>by which processes.
>
>I don't think that was the primary issue.  The issue was that if a process
>is using a directory as its working directory (chdir()'ed into it), "rm
>-rf" goes into an infinite loop attempting to remove the directory (rather
>than print an error and move on).
>
>Definitely a bug, and still a bug.


That, in fact, is a presumption. The Cygwin principals are aware of this
behavior and it is not new. It is a trade-off required to get POSIX-like
behavior from the "unlink" system call as emulated by Cygwin.

Please review the discussions under the subject "Infinite Loop In "rm -fr"
When Busy File Encountered" on April 6, 2002 and "REPOST: unlink semantics"
from April 10, 2002.

I'm not an expert, but this has come up more than once (I initiated the
April 6 round of discussions) and the upshot is that given the mismatch of
API semantics between Windows and POSIX, this is the best that can be done.


Randall Schulz


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/







"Empire Health Choice Inc." made the following
 annotations on 01/21/2003 02:43:30 PM
--

[INFO] -- Access Manager:
Attention!  This electronic message contains information that may be legally 
confidential and/or privileged.  The information is intended solely for the individual 
or entity named above and access by anyone else is unauthorized.  If you are not the 
intended recipient, any disclosure, copying, distribution, or use of the contents of 
this information is prohibited and may be unlawful.  If you have received this 
electronic transmission in error, please reply immediately to the sender that you have 
received the message in error, and delete it. Release/Disclosure Statement




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




RE: Bug in rm -r with locked files

2003-01-21 Thread Shankar Unni
Max corrected me:

> No. The thing that rm -rf gets stuck on is vim .swp recovery file.

Ah. Sorry. Should have straced the thing before shooting off.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Home dir is "/"

2003-01-21 Thread Matthew Litwin
I've installed cygwin 1.3.18-1 on an XP system and
found it set my home dir as "/" instead of
/home/ like it normally does. Within
cygwin, I see that /home isn't even there. Even after
making my homedir, it still still puts me at root when
I launch a shell. I noted that I am not in /etc/passwd
as well. Should I be? If this is common problem, could
someone clue me in please?

Thanks,
Matt


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




RE: Bug in rm -r with locked files

2003-01-21 Thread Brian . Kelly

Well - even so   "my" problem remains   The scripts that I have are
written to work cross-platform,
and because I can't use  rm -rf  when telneting to a cygwin box with an
automated telnet/ssh script,
I have to do this nonsense:

if ($telnet_handle->{$hostlabel}->{OS} eq 'cygwin') {
($stdout,$stderr)=$telnet_handle->{_cmd_handle}->cmd("cmd /c del /s
$dir");
} else {
($stdout,$stderr)=$telnet_handle->{_cmd_handle}->cmd("cmd /c rm -r
$dir");
}

I'd rather not have to do this!!

Brian





"Shankar Unni" <[EMAIL PROTECTED]>@cygwin.com on 01/21/2003 02:47:54
PM

Sent by:[EMAIL PROTECTED]


To:"'Max Bowsher'" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
cc: (bcc: Brian Kelly/WTC1/Empire)

Subject:RE: Bug in rm -r with locked files


Max corrected me:

> No. The thing that rm -rf gets stuck on is vim .swp recovery file.

Ah. Sorry. Should have straced the thing before shooting off.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/







"Empire Health Choice Inc." made the following
 annotations on 01/21/2003 03:00:42 PM
--

[INFO] -- Access Manager:
Attention!  This electronic message contains information that may be legally 
confidential and/or privileged.  The information is intended solely for the individual 
or entity named above and access by anyone else is unauthorized.  If you are not the 
intended recipient, any disclosure, copying, distribution, or use of the contents of 
this information is prohibited and may be unlawful.  If you have received this 
electronic transmission in error, please reply immediately to the sender that you have 
received the message in error, and delete it. Release/Disclosure Statement




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Home dir is "/"

2003-01-21 Thread Abraham Backus
I've seen this as well, particularly on Win2K systems at work where you use
domain credentials to log into your machine.

Here's what I did to fix it (at the cygwin bash prompt):
$ mkpasswd -d -u myusername >> /etc/passwd

The mkpasswd command creates entries intended for /etc/passwd.  The "-d"
means to get information from a domain (the default domain).  The "-u" means
to use the information for "myusername" in the given domain.

I hope this makes sense and helps.

-Abe

- Original Message -
> I've installed cygwin 1.3.18-1 on an XP system and
> found it set my home dir as "/" instead of
> /home/ like it normally does. Within
> cygwin, I see that /home isn't even there. Even after
> making my homedir, it still still puts me at root when
> I launch a shell. I noted that I am not in /etc/passwd
> as well. Should I be? If this is common problem, could
> someone clue me in please?


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Consistent usage of "black on white" colors in terminal

2003-01-21 Thread Jim Kleckner
I promise that I have searched a whole bunch to
find the answer to this question.  I would be
happy just to get pointers in the right direction
to look.  It appears that some programs use
termcap and some use terminfo.

I have mostly gotten my bash colors to display
properly with black on white which I find
considerably more pleasing than white on black
(the default cmd.exe colors).  One does this by
just creating a shortcut to the cygwin.bat file,
right-click on properties on the shortcut, and
setting the colors and layout.

Programs like info, man, and cpan, however, do not
know about these switched default colors.  Trying
to eliminate color altogether also doesn't seem to
work.  Try setting TERM=ansi-mono, invoke a bash
subshell just for good luck, then type "man man"
and notice the continued use of color and
invisible white on white highlighted text.

Has anyone done this successfully and can you give
a pointer to the documentation to do this?

Many thanks - Jim



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Christopher Faylor
On Tue, Jan 21, 2003 at 11:25:19AM -0800, Randall R Schulz wrote:
>Shankar,
>
>At 11:05 2003-01-21, Shankar Unni wrote:
>>[EMAIL PROTECTED] wrote:
>>>You may find the 'handle' utility from www.sysinternal.com a handy
>>>(no pun intended :-) ) tool for determining which files are opened
>>>by which processes.
>>
>>I don't think that was the primary issue.  The issue was that if a process 
>>is using a directory as its working directory (chdir()'ed into it), "rm 
>>-rf" goes into an infinite loop attempting to remove the directory (rather 
>>than print an error and move on).
>>
>>Definitely a bug, and still a bug.
>
>
>That, in fact, is a presumption. The Cygwin principals are aware of this 
>behavior and it is not new. It is a trade-off required to get POSIX-like 
>behavior from the "unlink" system call as emulated by Cygwin.
>
>Please review the discussions under the subject "Infinite Loop In "rm -fr" 
>When Busy File Encountered" on April 6, 2002 and "REPOST: unlink semantics" 
>from April 10, 2002.
>
>I'm not an expert, but this has come up more than once (I initiated the 
>April 6 round of discussions) and the upshot is that given the mismatch of 
>API semantics between Windows and POSIX, this is the best that can be done.

Correct.  I knew that if I waited long enough Randall would probably reply.
:-)

It's not a completely intractable problem.  I think that someone (Chris
January?) provided a workaround at one point.  "cygserver" could also
provide a possible solution someday.

So, there's hope but I don't see this being resolved anytime really soon.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: List archive search broken?

2003-01-21 Thread Christopher Faylor
On Tue, Jan 21, 2003 at 01:05:03PM -0600, Brian Ford wrote:
>Recently, everything I search for in this list's archives returns "No
>matches found".  Surely the search engine is broken, as a search for
>Cygwin in the cygwin mailing list archive turns up empty.  Thanks.

The search engine is broken after the move to the new sourceware system.
The htdig volunteer is working on fixing it.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




RE: Bug in rm -r with locked files

2003-01-21 Thread [EMAIL PROTECTED]
Or read my analysis of the strace I did which I posted earlier in the 
thread. ;-)

No worries.

Larry

Original Message:
-
From: Shankar Unni [EMAIL PROTECTED]
Date: Tue, 21 Jan 2003 11:47:54 -0800
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: Bug in rm -r with locked files


Max corrected me:

> No. The thing that rm -rf gets stuck on is vim .swp recovery file.

Ah. Sorry. Should have straced the thing before shooting off.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



mail2web - Check your email from the web at
http://mail2web.com/ .



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




RE: Bug in rm -r with locked files

2003-01-21 Thread [EMAIL PROTECTED]
OK.  Have you investigated the use of tools I suggested to help you track 
down which utilities are causing you the problem(s)?  That would be a good
start to narrowing down your issue into something this list can discuss,
assuming that's where you'd like to take this.  

Of course, you're always welcome to review the current implementation of 
unlink() to see if you can suggest improvements.  It's worthwhile though 
to review past discussions on this issue to make sure you don't end up 
just rehashing old threads.  But new ideas are always welcome, particularly
if they solve some long-standing problems! ;-)

Larry 

Original Message:
-
From:  [EMAIL PROTECTED]
Date: Tue, 21 Jan 2003 14:59:23 -0500
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: Bug in rm -r with locked files



Well - even so   "my" problem remains   The scripts that I have are
written to work cross-platform,
and because I can't use  rm -rf  when telneting to a cygwin box with an
automated telnet/ssh script,
I have to do this nonsense:

if ($telnet_handle->{$hostlabel}->{OS} eq 'cygwin') {
($stdout,$stderr)=$telnet_handle->{_cmd_handle}->cmd("cmd /c del /s
$dir");
} else {
($stdout,$stderr)=$telnet_handle->{_cmd_handle}->cmd("cmd /c rm -r
$dir");
}

I'd rather not have to do this!!

Brian





"Shankar Unni" <[EMAIL PROTECTED]>@cygwin.com on 01/21/2003 02:47:54
PM

Sent by:[EMAIL PROTECTED]


To:"'Max Bowsher'" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
cc: (bcc: Brian Kelly/WTC1/Empire)

Subject:RE: Bug in rm -r with locked files


Max corrected me:

> No. The thing that rm -rf gets stuck on is vim .swp recovery file.

Ah. Sorry. Should have straced the thing before shooting off.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/







"Empire Health Choice Inc." made the following
 annotations on 01/21/2003 03:00:42 PM

--

[INFO] -- Access Manager:
Attention!  This electronic message contains information that may be
legally confidential and/or privileged.  The information is intended solely
for the individual or entity named above and access by anyone else is
unauthorized.  If you are not the intended recipient, any disclosure,
copying, distribution, or use of the contents of this information is
prohibited and may be unlawful.  If you have received this electronic
transmission in error, please reply immediately to the sender that you have
received the message in error, and delete it. Release/Disclosure Statement




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



mail2web - Check your email from the web at
http://mail2web.com/ .



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: CVS problem

2003-01-21 Thread Frédéric L. W. Meunier
Max Bowsher wrote:

> I'm sorry, I'm out of suggestions. Unless anyone else here
> knows what might cause cvs to hang like this:
>   41 4076680 [main] cvs 3092 wsock_event::prepare: 39189212 =
> wsock_event::prepare ()

And I can't help further, but I just compiled 1.1.15 with
--prefix=/usr --disable-dependency-tracking
make CFLAGS='-O2 -Wall' LDFLAGS=-s

I also commented:

#define TMPDIR_DFLT "/c/DOCUME~1/root/LOCALS~1/Temp"

and used #define TMPDIR_DFLT "/tmp"

Just to report I can't reproduce it with the new version.
Sounds like a problem with the Cygwin port ?

-- 
0@pervalidus.{net, {dyndns.}org}

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Shankar Unni
Christopher Faylor wrote:


It's not a completely intractable problem.  I think that someone (Chris
January?) provided a workaround at one point.  "cygserver" could also
provide a possible solution someday.


Right. I went back and re-read those archives. Interesting problem.

Now why was it important to do this "delayed remove" semantics? I.e. 
what (as alluded to by Robert Collins) would be broken if unlink simply 
returned EPERM or something like that if the file was busy? I didn't see 
any reference to that in the message threads.

(PS The archive search feature at http://cygwin.com/ml/cygwin/ seem to 
be broken - just about anything I type in the search box, including the 
word "cygwin", comes back with "no matches". So I apologize for not 
being able to do this research myself, and have to depend on those with 
long memories..)
--
Shankar.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Consistent usage of "black on white" colors in terminal

2003-01-21 Thread Thorsten Kampe
* Jim Kleckner (03-01-21 21:17 +0100)
> I have mostly gotten my bash colors to display properly with black on white
> which I find considerably more pleasing than white on black [...]
> 
> Programs like info, man, and cpan, however, do not know about these switched
> default colors.

I have switched to rxvt because of color problems with IPython and 
haven't turned back.

Have a look at the man page and my .Xdefaults[1]...

Thorsten

[1]
Rxvt*background: Black
Rxvt*backspacekey:   ^H
Rxvt*boldFont:   Fixedsys
Rxvt*colorBD:Red
!Rxvt*colorUL:   LightGrey
Rxvt*cursorColor:Cyan3
!Rxvt*cursorColor2:  Black
Rxvt*font:   Fixedsys
Rxvt*foreground: LightGrey
Rxvt*geometry:   87x38
Rxvt*iconName:   rxvt
Rxvt*inheritPixmap:  False
Rxvt*loginShell: False
Rxvt*meta8:  False
Rxvt*pointerColor:   LightGrey
Rxvt*reverseVideo:   False
Rxvt*saveLines:  64
Rxvt*scrollBar:  False
Rxvt*scrollBar_floating: True
Rxvt*scrollBar_right:True
Rxvt*scrollColor:LightGrey
Rxvt*scrollTtyKeypress:  False
Rxvt*scrollTtyOutput:False
Rxvt*title:  rxvt
Rxvt*troughColor:LightGrey
Rxvt*utmpInhibit:False
Rxvt*visualBell: False

! backgroundPixmap: file[;geom]
! borderColor:  color
! color0:   color
! color1:   color
! color2:   color
! color3:   color
! color4:   color
! color5:   color
! color6:   color
! color7:   color
! color8:   color
! color9:   color
! color10:  color
! color11:  color
! color12:  color
! color13:  color
! color14:  color
! color15:  color
! cutchars: string
! deletekey:string
! font1:fontname
! font2:fontname
! font3:fontname
! font4:fontname
! font5:fontname
! font6:fontname
! keysym.sym:   keysym
! mapAlert: boolean
! menu: name[;tag]
! modifier: modifier
! path: search path
! print-pipe:   string
! selectstyle:  string
! termName: string
-- 
 Content-Type: text/explicit; charset=ISO-8859-666 (Parental Advisory)
 Content-Transfer-Warning: message contains innuendos not suited for
 children under the age of 18


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Igor Pechtchanski
On Tue, 21 Jan 2003, Shankar Unni wrote:

> (PS The archive search feature at http://cygwin.com/ml/cygwin/ seem to
> be broken - just about anything I type in the search box, including the
> word "cygwin", comes back with "no matches". So I apologize for not
> being able to do this research myself, and have to depend on those with
> long memories..)
> --
> Shankar.

FYI, until the htdig archive search gets fixed, this also seems to work:

(IOW, search google for ["phrase" site:cygwin.com /ml/cygwin/]).
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Carlo Florendo
Hi Gael,

This is not a bug.  rm will *not* be able to remove the file as long as it
is locked.  This is the expected behaviour of rm when it is trying to remove
something which is locked by windows.  AFAIK, rm, in cases such as these,
echoes an error message which says, for example:

"rm: cannot remove `/tmp/directory/.file.swp': Permission denied"

and not go on infinite loop.  Why rm went on an infinite loop is another
matter, but the gurus here can help you if you give more details.

Regards,

Carlo

Carlo Florendo
Astra Philippines Inc.
email: [EMAIL PROTECTED]
URL: http://www.astra.ph



- Original Message -
From: "Gael Mulat" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 21, 2003 8:50 PM
Subject: Bug in rm -r with locked files


> Hi,
>
> This is a bug report about rm (package fileutils, version 4.1-1) on
W2K.
>
> Test case: take 2 cygwin shells.
> shell 1:
> mkdir /tmp/directory
> vi /tmp/directory/file
>
> shell 2:
> /bin/rm -rf /tmp/directory
>
> The shell2 doesn't manage to remove the directory and goes into an
> infinite loop, taking 100% of the CPU.
> All is then OK if we go out of vi in the shell1.
>
> Doing the same thing (deleting the directory) directly in Windows
> produces an error message: "cannot delete directory: Access is denied.
> The source file may be in use" and we can notice in the directory a file
> named .file.swp that is also visible under Cygwin with ls -la.
>
> The example I have just given uses vi, but it is the same with all
> processes that open the file, as W2K puts a lock on it.
>
> Gael Mulat
>
>
>
>
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
>
>


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Randall R Schulz
Shankar,

At 13:39 2003-01-21, Shankar Unni wrote:

Christopher Faylor wrote:


It's not a completely intractable problem.  I think that someone (Chris
January?) provided a workaround at one point.  "cygserver" could also
provide a possible solution someday.


Right. I went back and re-read those archives. Interesting problem.

Now why was it important to do this "delayed remove" semantics? I.e. what 
(as alluded to by Robert Collins) would be broken if unlink simply 
returned EPERM or something like that if the file was busy? I didn't see 
any reference to that in the message threads.

Well, EPERM would be a lie. EBUSY might be appropriate. The canonical text 
for that is "mount device busy", but it gets used for lots of things not 
related to mounting or unmounting.


(PS The archive search feature at http://cygwin.com/ml/cygwin/ seem to be 
broken - just about anything I type in the search box, including the word 
"cygwin", comes back with "no matches". So I apologize for not being able 
to do this research myself, and have to depend on those with long memories..)
--
Shankar.


Randall Schulz 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Bug in rm -r with locked files

2003-01-21 Thread Carlo Florendo
What cygwin, vi, and fileutils versions are you using?  In my case, I
(Bsimulated the test case but rm returned immediately with
(B
(Brm: cannot remove `/tmp/direx/a.swp': Permission denied
(Brm: cannot remove directory `/tmp/direx': Directory not empty
(B
(BI'm using vim 5.8.9, fileutils 4.1, and cygwin 1.3.15-1
(B
(BRegards,
(B
(BCarlo
(B
(BCarlo Florendo
(BAstra Philippines Inc.
(Bemail: [EMAIL PROTECTED]
(BURL: http://www.astra.ph
(B
(B
(B- Original Message -
(BFrom: David Means
(BTo: Gael Mulat
(BCc: [EMAIL PROTECTED]
(BSent: Tuesday, January 21, 2003 9:35 PM
(BSubject: Re: Bug in rm -r with locked files
(B
(B
(BYep, I concur.  If windows has a lock on the file, rm just hangs.  I've seen
(Bit hang on directories when doing an 'rm -rf yada/*"
(B
(BOn Tue, 2003-01-21 at 06:50, Gael Mulat wrote:
(BHi,
(B
(BThis is a bug report about rm (package fileutils, version 4.1-1) on W2K.
(B
(BTest case: take 2 cygwin shells.
(Bshell 1:
(Bmkdir /tmp/directory
(Bvi /tmp/directory/file
(B
(Bshell 2:
(B/bin/rm -rf /tmp/directory
(B
(BThe shell2 doesn't manage to remove the directory and goes into an
(Binfinite loop, taking 100% of the CPU.
(BAll is then OK if we go out of vi in the shell1.
(B
(BDoing the same thing (deleting the directory) directly in Windows
(Bproduces an error message: "cannot delete directory: Access is denied.
(BThe source file may be in use" and we can notice in the directory a file
(Bnamed .file.swp that is also visible under Cygwin with ls -la.
(B
(BThe example I have just given uses vi, but it is the same with all
(Bprocesses that open the file, as W2K puts a lock on it.
(B
(BGael Mulat
(B
(B
(B
(B
(B
(B
(B--
(BUnsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
(BBug reporting: http://cygwin.com/bugs.html
(BDocumentation: http://cygwin.com/docs.html
(BFAQ:   http://cygwin.com/faq/



sigaction siginfo_t & SIGSEGV

2003-01-21 Thread Rolf Campbell
I'm trying to write an application that can run some code when a certain
memory address is read or written.  
My first theory was to use mprotect to remove read/write permissions
from a section and then catch SIGSEGV, but siginfo_t doesn't seem to be
defined.
Is hooking a signal using the 'sa_sigaction' member of 'struct
sigaction' supported in CygWin?

I noticed that struct siginfo_t is declared in sys/signal.h, but inside
a couple of #ifdef:
#if defined(__rtems__)
#if defined(_POSIX_REALTIME_SIGNALS)

And it doesn't have the member that I need anyways (si_addr).

Does anyone know of any other ways of trapping reads/writes to/from
memory regions?


-Rolf Campbell
Software Designer
Tropic Networks

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Consistent usage of "black on white" colors in terminal

2003-01-21 Thread Jim Kleckner

Thorsten Kampe wrote:


* Jim Kleckner (03-01-21 21:17 +0100)


I have mostly gotten my bash colors to display properly with black on white
which I find considerably more pleasing than white on black [...]

Programs like info, man, and cpan, however, do not know about these switched
default colors.



I have switched to rxvt because of color problems with IPython and 
haven't turned back.

Have a look at the man page and my .Xdefaults[1]...


Thank you for the suggestion.  

I'm currently using the bare cmd.exe of Win2k and didn't want to have to 
start X11 just to get a terminal emulator.  It seems heavy - is this 
really necessary?  There is probably some magic thing to say in inputrc 
or terminfo to specify these colors but it has been 20 years since I 
waded into termcap/terminfo.  The manual mentions set_foreground and 
set_background but it requires a lot of digging to sort out.  I was 
hoping someone could point the way or say "there be dragons".

Jim



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Consistent usage of "black on white" colors in terminal

2003-01-21 Thread Lapo Luchini
Jim Kleckner wrote:


Have a look at the man page and my .Xdefaults[1]...


Thank you for the suggestion. 
I'm currently using the bare cmd.exe of Win2k and didn't want to have 
to start X11 just to get a terminal emulator.  It seems heavy - is 
this really necessary?  There is probably some magic thing to say in 
inputrc or terminfo to specify these colors but it has been 20 years 
since I waded into termcap/terminfo.  The manual mentions 
set_foreground and set_background but it requires a lot of digging to 
sort out.  I was hoping someone could point the way or say "there be 
dragons". 

Cygwin's rxvt port is quite cool, actually: can BOTH run with and 
without X11.

--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Consistent usage of "black on white" colors in terminal

2003-01-21 Thread Jim Kleckner
I see, very nice!  The synopsis with "for the X window system" led me 
astray and prevented me from looking at it.

Some mention of this would be very good to put in the documentation here:
  http://cygwin.com/cygwin-ug-net/setup-files.html

Just a mention that rxvt is a good alternative for the default windows 
terminal emulator and that it doesn't require X on Windows but works
with it if present.

Thanks!  Jim

Lapo Luchini wrote:

Jim Kleckner wrote:


Have a look at the man page and my .Xdefaults[1]...



Thank you for the suggestion. I'm currently using the bare cmd.exe of 
Win2k and didn't want to have to start X11 just to get a terminal 
emulator.  It seems heavy - is this really necessary?  There is 
probably some magic thing to say in inputrc or terminfo to specify 
these colors but it has been 20 years since I waded into 
termcap/terminfo.  The manual mentions set_foreground and 
set_background but it requires a lot of digging to sort out.  I was 
hoping someone could point the way or say "there be dragons". 


Cygwin's rxvt port is quite cool, actually: can BOTH run with and 
without X11.




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Larry Hall (RFK Partners, Inc)
Actually the tests I ran in response to this thread used the most current 
vim (6.1-2) and fileutils (4.1-1) with cygwin 1.3.17-1, 1.3.18-1, and the 
latest snapshot.  The versions you're using are out-of-date.  But I expect 
the main difference is in vim and some change there.  But perhaps you can 
help verify that by updating to cygwin 1.3.18-1 and rerunning the test.  
Then try again with the most current vim (6.1.-2).

Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX

At 07:45 PM 1/21/2003, Carlo Florendo wrote:
>What cygwin, vi, and fileutils versions are you using?  In my case, I
>simulated the test case but rm returned immediately with
>
>rm: cannot remove `/tmp/direx/a.swp': Permission denied
>rm: cannot remove directory `/tmp/direx': Directory not empty
>
>I'm using vim 5.8.9, fileutils 4.1, and cygwin 1.3.15-1
>
>Regards,
>
>Carlo
>
>Carlo Florendo
>Astra Philippines Inc.
>email: [EMAIL PROTECTED]
>URL: http://www.astra.ph
>
>
>- Original Message -
>From: David Means
>To: Gael Mulat
>Cc: [EMAIL PROTECTED]
>Sent: Tuesday, January 21, 2003 9:35 PM
>Subject: Re: Bug in rm -r with locked files
>
>
>Yep, I concur.  If windows has a lock on the file, rm just hangs.  I've seen
>it hang on directories when doing an 'rm -rf yada/*"
>
>On Tue, 2003-01-21 at 06:50, Gael Mulat wrote:
> Hi,
>
> This is a bug report about rm (package fileutils, version 4.1-1) on W2K.
>
> Test case: take 2 cygwin shells.
>shell 1:
> mkdir /tmp/directory
> vi /tmp/directory/file
>
>shell 2:
> /bin/rm -rf /tmp/directory
>
> The shell2 doesn't manage to remove the directory and goes into an
>infinite loop, taking 100% of the CPU.
> All is then OK if we go out of vi in the shell1.
>
> Doing the same thing (deleting the directory) directly in Windows
>produces an error message: "cannot delete directory: Access is denied.
>The source file may be in use" and we can notice in the directory a file
>named .file.swp that is also visible under Cygwin with ls -la.
>
> The example I have just given uses vi, but it is the same with all
>processes that open the file, as W2K puts a lock on it.
>
>Gael Mulat
>
>
>
>
>
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug in rm -r with locked files

2003-01-21 Thread Larry Hall (RFK Partners, Inc)
At 04:39 PM 1/21/2003, Shankar Unni wrote:
>Christopher Faylor wrote:
>
>>It's not a completely intractable problem.  I think that someone (Chris
>>January?) provided a workaround at one point.  "cygserver" could also
>>provide a possible solution someday.
>
>Right. I went back and re-read those archives. Interesting problem.
>
>Now why was it important to do this "delayed remove" semantics? I.e. what (as alluded 
>to by Robert Collins) would be broken if unlink simply returned EPERM or something 
>like that if the file was busy? I didn't see any reference to that in the message 
>threads.



Forgive me.  I didn't take the time to review the email archives for all
the threads on this but if I recall correctly, the current behavior is 
meant to combat the "my script/program deletes the file/directory then 
tries to recreate it - why isn't the file/directory deleted when unlink()
returns?" issue.



Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




strange behavior of cygpath

2003-01-21 Thread Kenji Yamashita
Hello,

I found that the behavior of cygpath was strange.

  kenji@ibm[88] cygcheck -c cygwin
  Cygwin Package Information
  Package Version
  cygwin  1.3.18-1
  
  Use -h to see help about each section
  kenji@ibm[89] cygpath -pw 'c:\'
  c;c:\

In cygwin-1.3.14-1, the behavior of cygpath is the following.

  kenji@ibm[93] tar jxf cygwin-1.3.14-1.tar.bz2 usr/bin/cygpath.exe
  kenji@ibm[94] usr/bin/cygpath.exe -pw 'c:\'
  c:\

Since cygwin-1.3.15-2, the behavior of cygpath has changed.

  kenji@ibm[95] tar jxf cygwin-1.3.15-2.tar.bz2 usr/bin/cygpath.exe
  kenji@ibm[96] usr/bin/cygpath.exe -pw 'c:\'
  c;c:\

In the announcement of cygwin-1.3.15-1,
  - Fix for "cygpath -w -l returning garbage".
(see http://cygwin.com/ml/cygwin/2002-09/msg00749.html )
(Christopher Faylor)

Is it related with? and the above is the specification of cygpath?

Regards,
Kenji Yamashita
[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: sigaction siginfo_t & SIGSEGV

2003-01-21 Thread Igor Pechtchanski
On Tue, 21 Jan 2003, Rolf Campbell wrote:

> I'm trying to write an application that can run some code when a certain
> memory address is read or written.
> My first theory was to use mprotect to remove read/write permissions
> from a section and then catch SIGSEGV, but siginfo_t doesn't seem to be
> defined.
> Is hooking a signal using the 'sa_sigaction' member of 'struct
> sigaction' supported in CygWin?
>
> I noticed that struct siginfo_t is declared in sys/signal.h, but inside
> a couple of #ifdef:
> #if defined(__rtems__)
> #if defined(_POSIX_REALTIME_SIGNALS)
>
> And it doesn't have the member that I need anyways (si_addr).
>
> Does anyone know of any other ways of trapping reads/writes to/from
> memory regions?
>
> -Rolf Campbell

No, sigaction is not supported on Cygwin.  It's on the TODO list.

There has been some discussion on how to set up your own signal handler on
this list last October.  See .
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: strange behavior of cygpath

2003-01-21 Thread Igor Pechtchanski
On Wed, 22 Jan 2003, Kenji Yamashita wrote:

> Hello,
>
> I found that the behavior of cygpath was strange.
>
>   kenji@ibm[88] cygcheck -c cygwin
>   Cygwin Package Information
>   Package Version
>   cygwin  1.3.18-1
>
>   Use -h to see help about each section
>   kenji@ibm[89] cygpath -pw 'c:\'
>   c;c:\
>
> In cygwin-1.3.14-1, the behavior of cygpath is the following.
>
>   kenji@ibm[93] tar jxf cygwin-1.3.14-1.tar.bz2 usr/bin/cygpath.exe
>   kenji@ibm[94] usr/bin/cygpath.exe -pw 'c:\'
>   c:\
>
> Since cygwin-1.3.15-2, the behavior of cygpath has changed.
>
>   kenji@ibm[95] tar jxf cygwin-1.3.15-2.tar.bz2 usr/bin/cygpath.exe
>   kenji@ibm[96] usr/bin/cygpath.exe -pw 'c:\'
>   c;c:\
>
> In the announcement of cygwin-1.3.15-1,
>   - Fix for "cygpath -w -l returning garbage".
> (see http://cygwin.com/ml/cygwin/2002-09/msg00749.html )
> (Christopher Faylor)
>
> Is it related with? and the above is the specification of cygpath?
>
> Regards,
> Kenji Yamashita

Kenji,

Let me make sure I understand what you're trying to do:
You're trying to translate a *Windows* path to a Windows path using
cygpath?

The '-p' flag tells cygpath that the path it's translating is in the form
of Unix $PATH (i.e., directories/files separated by *colons*).  Thus, it's
trying to translate the 2 component Unix path, 'c' followed by '\', into a
Windows %PATH%-style list (directories/files separated by semicolons).
This is correct behavior, and exactly what you're seeing in 1.3.15.  Any
other output is erroneous, and should be treated as such.  1.3.14 cygpath
apparently had a bug.  It's quite possible that the change you mentioned
had the additional benefit of fixing this bug.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: strange behavior of cygpath

2003-01-21 Thread Kenji Yamashita
Hello, Igor.

> On Tue, 21 Jan 2003 23:35:01 -0500 (EST)
> [EMAIL PROTECTED](Igor Pechtchanski)  said:

> Let me make sure I understand what you're trying to do:
> You're trying to translate a *Windows* path to a Windows path using
> cygpath?

I use cygpath in shell scripts. The arguments of shell scripts may
include both Windows-like path and UNIX-like path.

> The '-p' flag tells cygpath that the path it's translating is in the form
> of Unix $PATH (i.e., directories/files separated by *colons*).  
  (snip)
> This is correct behavior

I see. I forgot the meaning of '-p' option. I'll modify my scripts.
Thanks a lot.

Regards,
Kenji Yamashita
[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Announce: ioperm-0.2.1 for cygwin released

2003-01-21 Thread Marcel Telka
On Mon, Jan 20, 2003 at 09:59:11PM +0100, Marcel Telka wrote:
> On Mon, Jan 20, 2003 at 08:43:21PM -, Max Bowsher wrote:
> > Marcel Telka wrote:
> > > On Mon, Jan 20, 2003 at 05:57:42PM -, Max Bowsher wrote:
> > >> Marcel Telka wrote:
> > >>> On Mon, Jan 20, 2003 at 10:05:43AM -0500, Christopher Faylor wrote:
> >  On Mon, Jan 20, 2003 at 03:57:35PM +0100, Marcel Telka wrote:
> > 
> > 
> > > This software adds support for ioperm() function to Cygwin.
> > >>> 2. Windows DDK is required for the driver compilation.
> > >> 2. is likely a problem. Are you aware that w32api has some ddk
> > >> support now?
> > > Yes. But this is only at .h level. I need a linker (binutils)...
> > > I'm unaware about any way to compile & link a device driver using
> > > cygwin-only tools :-(
> > 
> > It is at very least possible to create a null.sys device driver that
> > implements a /dev/null-style bitbucket device, entirely with cygwin-only
> > tools.
> > 
> > There is sample code at:
> > http://reactos.wox.org/download/ddk-sample.tar.gz
> 
> This is really very important. I'll try it ASAP. Thank you!

This scenario works. Windows DDK is no longer required for building ioperm.

Thanks.

-- 
+---+
| Marcel Telka   e-mail:   [EMAIL PROTECTED]  |
|homepage: http://telka.sk/ |
|jabber:   [EMAIL PROTECTED] |
+---+

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Announce: ioperm-0.2.1 for cygwin released

2003-01-21 Thread Marcel Telka
On Mon, Jan 20, 2003 at 10:42:58AM -0800, Randall R Schulz wrote:
> Marcel et. al.,
> 
> At 09:52 2003-01-20, Marcel Telka wrote:
> >On Mon, Jan 20, 2003 at 10:05:43AM -0500, Christopher Faylor wrote:
> >> On Mon, Jan 20, 2003 at 03:57:35PM +0100, Marcel Telka wrote:
> >> >This software adds support for ioperm() function to Cygwin. This support
> >> >includes sys/io.h and sys/perm.h header files (not included in Cygwin by
> >> >default) together with development and runtime libraries.
> >> >
> >> >News in this release:
> >> > * Windows DDK is optional for compilation now
> >> > * --prefix=/usr parameter for ./configure script is not mandatory now
> >> >
> >> >Homepage: http://openwince.sourceforge.net/ioperm/
> >>
> >> Is there some reason you're not proposing this as a standard cygwin 
> >package?
> >
> >There are at least two reasons:
> >1. A device driver (ioperm.sys) is required for running ioperm with 
> >NT/2000/XP
> >2. Windows DDK is required for the driver compilation.
> >
> >If these drawbacks are acceptable for a standard cygwin package I could 
> >start
> >ioperm integration with mainstream cygwin net distribution.
> >
> >Any votes? :-)
> 
> 
> Regarding (1): Are we ("We" Kemo Sabe?) not crossing a boundary here?

Yes. But this crossing is optional.

> 
> Up to now we've been able to say that Cygwin does not install drivers or 
> other kernel-mode software and, the recent "/etc" business notwithstanding, 
> have been able to claim that BSODs, hangs and other nastiness cannot be 
> blamed on Cygwin.

My idea for ioperm is:
After package installation user must by hand install ioperm.sys driver.
So, no automatic driver installation in postinstall script.

> 
> Will this added capability be optional so those who don't need it and who 
> would prefer to avoid the potential instability of added driver software 
> (and I emphasize _potential_, not wanting to impugn anyone's programming 
> abilities) can avoid it altogether?

Yes. ioperm package installation will be optional (like any other cygwin
package is).

> 
> Am I being overly cautious? Paranoid?

That is ok :-).


Thank you.

-- 
+---+
| Marcel Telka   e-mail:   [EMAIL PROTECTED]  |
|homepage: http://telka.sk/ |
|jabber:   [EMAIL PROTECTED] |
+---+

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/