Re: startx hanging - startup problem located

2005-05-01 Thread martouf .
On 4/30/05, Alexander Gottwald [EMAIL PROTECTED] wrote:
 
 Just as expected. The forked xkbcomp does still hang forever.
 
  // any chance at all what I'm seeing has something to do with the
  EINTR || ECHILD possibility above?
 
 Even then the xserver should continue. But it appears to be waiting for
 the child which never exits properly.

ok then, any chance the pipe(), fork() and _exit() semantics are involved?
I wrote a small test program along the lines of what Popen() is doing,
and on SunOS 5.8 the output is::

 child :: myPID = 2998 :: 1 parent :: chPID = 2998
parent :: pd[0] = 3pd[1] = 4
2 3 4 5 6 7 8 9 10

Done..
child put 1442 bytes in fd 3

All done..

while on Linux 2.6.4-52-default and CYGWIN_NT-5.1 1.5.13(0.122/4/2)
the output is:

 child :: myPID = 6295 :: 1 parent :: chPID = 6295
parent :: pd[0] = 3pd[1] = 4
2 3 4 5 6 7 8 9 10

Done..
child put 0 bytes in fd 3

All done..

a description of the test program:

1. the parent makes a pipe() and fork()s. the child slowly counts to
10 and then uses dup2() to make the  'w'||pd[1] end of the pipe into
stdout and close()s the 'r'||pd[0] end of the pipe.
(SunOS 5.8 creates a bidirectional pipe, while the Linux doc indicates
it creates a unidirectional pipe with pd[0] ready to be read and pd[1]
ready to be written)

2. the child then execl()s a shell which makes more output and
_exit()s if the execl() is unsuccessful.

3. the parent sets SIGCHLD to SIG_IGN and close()s the 'w'||pd[1] end
of the pipe.

4. the parent blocks in waitpid() until the child completes, then
fstat()s the 'r'||pd[0] end of the pipe and reports the number of
bytes written into it.


winsup/cygwin ChangeLog fhandler_tty.cc

2005-05-01 Thread cgf
CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: [EMAIL PROTECTED]   2005-05-02 00:17:46

Modified files:
cygwin : ChangeLog fhandler_tty.cc 

Log message:
* fhandler_tty.cc (fhandler_tty_slave::read): Actually read input when 
vmin ==
vtime == 0.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.2865r2=1.2866
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_tty.cc.diff?cvsroot=uberbaumr1=1.137r2=1.138



winsup/cygwin ChangeLog-1995 ChangeLog-1996 Ch ...

2005-05-01 Thread cgf
CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: [EMAIL PROTECTED]   2005-05-02 03:50:11

Modified files:
cygwin : ChangeLog-1995 ChangeLog-1996 ChangeLog-1997 
 config.h.in cygheap.h dlfcn.cc 
 fhandler_disk_file.cc fhandler_process.cc 
 fhandler_socket.cc how-autoload-works.txt 
 lsearch.cc mmap.cc net.cc newsym ntdll.h 
 path.cc pinfo.cc poll.cc security.h select.cc 
 sigproc.cc strace.cc syscalls.cc syslog.cc 
 timer.cc uinfo.cc 
cygwin/include : pthread.h utmpx.h 
cygwin/include/cygwin: sysproto.h version.h 
cygwin/include/netinet: ip.h tcp.h 
cygwin/include/sys: copying.dj dirent.h lock.h stdio.h termios.h 
utime.h utmp.h 
cygwin/regex   : regerror.c 

Log message:
white space and minor comment cleanup.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog-1995.diff?cvsroot=uberbaumr1=1.2r2=1.3
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog-1996.diff?cvsroot=uberbaumr1=1.2r2=1.3
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog-1997.diff?cvsroot=uberbaumr1=1.2r2=1.3
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/config.h.in.diff?cvsroot=uberbaumr1=1.10r2=1.11
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/cygheap.h.diff?cvsroot=uberbaumr1=1.101r2=1.102
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/dlfcn.cc.diff?cvsroot=uberbaumr1=1.27r2=1.28
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=uberbaumr1=1.121r2=1.122
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_process.cc.diff?cvsroot=uberbaumr1=1.59r2=1.60
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_socket.cc.diff?cvsroot=uberbaumr1=1.161r2=1.162
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/how-autoload-works.txt.diff?cvsroot=uberbaumr1=1.3r2=1.4
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/lsearch.cc.diff?cvsroot=uberbaumr1=1.1r2=1.2
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/mmap.cc.diff?cvsroot=uberbaumr1=1.108r2=1.109
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/net.cc.diff?cvsroot=uberbaumr1=1.187r2=1.188
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/newsym.diff?cvsroot=uberbaumr1=1.5r2=1.6
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ntdll.h.diff?cvsroot=uberbaumr1=1.27r2=1.28
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/path.cc.diff?cvsroot=uberbaumr1=1.366r2=1.367
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/pinfo.cc.diff?cvsroot=uberbaumr1=1.171r2=1.172
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/poll.cc.diff?cvsroot=uberbaumr1=1.43r2=1.44
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/security.h.diff?cvsroot=uberbaumr1=1.63r2=1.64
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/select.cc.diff?cvsroot=uberbaumr1=1.113r2=1.114
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.cc.diff?cvsroot=uberbaumr1=1.224r2=1.225
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/strace.cc.diff?cvsroot=uberbaumr1=1.50r2=1.51
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/syscalls.cc.diff?cvsroot=uberbaumr1=1.375r2=1.376
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/syslog.cc.diff?cvsroot=uberbaumr1=1.33r2=1.34
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/timer.cc.diff?cvsroot=uberbaumr1=1.13r2=1.14
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/uinfo.cc.diff?cvsroot=uberbaumr1=1.136r2=1.137
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/include/pthread.h.diff?cvsroot=uberbaumr1=1.20r2=1.21
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/include/utmpx.h.diff?cvsroot=uberbaumr1=1.2r2=1.3
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/include/cygwin/sysproto.h.diff?cvsroot=uberbaumr1=1.1r2=1.2
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/include/cygwin/version.h.diff?cvsroot=uberbaumr1=1.189r2=1.190
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/include/netinet/ip.h.diff?cvsroot=uberbaumr1=1.4r2=1.5
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/include/netinet/tcp.h.diff?cvsroot=uberbaumr1=1.4r2=1.5
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/include/sys/copying.dj.diff?cvsroot=uberbaumr1=1.2r2=1.3
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/include/sys/dirent.h.diff?cvsroot=uberbaumr1=1.3r2=1.4
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/include/sys/lock.h.diff?cvsroot=uberbaumr1=1.2r2=1.3
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/include/sys/stdio.h.diff?cvsroot=uberbaumr1=1.2r2=1.3

Re: create installation using installed.db

2005-05-01 Thread Bas van Gompel
Op Thu, 28 Apr 2005 21:41:26 -0700 schreef Joshua Daniel Franklin
in [EMAIL PROTECTED]:
[...]

:  You particularly want 'mount -m':
:
:  -m, --mount-commands  write mount commands to replace user and
 ^^^
:  system mount points and cygdrive prefixes

Would not ``replicate'' express the intention better, above...

:  (from mount --help or
:  http://www.cygwin.com/cygwin-ug-net/using-utils.html#mount)

...and in the manpage?

[...]


L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   //   really is |   and false bits entirely.| mail for
  ) |  |  //a 72 by 4 +---+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe s.u(z)\1.as.| me. 4^re

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: one Cygwin file

2005-05-01 Thread Bas van Gompel
Op Fri, 29 Apr 2005 21:39:36 -0700 schreef Brian Dessent
in [EMAIL PROTECTED]:
[...]

:  cygwin web site.  The minimum you will need is everything in category
:  base.

You may also need any packages which those depend on.

Specifically this means you might need following packages which are not
in Base, according to my current local setup.inis:

_update-info-dir
bzip2
cygutils
groff
less
libbz2_1
libcharset1
libiconv
libiconv2
libintl
libintl1
libintl2
libintl3
libpcre
libpcre0
libpopt0
mktemp
texinfo

Maybe these could/should be added to Base?


L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   //   really is |   and false bits entirely.| mail for
  ) |  |  //a 72 by 4 +---+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe s.u(z)\1.as.| me. 4^re

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: SSH Path Bug

2005-05-01 Thread Corinna Vinschen
On Apr 30 14:53, Larry Hall wrote:
 At 09:59 PM 4/29/2005, you wrote:
 Dominic Chambers wrote:
 
  Running commands via SSH causes windows executables to be given path
  priority, so that they run ahead of identically named UNIX executables. I
  found this while trying to use the find command as part of an SSH call.
  For example, assuming you have an SSH server set up:
 
 I would think this has more to do with how you set your path than
 anything else.  [...]
 
 No, it's not that.  I was able to reproduce the described behavior even 
 when my system path has Cygwin's bin path before Windows.

Sounds more like a cockpit error.  I just tried it and I can't reproduce it.

 Running 'sshd'
 in debug mode showed the imported path that was not an exact match to any
 path I'd set anywhere.  So far, I haven't been able to get far enough 
 that I know why this happens.  But I can say that it happens for me
 and on more than 1 system and O/S.

It's not a bug, it's a feature :-)

What happens is a combination of what's done in cygrunsrv and sshd.

First, cygrunsrv adds the path to /bin to the environment before starting
a child process.  But it *appends* /bin to the path, so that the order
of path evaluation isn't changed.  So that can be taken out of the equation.

And what does sshd?  Sshd is equivalent to a login process, so on non-Cygwin
systems, it has to set the PATH variable to the default path value for the
system.  Usually something like PATH=/usr/bin:/bin.

On Windows it's a bit different because the PATH variable given to service
process (== the system environment) already contains paths, which are
required to run any process on Windows.  So the PATH variable must not be
replaced by default paths as on other systems.  Consequentially, Cygwin-sshd
does not change $PATH at all, but uses the default PATH as it is set in the
Windows system environment.  This is, IMHO, the equivalent to the default
PATH on other systems.

What you can do: 

- Prepend Cygwin paths to your system environment and restart(!) the PC.

- Set the default PATH only for your sshd service, for instance

cygrunsrv -I sshd -d CYGWIN sshd -p /usr/sbin/sshd -a -D \
  -e 
PATH=/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem

  assuming your Windows is installed in C:\Windows

- Even better: Always use absolute paths when running remote applications.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Perl-Win32-Porters Digest, Vol 14, Issue 1

2005-05-01 Thread Reini Urban
robert johnson schrieb:
hello
i have been using activestate's perl for win32 just fine, except that i cant do
ZModem transfers.  so I installed CYGWIN, and built a new perl in that
environment, with the hopes i could use available zmodem routines built for
*nix.
problem is, whereas Win32::SerialPort worked just fine in windows, the
corresponding Device::SerialPort is not working so well in Cygwin.  the make
complains that it cant find the following header files:
/usr/include/sys/termiox.h
/usr/include/sys/ttycom.h
/usr/include/sys/modem.h
and warns:
checking the checking serial control via ioctl... no
configure: WARNING: Without ioctl support, most serial control functions are
missing.
well, thats not going to work.  and Device::Modem has a dependency on
Device::SerialPort.
ive been all over the net, the boards, hassling the folks at cygwin and the
author of the Devices::SerialPort module (Kees).  Cygwin claims that the
headers in quesion have never been in their distribution, and so the problem is
in the application code.  SerialPort.pm's author just said hm, never tried it
on Cygwin.
so...  my task, should i accept it, is to port SerialPort.pm over to cygwin, by
resolving the problems with the three missing header files.  at least.  and
probably then some more.
which would be difficult if i knew what i was doing.  But since I Have No Idea,
it should be a breeze, right?
anyone got any suggestions?
refering to:
  http://sourceware.org/ml/cygwin/2005-04/msg01371.html
1) Why did you build perl from scratch where it would be just easier to 
install the cygwin package?
I didn't need those headers with the regular cygwin perl package and the 
regular cpan Device::SerialPort package.
You may need ioctl but it is easier to use the winapi directly than the 
POSIX quirks. Forget the headers. Look at the original source.

2) Why do ask cygwin questions here at the defunct activestate list?
The new libwin32 list is libwin32@perl.org
3) What's wrong with the Win32 package. Device::SerialPort is just a 
backport from the original Win32::SerialPort (based on 
Win32API::CommPort) over to POSIX. Using the direct package even on 
cygwin would be much better.

4) cpan Device::SerialPort
ioctl is missing, but this is not important imho.
checking serial control via ioctl... no
configure: WARNING: Without ioctl support, most serial control functions 
are missing
checking read/write of RTS signal... no
configure: WARNING: You will not be able to check or change the RTS line 
(direct flow control)
checking read/write of DTR signal... no
configure: WARNING: You will not be able to check or change the DTR line 
(modem hang up)

but only one test is failing:
t/test3...FAILED test 93
Failed 1/159 tests, 99.37% okay
  $err=$tock - $tick;
  is_bad ($err  50);# 93
  print 0 elapsed time=$err\n;
( I had no modem attached )
1/727 subtests failed, 99.86% okay.
Conclusion if this is not enough:
1) I would recommend to build Win32::SerialPort and Win32API::CommPort 
on cygwin (SerialPort-0.19), which will just require adding MakeMaker 
support. At least the cygwin folks will highly appreciate it, if not the 
cpan folks also.
2) Easier would be to add cygwin support to Device::SerialPort by using 
the original WINAPI calls for the few ioctl functions. And it will be 
more likely that the Device::SerialPort maintainer will accept it.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


Re: cygwin-1.5.16-1: FIFOs broken

2005-05-01 Thread Jerry D. Hedden
 However, that said, the above WJFFM.  In fact, it works more like
 linux in 1.5.16 than it does on 1.5.15, i.e., the cat command exits
 after printing YOUR TEXT HERE whereas it continues to block in
 1.5.15.
 I tried the 4/30 snapshot of cygwin1.dll.  It exhibited the behavior
 you mentioned with the 'cat' exiting after it reads text.  However,
 this is a bad thing.  It means that the FIFO is being set EOF after
 there is no more data.  I tried my client-server app with the
 snapshot cygwin1.dll, and it failed because of this.

 It seems to me that the behavior of FIFOs under 1.5.15 was correct,
 and that under both 1.5.16 and the snapshot, FIFOs are now broken.
 FWIW, I just tested your example under Solaris 8 and it works just
 like Christopher describes.
Okay.  I have seen the error of my ways.  I'm going to rewrite my app to 
use UPD instead.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


old wtf? [Was: cygwin-1.5.16-1: FIFOs broken]

2005-05-01 Thread Lapo Luchini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christopher Faylor wrote:
 However, that said, the above WJFFM.

It *is* in the oloca but not found in command line wtf, is this
expected? (e.g. a new version if waiting for some critical level of
new acronyms?)

  Lapo

- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iEYEARECAAYFAkJ02EAACgkQaJiCLMjyUvuFyQCg5bZwY8AshFyAv5AapFSdCy0j
+CUAoK8nrAUldbbhvbrfsuti/8fh0y4f
=/HKs
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: fenv.h missing!?

2005-05-01 Thread Corinna Vinschen
On May  1 03:46, Wesley W. Terpstra wrote:
 Why is the ISO C99 header fenv.h missing?
 Cygwin is the only gcc platform I've seen without it; even MinGW has it.
 This header provides fesetround which I have no idea how to reproduce.
 
 Am I using the wrong version of some cygwin package?

Since the floating point stuff in Cygwin is actually newlib's libm
implementation, this question better asked on the newlib list.  I've
CC'ed it.  Nevertheless, http://cygwin.com/acronyms/#PTC.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



installing XML::Xerces in Perl

2005-05-01 Thread marcos rebelo
I'm getting crazy 

I have the Xerces (I think) installed.

Now I have to set some variables but I dont know to what, can someone help me

XERCES_LIB
XERCES_INCLUDE
XERCESCROOT
XERCES_CONFIG

Thanks

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: create installation using installed.db

2005-05-01 Thread Christopher Faylor
On Sun, May 01, 2005 at 09:43:50AM +0200, Bas van Gompel wrote:
Op Thu, 28 Apr 2005 21:41:26 -0700 schreef Joshua Daniel Franklin
in [EMAIL PROTECTED]:
[...]

:  You particularly want 'mount -m':
:
:  -m, --mount-commands  write mount commands to replace user and
 ^^^
:  system mount points and cygdrive prefixes

Would not ``replicate'' express the intention better, above...

:  (from mount --help or
:  http://www.cygwin.com/cygwin-ug-net/using-utils.html#mount)

...and in the manpage?

Yes, it would.  I've made the appropriate changes.

Thanks.

cgf 

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Unison 2.10.2 fast update check broken?

2005-05-01 Thread Rolf Campbell
Marcus Picasso wrote:
Seems that Cygwin port of the unison file synchronizer does not do the
-fastcheck very well. Transcript follows:
...
Can somebody confirm / explain this behaviour? I have a large tree that I'm
synchronizing across two hard-disks, and got suspicious when re-running
synchronization takes longer than expected. The above transcript 
functions as
expected using linux or native Win32 unison builds.

Regards,
-Marcus.

I have noticed a change in how -fastcheck which seems to be caused by my 
upgrade from cygwin 1.5.14 - 1.5.16.  I tried doing a unison sync 
between a maching running 1.5.14 and a machine running 1.5.16 when I 
noticed the 1.5.16 machine spent a lot of time grinding the disk.  So, I 
upgraded the 1.5.14 machine to 1.5.16 and it too went from a 10 second 
scan time to a half hour of heavy disk access.

Cygwin Configuration Diagnostics
Current System Time: Sun May 01 13:04:20 2005

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
C:\Program

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
0(root)  544(Administrators)  545(Users)
10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
0(root)  544(Administrators)  545(Users)
10513(Domain Users)

SysDir: C:\WINNT\system32
WinDir: C:\WINNT

HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `rcampbell'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PCRCAMPBELL3'
COMSPEC = `C:\WINNT\system32\cmd.exe'
COSMIC = `t'
CVS_RSH = `/bin/ssh'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\rcampbell'
HOSTNAME = `pcrcampbell3'
INFOPATH = 
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LOGONSERVER = `\\PCRCAMPBELL3'
MANPATH = 
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/home/rcampbell'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0806'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp'
TERM = `xterm'
TMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp'
TROPIC_UNIQUE_ID = `156'
USERDNSDOMAIN = `tropicnetworks.com'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINNT'
WINDOWID = `168188080'
_ = `/usr/bin/cygcheck'
POSIXLY_CORRECT = `1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `C:'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/d
  (default) = `d:'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/e
  (default) = `E:'
  flags = 0x001a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/f
  (default) = `f:'
  flags = 0x010a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS 19069Mb  84% CP CS UN PA FC 
d:  cd N/AN/A
f:  netN/AN/A

C:\cygwin  /  system  binmode
C: /c system  binmode
d: /d system  binmode
E: /e system  binmode,exec
f: /f system  binmode
C:\cygwin/bin  /usr/bin   system  binmode
C:\cygwin/lib  /usr/lib   system  binmode
.  /cygdrive  system  binmode,cygdrive

Found: 

Re: SSH Path Bug

2005-05-01 Thread Larry Hall
At 05:55 AM 5/1/2005, you wrote:
On Apr 30 14:53, Larry Hall wrote:
 At 09:59 PM 4/29/2005, you wrote:
 Dominic Chambers wrote:
 
  Running commands via SSH causes windows executables to be given path
  priority, so that they run ahead of identically named UNIX executables. I
  found this while trying to use the find command as part of an SSH call.
  For example, assuming you have an SSH server set up:
 
 I would think this has more to do with how you set your path than
 anything else.  [...]
 
 No, it's not that.  I was able to reproduce the described behavior even 
 when my system path has Cygwin's bin path before Windows.

Sounds more like a cockpit error.  I just tried it and I can't reproduce it.


Yeah, it looks like I must have been caught by Windows' insufferable need
to be rebooted after almost any change.  Why am I surprised? ;-)


 Running 'sshd'
 in debug mode showed the imported path that was not an exact match to any
 path I'd set anywhere.  So far, I haven't been able to get far enough 
 that I know why this happens.  But I can say that it happens for me
 and on more than 1 system and O/S.

I should have said Windows O/S here.  Specifically, I tried it on W2K and
XP.

It's not a bug, it's a feature :-)

What happens is a combination of what's done in cygrunsrv and sshd.

First, cygrunsrv adds the path to /bin to the environment before starting
a child process.  But it *appends* /bin to the path, so that the order
of path evaluation isn't changed.  So that can be taken out of the equation.

And what does sshd?  Sshd is equivalent to a login process, so on non-Cygwin
systems, it has to set the PATH variable to the default path value for the
system.  Usually something like PATH=/usr/bin:/bin.

On Windows it's a bit different because the PATH variable given to service
process (== the system environment) already contains paths, which are
required to run any process on Windows.  So the PATH variable must not be
replaced by default paths as on other systems.  Consequentially, Cygwin-sshd
does not change $PATH at all, but uses the default PATH as it is set in the
Windows system environment.  This is, IMHO, the equivalent to the default
PATH on other systems.

What you can do: 

- Prepend Cygwin paths to your system environment and restart(!) the PC.


As I said above, UGH! ;-)


- Set the default PATH only for your sshd service, for instance

cygrunsrv -I sshd -d CYGWIN sshd -p /usr/sbin/sshd -a -D \
  -e 
 PATH=/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem

  assuming your Windows is installed in C:\Windows


Yeah, this is probably the nicest from the user point of view.


- Even better: Always use absolute paths when running remote applications.


Yep.  That certainly works and is the most portable. :-)

Thanks.


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


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: find command in cygwin

2005-05-01 Thread Shankar Unni
Igor Pechtchanski wrote:
This message is produced by GNU find.  find -name a . will result in such.
Oops. (Crawl under rock..)
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


read bug in Cygwin 1.5.16?

2005-05-01 Thread Peter Farley
Hi all,

I tried to forward this message to the main cygwin
list yesterday, but had a little trouble getting it
there, probably because I mentioned xterm in the
subject.  I'm trying again in case this is NOT an X
problem but a base cygwin problem.

I have attached the test program xtermbug.c instead 
of pasting it inline.  I hope that is OK for this
list.

If there is anything I can do to help debug the reason
I am seeing this problem, please just tell me what to
do.

BTW, thanks to all the developers for an awesome
product.

Regards,

Peter Farley

--- Peter Farley [EMAIL PROTECTED] wrote:

 Hi all,
 
 The following program demonstrates what looks to me
 like a bug in the read function in an xterm (as
 opposed to a Cygwin console window).  To run the
 test, compile with:
 
 gcc -g -o xtermbug.exe xtermbug.c
 
 When you run it in a console window, you can enter
 normal keyboard characters, then a return to see
 cmdline=what you typed.  Press the Esc key to
 exit the program.
 
 When run in an xterm window, the first keypress
 causes this behavior:
 
 1. Select returns with rc = 0 and readset set to
 indicate that a key was received
 2. read returns with kblen = 1 and kbbuf[0] = '\0'
 3. (1) and (2) repeat forever.
 
 I put in a maxdbg parameter and terminate the
 program after 5 occurrences of this loop.
 
 This problem was first detected trying to run a copy
 of the hercules IBM mainframe emulator in a Cygwin
 xterm window.  The code below is extracted and
 minimalized as much as possible from the hercules
 keyboard input routine.
 
 Peter Farley


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com /*---*/
/* This is a test program to show a cygwin xterm bug, possibly   */
/* in the read function. */
/*---*/

/*---*/
/* Definitions for keyboard input sequences  */
/*---*/
#define KBD_DELETE  \x1B[3~

#include stdio.h
#include unistd.h
#include sys/time.h
#include string.h
#include errno.h
#include termios.h

#define MSG_SIZE80  /* Size of one message   */
#define CMD_SIZE 32767  /* Length of command line*/

#define BYTE unsigned char

int ttyreset = 0;
struct  termios kbattr; /* Terminal I/O structure*/

/*---*/
/* xterm display subroutine  */
/*---*/

void xterm_display (void)
{
int rc; /* Return code   */
int i;  /* Array subscripts  */
charcmdline[CMD_SIZE+1];/* Command line buffer   */
int cmdoff = 0; /* Cursor position in cmdline*/
int cmdlen = 0; /* Number of bytes in cmdline*/
//BYTEc;  /* Character work area   */
FILE   *confp;  /* Console file pointer  */
size_t  kbbufsize = CMD_SIZE;   /* Size of keyboard buffer   */
char   *kbbuf = NULL;   /* Keyboard input buffer */
int kblen;  /* Number of chars in kbbuf  */
int keybfd; /* Keyboard file descriptor  */
int maxfd;  /* Highest file descriptor   */
fd_set  readset;/* Select file descriptors   */
struct  timeval tv; /* Select timeout structure  */
int maxdbg = 0;

/* Set up the input file descriptors */
confp = stdout;
keybfd = STDIN_FILENO;

fprintf(confp, start kbbuf=%8.8X,kbbuf=%8.8X\n, 
kbbuf, kbbuf);

/* Obtain storage for the keyboard buffer */
if (!(kbbuf = (char *)malloc (kbbufsize)))
{
fprintf(stderr, HHCPN002S Cannot obtain keyboard buffer: %s\n,
strerror(errno));
return;
}

fprintf(confp, start kbbuf=%8.8X,kbbuf=%8.8X,*kbbuf=%8.8X\n, 
kbbuf, kbbuf, *kbbuf);

/* Set screen output stream to fully buffered */
setvbuf (confp, NULL, _IOFBF, 0);

/* Put the terminal into cbreak mode */
tcgetattr (keybfd, kbattr);
kbattr.c_lflag = ~(ECHO | ICANON);
kbattr.c_cc[VMIN] = 0;
kbattr.c_cc[VTIME] = 0;
tcsetattr (keybfd, TCSANOW, kbattr);
ttyreset = 1;

fprintf(confp, Starting while(1) loop.\n);
fflush(confp);

/* Process messages and commands */
while (1)
{
/* Set the file descriptors for select */
FD_ZERO (readset);
FD_SET (keybfd, readset);

Re: read bug in Cygwin 1.5.16?

2005-05-01 Thread Christopher Faylor
On Sun, May 01, 2005 at 04:56:13PM -0700, Peter Farley wrote:
Hi all,

I tried to forward this message to the main cygwin
list yesterday, but had a little trouble getting it
there, probably because I mentioned xterm in the
subject.  I'm trying again in case this is NOT an X
problem but a base cygwin problem.

I have attached the test program xtermbug.c instead 
of pasting it inline.  I hope that is OK for this
list.

Thanks for the test program.

There was a problem with setting VMIN == VTIME == 0 on ttys/ptys.  I've
just checked in a fix.  It will be in today's snapshot, when it shows
up: http://cygwin.com/snapshots/ .

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: read bug in Cygwin 1.5.16?

2005-05-01 Thread Brian Dessent

Christopher Faylor wrote:

 There was a problem with setting VMIN == VTIME == 0 on ttys/ptys.  I've
 just checked in a fix.  It will be in today's snapshot, when it shows
 up: http://cygwin.com/snapshots/ .

Peter Farley wrote:

 kbattr.c_cc[VMIN] = 0;
 kbattr.c_cc[VTIME] = 0;

If you're always using select() to read, you could set VMIN = 1 as a
workaround if you need to support versions of Cygwin prior to the above
fix.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Can cygwin create a ramdisk which is a cygwin filesystem?

2005-05-01 Thread William Deegan
Greetings,

As I understand it cygwin access to NTFS is slow for various reasons.
For my purposes a filesystem on ramdisk managed by cygwin would work just fine.
Is that possible?

-Bill

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Bash Process Substitution

2005-05-01 Thread Christopher Faylor
On Thu, Apr 14, 2005 at 03:58:13AM -0400, Lev S Bishop wrote:
Process substitution in bash is not working for me currently. I'm pretty 
certain it worked at some point in the past (maybe about 6 months ago). 

For example:
$ cat ( echo hello)

hangs, ignoring ^C, kill -9, and requiring kill -f on the cat 
process.

This is working (for me at least) in cygwin 1.5.16.  However, since it uses
fifos, it is possible that it may still be flaky.

I have more work to do in fifos when I get a tuit.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



RE: Re: Help !!! - Problem running Cygwin in Remote Desktop session with non-admin privileges

2005-05-01 Thread Moghe, Jayant
Thank you Andrew.

I would try that out and let you know.

Best regards,

Jayant

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Andrew DeFaria
Sent: Friday, April 29, 2005 9:17 PM
To: cygwin@cygwin.com
Subject: Re: Help !!! - Problem running Cygwin in Remote Desktop session
with non-admin privileges

Moghe, Jayant wrote:

 Corinna:

 Thank you for your response. Sorry for the inconvenience.

 May I know, normally, how long does it take to respond to a query?

 Since this is for the first time I have posted my query, I am not 
 aware of quite a few processes that need to be followed. Am I missing 
 something?

I've found in the past that sometimes that error indicates a memory 
problem of some sort. If your W2K server is indeed a server then perhaps

it's running long running service processes that have consumed most of 
the memory (memory leaks). You might try rebooting it though that may be

inconvenient or you could try shutting down some non essential services 
or restarting services that seem to have hogged memory.
-- 
A closed mouth gathers no feet.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



RE: Help !!! - Problem running Cygwin in Remote Desktop session with non-admin privileges

2005-05-01 Thread Moghe, Jayant
Thank you Corinna!!!

I would try it out and get back to you.

Best regards,

Jayant

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Corinna Vinschen
Sent: Friday, April 29, 2005 7:15 PM
To: cygwin@cygwin.com
Subject: Re: Help !!! - Problem running Cygwin in Remote Desktop session
with non-admin privileges

On Apr 29 15:36, Corinna Vinschen wrote:
 On Apr 29 18:50, Moghe, Jayant wrote:
  I there any way where I can avail paid support?
 
 Sure, but isn't it easier to report your problem somewhat more
detailed
 and see if you get a free (as in free beer) reply within a couple of
 days?

For the records:  I tried to reproduce your problem with a 2K3 Server
machine running terminal services.  Logging in via remote desktop with
a non-admin acocunt, I was able to use bash and any other tool just
fine.

This is with Cygwin 1.5.16.  Did you upgrade?  Perhaps that helps.
Other than that, I found that bash can be somewhat obdurate if the
/tmp directory is not writable for the user.  I suggest to change
the permissions with

 chmod 1777 /tmp


HTH,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/