Cygwin and Interix interoperability?

[mwoehlke]

Hi, list,

I saw a few comments roughly on this topic when I searched the archives,
but nothing 100% definite, so I thought I'd ask... Are there any plans
of making Cygwin more compatible with Interix (and especially the
SFU/SUA NFS clients)?

Specifically, I would be interested in two things:
1) Compatibility with Interix symlinks (especially on NFS where they are
*real* symlinks!)
2) Usage of real NFS permissions; particularly since Cygwin creates
everything with a+x on NFS volumes ATM (and can't correctly affect the
permissions at all).

I'm not asking for any time frame, just... has it been given any thought?

(I don't *think* this is a double-post, but apologies if it is; this is
about my third time trying to send... still trying to figure out the
headers in Thunderbird! :-))

TIA

--
Matthew
"Ethics? We've heard of it" -- Microsoft





--
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 and Interix interoperability?

[mwoehlke]

Christopher Faylor wrote:

On Thu, Apr 20, 2006 at 11:59:49AM -0500, mwoehlke wrote:

Are there any plans of making Cygwin more compatible with Interix

>> (and especially the (and especially the SFU/SUA NFS clients)?


No, there are no plans.  I can't speak for Corinna, but, personally, I
have no interest in this.  That does not preclude someone offering patches
but I think that's pretty unlikely, too.


IOW, "DIY"?

When you say "pretty unlikely", do you mean 'that anyone else would 
provide patches', or that such patches would be used?


--
Matthew
"Ethics? We've heard of it" -- Microsoft

--
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: how to get my app to find a dynamic library

[mwoehlke]

Thomas Preisler wrote:
My main app 'main.c' is in one directory and I have a dynamic library 
'cygmylib.dll' in a subdiretory 'tmp'. I can compile and link my main 
app fine but having trouble running it. It complaints about not being 
able to find the dynamic library. I have tried just about everything 
from -L, -Wl,-rpath using relative or absolute paths on the compile line 
to setting LD_LIBRARY_PATH and LD_RUN_PATH at run time, but to no avail.


Seeing as how this is Cygwin, and not Interix or A Real *nix, did you 
try setting PATH? (PATH="./tmp:$PATH" ./app # this is one line)


--
Matthew
"Ethics? We've heard of it" -- Microsoft

--
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 and Interix interoperability?

[mwoehlke]

Corinna Vinschen wrote:

We're already having two different symlink types, one of them U/Win
compatible.  I'm, too, not really interested in adding another one(*),
especially when there's no documentation and, TTBOMK, no Win32 API.


True; it might require linking against Interix (yuck), which is only
feasible with SUA 5.2. There is nevertheless a very real chance that I
will look into this, as this would be really useful for me, as most of
the files I work with exist on NFS.

Even better, believe it or not, the Windows subsystem actually
understands them! Which actually means that they are currently invisible
to Cygwin. If Cygwin could make these, then they would be understood
*transparently* by the rest of Windows (on NFS volumes, anyway)!


Same for the SFU NFS permission handling which doesn't seem to work
transparently using the Win32 security API.


I would assume that there is a different interface for NFS permissions,
as they show up in Explorer on an 'NFS Attributes' tab (which, however,
means that at some level they are accessible to normal Windows
applications; even SFU ones where mixed-mode is not supported). It a
different way, IMO this is /more/ worth looking into because one could
argue that you're "reducing" complexity rather than adding it.


(*) We will probably start using the new symlink API of Windows Longhorn/
Vista at one point when the first non-beta release of Vista is
available.  This is hopefully compatible with existing file systems
like SFU NFS...[snip]


I would HOPE it's compatible with NFS!

Anyway, it seems obvious that whatever I want to happen here, I have to
do myself. Hopefully 'PTC' will still apply. :-)

(Hopefully this isn't a double-post, either; I seem to have munged the 
'To:' last time.)


--
Matthew
"Ethics? We've heard of it" -- Microsoft


--
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 and Interix interoperability?

[mwoehlke]

Corinna Vinschen wrote:

On Apr 20 16:42, mwoehlke wrote:

True; it might require linking against Interix (yuck), which is only
feasible with SUA 5.2. There is nevertheless a very real chance that I


I don't think that's feasible for Cygwin, though.  Interix is not just a
Win32 DLL as Cygwin, it's an entirely different subsystem.  I don't even
want to know the implications when trying to link against the Interix
subsystem.


I wouldn't expect it to be *easy*... however, SUA supposedly allows
"mixed-mode" applications, meaning Interix code is allowed to call into
the Windows subsystem. So the question is; can it work the other way?


Even better, believe it or not, the Windows subsystem actually
understands them! Which actually means that they are currently invisible
to Cygwin. If Cygwin could make these, then they would be understood
*transparently* by the rest of Windows (on NFS volumes, anyway)!


They are not understood by Windows, and that's documented.  They are
just translated into the file type they are pointing to by the NFS
client and then presented as file or directory to Windows clients.


Sorry for the confusion; that's what I meant. The point is, you can
request an open on a symlink (including symlinks in the *middle* of a
path) and it will transparently "work". That isn't the case for .lnk
files (and unfortunately, neither way works on non-NFS volumes yet).

IMO making them look like hard links is better than making them obvious
but less usable.


I would assume that there is a different interface for NFS permissions,


On the contrary.  All the Windows calls are naturally using the Win32
security datatypes and so, even if there's an API, the POSIX permissions
would have to be translated to Windows ACLs to make sense in Win32 calls.
[snip]
I made a quick test.  If you retrieve the security descriptor from a
file or directory on an NFS share, you get the following information,
all the time, regarless of the real owner, real group, and real permissions:

  Owner:  S-1-1-0 == "Everyone"
  Group:  S-1-1-0 == "Everyone"
  DACL:   NULL== Full access for everyone.

[much snipping] It's really sad that NFS shares
are not better than FAT file systems from the perspective of Win32
applications.


Ok, I'll concede that the integration isn't as good as it could be.
However, it looks to me like what is happening isn't quite as grim as
you suggest. What I see is a: the Explorer interface displays the
correct attributes (even the right uid/gid if mapping is *not* set up
correctly), and b: the security API's seem to only give you the
attributes from the perspective of the user invoking the API (i.e. you
can't see what they would look like for other people).

At any rate, Cygwin *isn't* the Windows API... Why shouldn't Cygwin be
allowed to get it right for those API's that ask for POSIX-style
permissions?

How are you getting this information? Explorer won't give you "normal"
security attributes on an NFS volume... is there a command-line tool I
don't know about, or did you write your own?

--
Matthew
If you can't use a real OS, at least use Cygwin to fake one!


--
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 and Interix interoperability?

[mwoehlke]

Corinna Vinschen wrote:

I don't get it.  We're using .lnk symlinks for quite some time and open
works transparently with them.


Sorry; clarification (again): open() in Windows, outside of Cygwin. I.e. 
if I try to open a path in Notepad that contains a symlink, it doesn't 
work with Cygwin's .lnk's. It *does* work with real NFS symlinks.



At any rate, Cygwin *isn't* the Windows API... Why shouldn't Cygwin be
allowed to get it right for those API's that ask for POSIX-style
permissions?


Cygwin is running in the Windows subsystem, Interix isn't.  Cygwin can
only use functions in the Win32 API, or in the native NT API as far as
the call is allowed from user space.


Explorer is able to retrieve these. Thus, I'm assuming that there /is/ 
an NT API way of doing it. Maybe I'm wrong.


I'll keep you posted if I ever get around to messing with this stuff.

--
Matthew
If you can't use a real OS, at least use Cygwin to fake one!

--
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: Launch APP over SSH

[mwoehlke]

Wesley Smith wrote:

I've been reading previous posts on this topic, but I haven;t been
able to get cygwin to do what I need.  I tried:

$ cygstart notepad

from a remote SSH login and nothing happened.


If you'll pardon a stupid question, why would you want to do such a 
thing? (Or, "what good would this do you?")


To try to be more helpful... What user is your sshd running as? If it is 
SYSTEM, have you checked 'allow service to interact with the desktop'?


--
Matthew
If you can't use a real OS, at least use Cygwin to fake one!

--
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: Launch APP over SSH

[mwoehlke]

http://cygwin.com/acronyms/#TOFU

Wesley Smith wrote:

I'm trying to run a program called MaxMSP. [snip]
Even though I won't be graphically interating with it, I still want to
be able to launch it this way.


One really cheap way would be to write an app that sits around and waits 
for a message to launch this other app, but it sounds like this might 
not be an option. I don't know if http://www.realvnc.com/ would be of 
any help?



To try to be more helpful... What user is your sshd running as? If it is
SYSTEM, have you checked 'allow service to interact with the desktop'?

How do I check this?


Control Panel->Administrative Tools->Services. Your SSH service *might* 
be "CYGWIN sshd", but it might not.

Find it and go to Properties->Log On.

--
Matthew
If you can't use a real OS, at least use Cygwin to fake one!

--
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: Launch APP over SSH

[mwoehlke]

Eric Blake wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Wesley Smith on 4/21/2006 1:59 PM:

PS

I also get the message WARNING: terminal is not fully functional . 
How do I get rid of this?


Usually, this is an indication that the remote machine does not have a
termcap/terminfo database entry for the $TERM variable being sent to it
[snip]
It should be possible to install your own terminfo database entry on
the remote machine to teach it how to deal with cygwin, and the
warning will go away.  However, I have not done this recently myself,
so I don't know the formula for this off the top of my head.


One way is to "borrow" Cygwin's. Another is to build one from a recent 
ncurses. http://www.interopsystems.com/tools/tm.aspx?m=727 has a fair 
amount of information on how to deal with this problem.


HTH

--
Matthew
Look! ...a hippo! *GDRLH!*

--
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 and Interix interoperability?

[mwoehlke]

Cary Jamison wrote:

I read that Vista will have "Built-in NFS for Unix interoperability."
[snip] If it is true, you may want to wait for Vista, where all your
problems will be solved! :-)


It's called "Services for UNIX-based Applications" (SUA). It's also in 
Windows 2003 R2, which is what I have. Except maybe for symlinks; those 
are supposed to be "more supported" in Vista, I hear. However, "waiting 
for Vista" is not an option for two reasons. One, I'm impatient, and 
two, we're talking about a build machine. For anyone unfamiliar with 
SCOP (C=Corporate), "build machine" = "don't ever reconfigure this box 
for *any* reason". Putting Vista on it will NOT be an option. Putting 
something as modern as 2003 on it is already a departure.


In other news, I also opened a related 'is this workable' discussion at 
http://www.interopsystems.com/tools/fb.aspx?m=8872 and folks there seem 
to think all that's needed is to hook into the NFS driver (for NFS 
stuff, anyway, but supporting Interix symlinks on a non-POSIX file 
system is trivial, and not my main concern anyway). I was thinking 
Cygwin could check if the underlying file system is NFS and if it is, 
try to dynamically load the NFS client driver. If successful, Cygwin 
would then be able to use the real NFS permissions (and symlinks) rather 
than kluging through ACL's (which doesn't work reliably, as Corinna 
pointed out)... not to mention work with *real* symlinks.


But I'm still just guessing. I haven't gotten to actually *looking* yet 
(it's not exactly in the job description, after all).


--
Matthew
Lions and tigers and ...penguins? We're being invaded!

--
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: How do I detect a failure in Make?

[mwoehlke]

Richard Quadling wrote:

I have the following bash script ...

#!/bin/sh
cvs up 2> $HOME/cvs1.log > $HOME/cvs2.log
cd phpdoc
autoconf -v -d --warnings=all &> $HOME/autoconf.log
./configure --with-source=./../php-src --with-pear-source=./../pear
--with-chm=yes --with-treesaving > $HOME/configure.log
make test > $HOME/make_test.log

[ $? -eq 0 ] || exit $?

make test_xml > $HOME/make_test_xml.log

[ $? -eq 0 ] || exit $?

make chm_xsl > $HOME/make_chm_xsl.log

[ $? -eq 0 ] || exit $?


Is there a way of stopping the makes if there was a problem.


(additions in-line)

You might want to try 'man bash'. Doing something based on the return 
status of a command is pretty basic. Also, TMTOWTDI:


if [ $? -ne 0 ] ; then exit $? ; fi
if [ $? -eq 0 ] ; then : ; else exit $? ; fi
if ! make > log ; then exit $? ; fi
if make > log ; then : ; else exit $? ; fi
make > log || exit $?

Note that using 'exit $?' is good practice because it means your 
*script* will fail, which means you can embed your *script* like you've 
embedded 'make' and take action based on if it succeeds or fails (this 
is ALWAYS good practice in the pipe-biased environment of UNIX). 
However, be careful that you don't do something that replaces $? with 
the exit status of someone other than 'make' (in which case you should 
either save the status or 'exit ').


--
Matthew
All of my signatures are 100% original. Including this one.

--
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: "rm -rf ./foo/" safe to use?

[mwoehlke]

Ross, George - DOA wrote:

I have never tested the cygwin NFS client against the above-mentioned NFS 
server.


Wait... Cygwin has an NFS client? Did I miss something? (How would/does 
this work with non-Cygwin applications?)


--
Matthew
All of my signatures are 100% original. Including this one.

--
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/

"Ghost" processes on Cygwin

[mwoehlke]

I'm seeing something funny. While trying to build a large program on 
Cygwin using cl.exe (i.e. I am building a non-Cygwin app; just using 
Cygwin to drive 'make'), every now and then, cl.exe hangs. Before you 
tell me I'm on the wrong list :-), here's the funny part. If I do 'ps' 
in Cygwin, I can see the 'cl' process, along with its WINPID. However, 
it doesn't show up in task manager! Also, there are about five processes 
that are clearly Cygwin processes (bash.exe or sh.exe) that do NOT show 
up in Cygwin's 'ps'.


Is there any logic to this that I'm missing? I want to attach a debugger 
(probably devenv, since gdb - unsurprisingly - doesn't seem to work) to 
cl.exe to try to find out why it's hung, but I can't find the pid to 
attach to!


--
Matthew
All of my signatures are 100% original. Including this one.

Cygwin Configuration Diagnostics
Current System Time: Wed Apr 26 17:01:30 2006

Windows 2003 Enterprise Server Ver 5.2 Build 3790 Service Pack 1

Running under WOW64 on AMD64

Path:   C:\cygwin\w32dev
h:\mwoehlke\src
c:\j2sdk1.4.2_08\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\WINDOWS\MsNfs\
C:\WINDOWS\SUA\common\
C:\WINDOWS\SUA\usr\lib\
c:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\amd64
c:\Program Files (x86)\Perforce
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
C:\cygwin\usr\sbin
C:\cygwin\sbin
c:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin
c:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1003(mwoehlke)  GID: 513(None)
0(root)  513(None)544(Administrators)
545(Users)   1005(Debugger Users) 1008(NIS_mcast)
1009(NIS_root)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1003(mwoehlke)  GID: 513(None)
0(root)  513(None)544(Administrators)
545(Users)   1005(Debugger Users) 1008(NIS_mcast)
1009(NIS_root)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

USER = 'mwoehlke'
LD_LIBRARY_PATH = '/usr/lib/x86:/usr/X11R6/lib'
PWD = '/home/mwoehlke'
HOME = '/home/mwoehlke'
MAKE_MODE = 'unix'

HOMEPATH = '\Documents and Settings\mwoehlke'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Documents and Settings\mwoehlke\Application Data'
BASH_PROFILE_RUN = '1'
PROGRAMW6432 = 'C:\Program Files'
HOSTNAME = 'McKeon'
XKEYSYMDB = '/usr/X11R6/lib/X11/XKeysymDB'
VCDIR = 'C:\Program Files (x86)\Microsoft Visual Studio 8\VC'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'EM64T Family 15 Model 4 Stepping 1, GenuineIntel'
WINDIR = 'C:\WINDOWS'
VS80COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 
8\Common7\Tools\'
COMMONPROGRAMW6432 = 'C:\Program Files\Common Files'
OLDPWD = '/home/mwoehlke'
JAVAHOME = '/usr/java/j2sdk1.4.2'
USERDOMAIN = 'MCKEON'
COMMONPROGRAMFILES(X86) = 'C:\Program Files (x86)\Common Files'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
XAPPLRESDIR = '/usr/X11R6/lib/X11/app-defaults'
XCMSDB = '/usr/X11R6/lib/X11/Xcms.txt'
!:: = '::\'
TEMP = '/cygdrive/c/DOCUME~1/mwoehlke/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files'
XNLSPATH = '/usr/X11R6/lib/X11/locale'
LIB = 'C:\Program Files (x86)\Microsoft Visual Studio 
8\VC\atlmfc\lib;C:\Program Files (x86)\Microsoft Visual Studio 
8\VC\PlatformSDK\Lib;C:\Program Files (x86)\Microsoft Visual Studio 8\VC\lib'
SFUDIR = 'C:\WINDOWS\SUA\'
USERNAME = 'mwoehlke'
SUA_ROOT = '/dev/fs/C/WINDOWS/SUA/'
CLUSTERLOG = 'C:\WINDOWS\Cluster\cluster.log'
PROCESSOR_LEVEL = '15'
INTERIX_ROOT = '/dev/fs/C/WINDOWS/SUA/'
NDOC_DIR = '/w32dev/ndoc/1.3/bin/net/1.1'
FP_NO_HOST_CHECK = 'NO'
INPUTRC = '/home/mwoehlke/.inputrc_uow'
SYSTEMDRIVE = 'C:'
PROCESSOR_ARCHITEW6432 = 'AMD64'
EDITOR = 'vi'
UOW_CC = '/usr/bin/cc'
USERPROFILE = 'C:\Documents and Settings\mwoehlke'
PS1 = '\[\e]0;\w\a\]\[\e[1;31m\]\t [EMAIL PROTECTED] 
\[\e[36m\]\w\[\e[37m\]\$\[\e[0m\] '
LOGONSERVER = '\\MCKEON'
PROCESSOR_ARCHITECTURE = 'x86'
!C: = 'C:\cygwin\bin'
SHLVL = '1'
TERMINFO = '/home/mwoehlke/.terminfo'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
INTERIX_ROOT_WIN = 'C:\WIN

Re: "Ghost" processes on Cygwin

[mwoehlke]

Volker Quetschke wrote:

mwoehlke wrote:
I'm seeing something funny. While trying to build a large program on 
Cygwin using cl.exe (i.e. I am building a non-Cygwin app; just using 
Cygwin to drive 'make'), every now and then, cl.exe hangs. Before you 
tell me I'm on the wrong list :-), here's the funny part. If I do 'ps' 
in Cygwin, I can see the 'cl' process, along with its WINPID. However, 
it doesn't show up in task manager! Also, there are about five 
processes that are clearly Cygwin processes (bash.exe or sh.exe) that 
do NOT show up in Cygwin's 'ps'.

Can you enter
$ ls /proc/*/fd
in another cygwin console and report if it helps? It might unhang the stuck
process.


Hmm... nope. In fact, that got stuck too. 'ls /proc/2072' dies and must 
be 'kill -9'd. 'ps | grep 2072' says:

   PID  PPID  PGID WINPID  TTY  UIDSTIME COMMAND
  2072 1  1876   2072  con 1003   Apr 21 /usr/bin/bash

'ls /proc//fd' failed to revive it. If I cat it's cmdline 
(in its /proc), I see that it matches what 'make' is claiming it ran. 
Something a little suspicious(?); fd's 5-7 are all pointing at the same 
place and that place is a directory. Also, 255 is pointing at the shell 
script (/w32dev/cl32.exe) that launched (exec()'d) the process. If it's 
relevant, 'make' (which does show up as the parent) actually launched 
'cl'; it exec()'d through 3-4 scripts to get to the actual binary.


Is there any logic to this that I'm missing? I want to attach a 
debugger (probably devenv, since gdb - unsurprisingly - doesn't seem 
to work) to cl.exe to try to find out why it's hung, but I can't find 
the pid to attach to!


(Also, for the sake of brevity, please don't quote my cygcheck.out! :-) 
Um... PCYMTNQTA? ;-) (TA=Text Attachments))


--
Matthew
All of my signatures are 100% original. Including this one.

--
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: "Ghost" processes on Cygwin

[mwoehlke]

mwoehlke wrote:

Volker Quetschke wrote:

mwoehlke wrote:
I'm seeing something funny. While trying to build a large program on 
Cygwin using cl.exe (i.e. I am building a non-Cygwin app; just using 
Cygwin to drive 'make'), every now and then, cl.exe hangs. Before you 
tell me I'm on the wrong list :-), here's the funny part. If I do 
'ps' in Cygwin, I can see the 'cl' process, along with its WINPID. 
However, it doesn't show up in task manager! Also, there are about 
five processes that are clearly Cygwin processes (bash.exe or sh.exe) 
that do NOT show up in Cygwin's 'ps'.

Can you enter
$ ls /proc/*/fd
in another cygwin console and report if it helps? It might unhang the 
stuck

process.


Hmm... nope. In fact, that got stuck too. 'ls /proc/2072' dies and must 
be 'kill -9'd. 'ps | grep 2072' says:

   PID  PPID  PGID WINPID  TTY  UIDSTIME COMMAND
  2072 1  1876   2072  con 1003   Apr 21 /usr/bin/bash


It looks like this process was orphaned somehow... it wouldn't 'kill' or 
'kill -9', so I used task manager to end it, which didn't seem to affect 
any of my active sessions. 'ls /proc/*' and 'ls /proc/*/fd' both work 
now, but don't help.


I should mention that it dies politely if I send it just about any 
signal, but I need it to NOT get stuck in the first place... so I either 
want to figure out why it's hanging, or at least how to try to debug it.


--
Matthew
All of my signatures are 100% original. Including this one.

--
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: Call for testing Cygwin snapshot

[mwoehlke]

Dave Korn wrote:

On 26 April 2006 20:21, Jerry D. Hedden wrote:

In this case, I used the full 20060426 snapshot and generated some stuck
processes.  The output from 'ps' showed the following:

  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
 2944   11332  29292? 78809 13:54:03 /usr/bin/diff
32184   1 436   2860? 78809 14:00:03 /usr/bin/mv
 1560   1   28372  29084? 78809 14:06:05 /usr/bin/diff
 9768   1   23420  24436? 78809 14:12:04 /usr/bin/diff

Looking at the Windows Task Manager, those processes were not listed,
but what I suppose to be their shell processes were:

Image Name  PID
bash.exe2736
bash.exe9500
bash.exe   29048
bash.exe   30324

Note that no bash processes were listed by Cygwin under 'ps'.  (Is this
a clue?)


  Um.  I wonder if those processes are or aren't actually there.

  Isn't there something about bash keeping a pid table of recently-dead
kind-of-zombie processes hanging around for a while?  Do they show up in "ps"?
I have a vague memory but haven't tracked down the thread yet.  EB or CV might
be able to weigh in on this.


Hmm, that sounds almost exactly like my problem. I'm seeing a large 
'make' process occasionally get stuck[1], except the process that 
*seems* to be stuck shows up in 'ps', but not task manager. Sound familiar?


One additional nugget is that I left it "stuck" over night; when I came 
back this morning, I found a 'bash' that had been spawned by 'make' 
where there shouldn't have been any (it should have exec()'d itself out 
of existence). This sounds like the same problem.


I'm running what should be the latest release (minus any updates in the 
last few days), however, not a snapshot; see [1] for my cygcheck output.


[1] http://cygwin.com/ml/cygwin/2006-04/msg00801.html

--
Matthew
Ok, so the quotes aren't entirely original.

--
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: "Ghost" processes on Cygwin

[mwoehlke]

Christopher Faylor wrote:

On Wed, Apr 26, 2006 at 05:12:31PM -0500, mwoehlke wrote:
I'm seeing something funny. While trying to build a large program on 
Cygwin using cl.exe (i.e. I am building a non-Cygwin app; just using 
Cygwin to drive 'make'), every now and then, cl.exe hangs. Before you 
tell me I'm on the wrong list :-), here's the funny part. If I do 'ps' 
in Cygwin, I can see the 'cl' process, along with its WINPID. However, 
it doesn't show up in task manager! Also, there are about five processes 
that are clearly Cygwin processes (bash.exe or sh.exe) that do NOT show 
up in Cygwin's 'ps'.


Is there any logic to this that I'm missing?


Yes.  Windows doesn't implement the exec* family of linux system calls
so cygwin has to kludge it.


Ok, thanks for the information. It looks like it is actually bash that 
is hanging (I wonder, is the exec() failing to clean up properly), but 
I'm not sure what to do about it. If I try to attach with gdb, gdb hangs 
(but I can 'kill' it with a fatal - i.e. not-SIGINT - signal). Any 
suggestions on where to go from here to try to debug this? Is there a 
'gdb-on-cygwin' howto somewhere that I'm missing?


(See also http://cygwin.com/ml/cygwin/2006-04/msg00844.html)

--
Matthew
Ok, so the quotes aren't entirely original.

--
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: How do I detect a failure in Make?

[mwoehlke]

Richard Quadling wrote:

On 26/04/06, mwoehlke <[EMAIL PROTECTED]> wrote:

Richard Quadling wrote:

I have the following bash script ...

#!/bin/sh
cvs up 2> $HOME/cvs1.log > $HOME/cvs2.log
cd phpdoc
autoconf -v -d --warnings=all &> $HOME/autoconf.log
./configure --with-source=./../php-src --with-pear-source=./../pear
--with-chm=yes --with-treesaving > $HOME/configure.log
make test > $HOME/make_test.log
make test_xml > $HOME/make_test_xml.log
make chm_xsl > $HOME/make_chm_xsl.log

Is there a way of stopping the makes if there was a problem.



Matthew said using [ $? -eq 0 ] || exit $? after each make line would work.


It doesn't. The issue is that the make function is crashing (the core
dump ??!!!??).


http://cygwin.com/acronyms/#IWFM. A process that dumps core results in a 
non-zero exit status (not that 'make' should ever core dump). Did you 
try some of the alternatives? Are you sure you haven't clobbered your 
exit code?


If you can run 'make' at the command line in such a way that it fails, 
does ' || echo fail' work?


--
Matthew
"Sorry. Wrong species." --ST-TNG


--
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: where to find "dig" command?

[mwoehlke]

Hiroki Sakagami wrote:

Where is "dig" DNS lookup command?
It seems that search at http://cygwin.com/packages/ has no result package.


http://www.isc.org/index.pl?/sw/bind/ - but I can't tell what you need 
to download; good luck!


--
Matthew
"Sorry. Wrong species." --ST-TNG


--
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: "Ghost" processes on Cygwin

[mwoehlke]

mwoehlke wrote:
I'm seeing something funny. While trying to build a large program on 
Cygwin using cl.exe (i.e. I am building a non-Cygwin app; just using 
Cygwin to drive 'make'), every now and then, cl.exe hangs. Before you 
tell me I'm on the wrong list :-), here's the funny part. If I do 'ps' 
in Cygwin, I can see the 'cl' process, along with its WINPID. However, 
it doesn't show up in task manager! Also, there are about five processes 
that are clearly Cygwin processes (bash.exe or sh.exe) that do NOT show 
up in Cygwin's 'ps'.


Following up on this... I still haven't determined a cause, but it seems 
to have gone away for the moment. I should note that a: I was building 
on an NFS volume, and b: I had running in another window 'while sleep 2; 
do make install; done' (an equivalent, anyway). After stopping the 
repeating 'make', I'm not seeing it any more.


Maybe this information can help with the 'cron job hangs' problem. 
Anyway, if anyone figures out anything, please share with the rest of us.


--
Matthew
"Sorry. Wrong species." --ST-TNG


--
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/

Setup colors... getting there!

[mwoehlke]

Igor Peshansky wrote:
> Try a setup snapshot ().

Curious to see if the 'ignores user's color scheme' problem was fixed, I 
decided to give one of these a whirl. My first attempt crashed while 
downloading the mirror list (VS2005 seems to indicate a NULL dereference 
in msvcrt.dll, but isn't giving much in the way of more useful 
information). But now it's not happening. Oh, well.


Anyway... the problem with colors is /improved/ but not fixed. The text 
is now legible (which is wonderful, thanks!) but the tree structure, 
including the clickable [+] and [-] icons is now 99.9% invisible (turns 
out they ARE a different color, but not one that is visually 
distinguishable from my window background).


My current window background color is (70,74,80); it seems this is the 
only color that controls the color of the tree lines (if I change this 
color, and ONLY this color, I also get a different color for the tree 
lines). Several choices of color (e.g. (64,0,128)), result in tree lines 
that *are* exactly the same color!


--
Matthew
Ncurses. Blessing console programs since 1993.


--
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: SVN_EDITOR

[mwoehlke]

Harmin Rueda wrote:

Hi:

I am executing svn commands from cygwin and I get this messages:

svn: None of the environments variables SVN_EDITOR, VISUAL or EDITOR is 
set, and no 'editor-cmd' run-time configuration option was found.


How can I solve this problem?


(I'm assuming you're using bash and not [t]csh, otherwise someone that 
knows csh will have to help...)


What does 'export' say? Are SVN_EDITOR, VISUAL, or EDITOR exported, or 
even set?


--
Matthew
This line intentionally left blank.


--
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 problem

[mwoehlke]

Cédric Bouttes wrote:

I have a problem with ssh on cygwin.

When i use : ssh localhost i have the following
message and so i can't connect on ssh locally

The authenticity of host 'localhost (127.0.0.1)' can't
be established.
RSA key fingerprint is
7a:83:37:4b:d2:e0:b7:f5:2a:30:a3:4b:db:26:bc:07.
Are you sure you want to continue connecting (yes/no)?
yes
Failed to add the host to the list of known hosts
(/home/Cedric/.ssh/known_hosts).
[EMAIL PROTECTED]'s password: 


Why ?


Sounds like your ~/.ssh/known_hosts is not writable.

You should also read...
Problem reports:   http://cygwin.com/problems.html

--
Matthew
"Ethics? We've heard of it" --Microsoft


--
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: Inconsistency in find ... -name ...

[mwoehlke]

Eric Blake wrote:

[snip] And be aware that my suggested alias is not perfect
(think exit codes, among other things


alias find='_find() {
  local result;
  trap "set +f; trap SIGINT" SIGINT
  find "$@";
  result=$?;
  set +f;
  trap SIGINT
  return $result;
}; set -f; _find'

An improvement?

--
Matthew
Hey, buddy, if it's OT, TITTTL!


--
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: rvxt-20050409-1 console problem [SUMMARY]

[mwoehlke]

Charles Wilson wrote:

I'm leaning toward this solution, in a more generic sense, like:
   "gui-switcher.exe --config=/etc/rxvt-selector.conf"

It'll go into the checkX package since it'll leverage a lot of the same 
code.  And that's why I need to track down these issues with 
rxvt-unicode-X+run+loginShell...'cause if they are not solved with 
run.exe, they'll show up again with gui-switcher.exe.


I know this isn't an "ideal" solution, but have you considered fork()ing 
and exec()ing 'checkX' and using wait() to get the return code? That 
would require your app to have checkX installed but would avoid 
duplicating the code and/or having to library-ize it (i.e. would be 
faster to implement).


OTOH a lib (or static lib) is generally not a bad idea.

--
Matthew
Hey, buddy, if it's OT, TITTTL!


--
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: console question

[mwoehlke]

[EMAIL PROTECTED] wrote:

Do you use a 640x480 screen? Full screen for a console sounds like a grand
waste of field of vision.


Eh, I *love* my full-screen consoles... sooo much text you can see at 
once! Of course, I also have no fewer than... um... four ;) monitors here.


--
Matthew
Hey, buddy, if it's OT, TITTTL!


--
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-only samba directory appears writable to Cygwin

[mwoehlke]

Peter Fales wrote:

We've got a directory which is mounted from a Samba server.  The server
is sharing the directory as read-only.  However under Cygwin

	access("/path/to/samba/mount/some_file",W_OK) 


is returning 0, indicating the that file is writable.I assume this
is because Cygwin doesn't "know" that directory is read-only.   Is there
any workaround (such as an option to "mount") that would tell cygwin
that the directory is read-only, or that all directories have 555 permission
instead of 755?


Hmm, if you were asking this of Linux, I'd say 'use a umask option in 
the mount'... does Cygwin not have such a thing? (NOTE: That question is 
directed at the other Cygwin folks; I looked and did not find one in the 
'man' so I'm guessing it does not?)


--
Matthew
All of my signatures are 100% original. Including this one.


--
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: Reading Term::ReadKey support for ActiveState Perl and Cygwin

[mwoehlke]

David Christensen wrote:

Paul Dorman wrote:

I've been racking my brains trying to read keystrokes in a Cygwin
shell with ActiveState Perl.


I recently evaluated Microsoft Services for Unix (SFU), which aims to
provide a Unix subsystem and GNU tool chain running on top of the Windows
kernel:

http://www.microsoft.com/technet/interopmigration/unix/sfu/default.mspx

Here is a commercial company that is closely aligned with SFU (I don't quite
understand the relationship):

 http://www.interix.com/


As I understand, the folks at interix.com developed Interix 2.0, 
originally known as OpenNT, until it was taken over by M$ around I 
believe version 3.0. From Rodney's comments, it seems they are still 
involved in the ongoing development and maintenance.



I'm reasonably certain SFU uses ActiveState Perl.  I don't know if it's the
standard ActiveState Perl we can download and install for Win32, or a
special SFU build.


I just re-ran the installer for SFU. Right at the bottom is the option 
to install "ActiveState PERL".



Unfortunately, I ran into some deal-breaker issues with SFU:

1.  SFU sets a number of environment variables (including PATH), which
broke Cygwin Perl's ability to make modules.

2.  SFU uses Unix line endings by default.  I need tools that work with
DOS line endings.  The SFU developers think that line endings
should be dealt with on a per-application basis, not by the
tool chain.  Some tools do accept both Unix and DOS line endings.
The SFU developers were responsive to my request to get SFU Bash
working with DOS line endings, but it isn't ready yet:

http://www.interix.com/tools/tm.aspx?m=9028


Oh, so that's *YOU* I've been talking to on the interix.com forums. :-)

Welcome to the club. I went first down the Interix path and ran into a 
mountain ("brick wall" doesn't begin to express the severity of my 
problems). So now I'm back to Cygwin, which /works/.


(Any replies to this part, please TITTTL)

--
Matthew
All of my signatures are 100% original. Including this one.


--
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/

Problems with setup colors in snapshot

[mwoehlke]

A while back I posted about the colors in setup.exe. I noticed that the 
text background color is fixed but that there is still a problem with 
the tree structure; specifically, the clickable [+] and [-] icons are, 
on my colors, effectively invisible. On some other color schemes I 
tried, they *are* 100% invisible.


I didn't see any response last time, so... is anyone able to reproduce 
this? I know P are TC but I don't have time to play with this right now :-(.


Also, thanks again to whoever fixed the text color!

More info:

0: I am looking at the latest, 2.529 snapshot of setup.exe, however I 
also see it in the (older) most recent "release" setup.exe.


1: It seems that "window background" is the only color that has any 
effect on the tree color. Therefore, the color must be somehow 
calculated from this(?). This might even be a bug in the UI component 
being used (i.e. a bug in M$ code).


2: My current "window background" color is (70,74,80), which makes the 
tree effectively invisible, but tinkering with a screenshot in M$Paint 
shows that it is still a *marginally* different color.


3: If I pick, e.g. (64,0,128) for my window background color, the tree 
becomes the *exact* same color as the background.


--
Matthew
All of my signatures are 100% original. Including this one.


--
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 X Directory/File Manager - Does one exist?

[mwoehlke]

Dave Elstner wrote:

Is there a Cygwin X program that functions similar to Windows Explorer?


Konquerer? (If you can figure out the whole KDE-on-Cygwin thing...)
I'm not aware of anything else, but that doesn't mean there isn't something.

--
Matthew
All of my signatures are 100% original. Including this one.


--
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: Problems with setup colors in snapshot

[mwoehlke]

Igor Peshansky wrote:

On Mon, 22 May 2006, mwoehlke wrote:

A while back I posted about the colors in setup.exe. I noticed that the
text background color is fixed but that there is still a problem with
the tree structure; specifically, the clickable [+] and [-] icons are,
on my colors, effectively invisible. On some other color schemes I
tried, they *are* 100% invisible.


Yes, this is most likely reproducible (as the foreground color of those
icons is *always* black.

>
>> 3: If I pick, e.g. (64,0,128) for my window background color, the
>> tree becomes the *exact* same color as the background.
>
> Hmm, weird -- for me the foreground color of the icons is *always*
> black.

Unfortunately, a: this isn't the case for me, and b: as you've so 
astutely pointed out, if it was that would still be problematic :-). (In 
reality, I've learned that *someone* is always going to exercise poor 
design and so I usually pick a background light enough for black to be 
at least marginally visible against it).


Anyway, I'm going to violate "policy" and attach a screenshot, as it 
seems prudent in this case. The screenshot is with my "normal" settings; 
if you open it in a graphics editor with a non-fuzzy bucket fill tool 
(e.g. M$Paint), you can flood the background and see that the tree is 
actually being painted, but in a /very/ subtly different color (in fact 
it is (66,74,80), which I *can* barely on my other monitor at much 
closer range - or if I magnify it). However this is "clearly not black" ;-).



Theoretically, it should be a simple matter of using MaskBlt instead of
BitBlt with the properly configured pen color and the properly set up
mask.  In practice, making this work on all platforms (including Win9x),
correctly, and with the minimum amount of code changes is a big pain.


I'm using Win2k3 R2 x64 and (see attached screenshot) I can assure you 
it doesn't work on my system. Maybe my OS is the problem? (Hmm... yup, 
the problem has to be Windows ;-).)


Also, I'd test on my XP system but it is consistently dereferencing a 
NULL :-(. (On W2k3 R2 it did that *once* and has since run just fine.)



If you're interested in looking at the code and providing a patch, grep
the setup sources for bitmap_dc (or BitBlt) and patch all those places.

If someone can take one of the bitmaps from the setup sources, and send me
a *complete* small program that draws that bitmap on a window drawing
context with the foreground and background colors coming from the Windows
color scheme, I'll see what I can do about incorporating that code into
setup.  As is, I'm too busy to wade through MSDNs incomplete documentation
on this.


I wish I could get to it, but I don't have the time right now :-(. I 
would appreciate if someone else can do it, otherwise if I haven't heard 
anything I may try to tackle this myself when I *do* have time.



Also, thanks again to whoever fixed the text color!


The ChangeLogs should show the name of the culprit.


Yeah, I'm too lazy to go download it right now and send a private 
e-mail, etc... I was hoping they watch the list ;-).


--
Matthew
All of my signatures are 100% original. Including this one.

--
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/

dereferenced NULL in setup-2.529 (possible patch)

[mwoehlke]

mwoehlke wrote:
> Also, I'd test on my XP system but it is consistently dereferencing a
> NULL :-(. (On W2k3 R2 it did that *once* and has since run just fine.)

I built setup (from the 2.529 tarball) and ran it in gdb, and got this 
stack trace:


#0  0x77c470d0 in msvcrt!memcpy () from 
/cygdrive/c/WINDOWS/system32/msvcrt.dll

#1  0x004566ca in new_cstr_char_array ([EMAIL PROTECTED]) at String++.cc:294
#2  0x004527cc in do_download_site_info_thread (p=0x4dbd40) at site.cc:330
#3  0x7c80b50b in KERNEL32!GetModuleFileNameA () from 
/cygdrive/c/WINDOWS/system32/kernel32.dll

#4  0x004dbd40 in std::__ioinit ()
#5  0x0401 in ?? ()
#6  0x0002 in ?? ()
#7  0x004dbd40 in std::__ioinit ()
#8  0x7ffde000 in ?? ()
#9  0x823c2600 in ?? ()
#10 0x0174ffc0 in ?? ()
#11 0x82026bf0 in ?? ()
#12 0x in ?? ()
#13 0x7c8399f3 in KERNEL32!FindAtomW () from 
/cygdrive/c/WINDOWS/system32/kernel32.dll
#14 0x7c80b518 in KERNEL32!GetModuleFileNameA () from 
/cygdrive/c/WINDOWS/system32/kernel32.dll

#15 0x in ?? () from

...it looks like new_cstr_char_array pukes if the 's' is empty (i.e. 
s.theData == NULL). This is an easy (almost trivial) fix, but I'm not 
sure that the fact that 's' is empty is not a bigger problem.


Anyway, if it's OK for 's' to be empty, here's a patch (this *seems* to 
work, i.e. no crash and I didn't notice anything else blatantly "funky"):


=== String++.cc : 289
  char *
  new_cstr_char_array (const String &s)
  {
size_t len = s.size() + 1;
char *buf = new char[len];
-  memcpy (buf, s.c_str (), len);
+  if (len > 1)
+memcpy (buf, s.c_str (), len);
+  else
+buf[0] = 0;
return buf;
  }

--
Matthew
All of my signatures are 100% original. Including this one.


--
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: Problems with setup colors in snapshot

[mwoehlke]

mwoehlke wrote:

Igor Peshansky wrote:

On Mon, 22 May 2006, mwoehlke wrote:

A while back I posted about the colors in setup.exe. I noticed that the
text background color is fixed but that there is still a problem with
the tree structure; specifically, the clickable [+] and [-] icons are,
on my colors, effectively invisible. On some other color schemes I
tried, they *are* 100% invisible.


Yes, this is most likely reproducible (as the foreground color of those
icons is *always* black.


3: If I pick, e.g. (64,0,128) for my window background color, the
tree becomes the *exact* same color as the background.


Hmm, weird -- for me the foreground color of the icons is *always*
black.


Unfortunately, a: this isn't the case for me, and b: as you've so 
astutely pointed out, if it was that would still be problematic :-). (In 
reality, I've learned that *someone* is always going to exercise poor 
design and so I usually pick a background light enough for black to be 
at least marginally visible against it).



Theoretically, it should be a simple matter of using MaskBlt instead of
BitBlt with the properly configured pen color and the properly set up
mask.  In practice, making this work on all platforms (including Win9x),
correctly, and with the minimum amount of code changes is a big pain.


I'm using Win2k3 R2 x64 and (see attached screenshot) I can assure you 
it doesn't work on my system. Maybe my OS is the problem? (Hmm... yup, 
the problem has to be Windows ;-).)


Also, I'd test on my XP system but it is consistently dereferencing a 
NULL :-(. (On W2k3 R2 it did that *once* and has since run just fine.)


After tweaking and rebuilding 2.529 from the tarball, I can confirm, for 
whatever it's worth, that I see the same behavior on XP. Maybe now that 
I have the sources built I'll be more likely to submit a patch. :-) Time 
permitting, of course.


--
Matthew
All of my signatures are 100% original. Including this one.


--
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: Problems with setup colors in snapshot

[mwoehlke]

Brian Dessent wrote:

mwoehlke wrote:

A while back I posted about the colors in setup.exe. I noticed that the
text background color is fixed but that there is still a problem with
the tree structure; specifically, the clickable [+] and [-] icons are,
on my colors, effectively invisible. On some other color schemes I
tried, they *are* 100% invisible.


As the one responsible for this breakage I'll try to look into this soon
and see if it can be fixed.  I thought that I tested this by varying all
the colors of the window but obviously I never tried an inverted scheme.


Thanks... Please let me know if I can help in any way.

And in case you didn't notice my non-directed appreciation, thanks again 
for fixing the text background problem :-).


--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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: Problems with setup colors in snapshot

[mwoehlke]

Igor Peshansky wrote:

On Mon, 22 May 2006, mwoehlke wrote:

Igor Peshansky wrote:

Hmm, weird -- for me the foreground color of the icons is *always*
black.


Unfortunately, a: this isn't the case for me, and b: as you've so
astutely pointed out, if it was that would still be problematic :-). (In
reality, I've learned that *someone* is always going to exercise poor
design and so I usually pick a background light enough for black to be
at least marginally visible against it).


Besides, I was wrong -- the foreground isn't always black, it may
sometimes be the inverted background color.


That was *my* first thought, but obviously that's not what I'm seeing. 
I'd be curious if anyone *does* know what's happening, because I can't 
figure it out (not without digging in the code, at least). :-)



I wish I could get to it, but I don't have the time right now :-(. I
would appreciate if someone else can do it, otherwise if I haven't heard
anything I may try to tackle this myself when I *do* have time.


Actually, I looked into this last night, and it turned out to be not too
bad for the common case.  There are still some glitches left, but it's
better than what we have now.  I'll send a preliminary patch to
cygwin-apps shortly.


Thanks... I'll let you and Brian get your heads together and figure this 
out. Again, let me know if you need any help.



Yeah, I'm too lazy to go download it right now and send a private e-mail,
etc... I was hoping they watch the list ;-).


No need to download anything:
<http://cygwin.com/cgi-bin/cvsweb.cgi/setup/ChangeLog?rev=2.547&content-type=text/x-cvsweb-markup&cvsroot=cygwin-apps> 


BTW, private emails are really discouraged, and most people working on
setup do read this list.
Igor


That was the *other* reason I just said it here ;-). Oh... ok, and it 
took a while to actually find the change (in 2.511). Thanks (again) Brian.


And thanks for the pointer, I'll try to remember that. :-)

--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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: dereferenced NULL in setup-2.529 (possible patch)

[mwoehlke]

Brian Dessent wrote:

mwoehlke wrote:


I built setup (from the 2.529 tarball) and ran it in gdb, and got this
stack trace:


Thanks for the debugging.  I must have missed the original report, as I
don't see the parent post of this thread.  Under what circumstances is
this repeatable?  It looks like the probable case is that
get_url_to_string() is not able to fetch the URL of the mirrors list,
and hence 'mirrors' is empty.


No, you probably didn't... the original report was buried in 
http://cygwin.com/ml/cygwin/2006-05/msg00074.html which didn't seem to 
get much reading, under "hmm, that's funny, now it's working". That was 
on my W2k3 R2 computer. Originally, I gave up trying to debug it because 
it seemed to be a fluke.


It isn't an empty mirror list problem, though; on my XP computer, it 
consistently blows up shortly /after/selecting/ a mirror, so your guess 
is about one step too early :-).


Anyway, I found something interesting... I was using 
http://mirrors.kernel.org when it blew up. If I use 
http://mirrors.mcs.anl.gov, then it's OK.



As cgf alludes, the state of string handling in setup is currently quite
a mess.  There is kind of a mix std::string, a homemade String class,
and C strings.  We're trying to get rid of the homemade kind.

From looking at site.cc it seems that get_site_list() is in dire need of
refactoring.  I think it would make things a lot simpler to just have
load_site_list() take a string, and then process it using c_str(),
skipping the whole new_cstr_char_array() mess.  It makes no sense to go
and allocate something just to pass to load_site_list(), only to then
free it.  And eventually everything in String++.{cc,h} needs to die
anyway.

I will try to prepare a fix along these lines soon.


Ok, you know the code much better than I. :-) Meanwhile, it WFM with the 
patch in the previous message, so I'll just run that (or use a different 
mirror ;-)) until there is another snapshot or release.


p.s. What's the snapshot schedule for setup.exe... less often that 
cygwin1.dll, I take it?


--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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: Visibility of Samba shares after ssh login

[mwoehlke]

Guenter Bachler wrote:
I started the ssh-server on the windows client in order to log-on to a 
Linux maschine

and vice verse. On the Windows client several SAMBA shares have been mapped
and correctly displayed with the 'mount' command  in the cygwin shell.

Now invoking an ssh login session from the Linux machine on the Windows 
client

(under my regular Windows account), the mount command does not display the
SAMBA shares anymore (beginning with drive letters k)

Is there any simple procedure to remount all SAMBA shares
automatically in the ssh session?


Not an answer, but I have a similar problem... In fact, this is AFAICT 
one of *the* most common problems (and yes I've STFW and STFML and did 
not find a solution that WFM'd). So, if you figure it out, please share.


(The annoying part is that I somehow got this to work on *one* computer, 
and can't figure out how to do it again.)


Anyway, does 'net use' on your ssh session show all the "missing" drives 
as "unavailable"?


--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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: export arrays from cygwin ksh

[mwoehlke]

bob wrote:
I have an hp unix script that runs in ksh and am porting it to PC.  It uses and 
exports arrays in hp unix.  Does not seem to work in cygwin.  Can anybody offer 
suggestions to accomodate?  I tried to put an example below, but I was labeled 
a top poster and it would not let me do it.  


Eh? I've never had a message bounce (is there actually something that 
tries to bounce http://cygwin.com/acronyms/#TOFU? ...must not work very 
well.)


Did you try submitting your example as an attachment?

Back to the question: by "exports arrays" you mean it needs to export an 
array so that it is inherited by sub-shells? Also, what shell are you 
using on Cygwin?


It does seem like this doesn't work - at least, not how I would expect 
it to - on bash (either on Cygwin or on Linux). Maybe you should try ksh 
on Cygwin.


--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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: export arrays from cygwin ksh

[mwoehlke]

mwoehlke wrote:

bob wrote:
I have an hp unix script that runs in ksh and am porting it to PC.  It 
uses and exports arrays in hp unix.  Does not seem to work in cygwin.  
Can anybody offer suggestions to accomodate?  I tried to put an 
example below, but I was labeled a top poster and it would not let me 
do it.  


It does seem like this doesn't work - at least, not how I would expect 
it to - on bash (either on Cygwin or on Linux).


Oh, ok, it doesn't work in bash:

GNU Bash-3.0
...
BUGS
   ...
   Array variables may not (yet) be exported.

(Hmm... bugs: "it's too big and slow"?)

--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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: Visibility of Samba shares after ssh login

[mwoehlke]

mwoehlke wrote:

Guenter Bachler wrote:
I started the ssh-server on the windows client in order to log-on to a 
Linux maschine
and vice verse. On the Windows client several SAMBA shares have been 
mapped

and correctly displayed with the 'mount' command  in the cygwin shell.

Now invoking an ssh login session from the Linux machine on the 
Windows client
(under my regular Windows account), the mount command does not display 
the

SAMBA shares anymore (beginning with drive letters k)

Is there any simple procedure to remount all SAMBA shares
automatically in the ssh session?


Not an answer, but I have a similar problem... In fact, this is AFAICT 
one of *the* most common problems (and yes I've STFW and STFML and did 
not find a solution that WFM'd). So, if you figure it out, please share.


(The annoying part is that I somehow got this to work on *one* computer, 
and can't figure out how to do it again.)


Anyway, does 'net use' on your ssh session show all the "missing" drives 
as "unavailable"?


Eureka! It helps to pay attention to what is actually going on on the 
*working* computer :-). I apparently got things working by hacking my 
sshd service to run '/bin/bash -c /usr/local/sbin/sshd_init' (which is a 
script I wrote) instead of '/usr/sbin/sshd'. My 'sshd_init' looks 
something like this:


#!/bin/bash

export PATH="/bin:/usr/bin:/usr/sbin:$PATH"
export CYGWIN='tty'
for drv in 
  do net use ${drv}: /delete &>/dev/null
done
net use : 
<...>
umount <...> &>/dev/null # unmount anything that needs to be mounted
mount -f <...>
<...>
/usr/sbin/sshd -D

--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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/

ssh + nfs = no write permission

[mwoehlke]

I *think* this is new... if not, would appreciate someone pointing me at 
what search terms worked better than my attempts.


Anyway... I have two computers - one XP, one W2k3 R2 - running Cygwin 
with network mounts over ssh set up as described in 
.


This works fine on the XP machine, but on the W2k3 machine, I can *read* 
but not *alter* (write, change permissions, etc) files on the network 
mounts (local drives are OK though).


I suspect a permission problem on the ssh user and/or something with how 
shares work on 2k3 vs. XP. I'm not sure, however, how to investigate the 
permissions possibility or what I would be looking for.


Any guesses?

--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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/

...even stranger (was: ssh + nfs = no write permission)

[mwoehlke]

mwoehlke wrote:
I *think* this is new... if not, would appreciate someone pointing me at 
what search terms worked better than my attempts.


Anyway... I have two computers - one XP, one W2k3 R2 - running Cygwin 
with network mounts over ssh set up as described in 
<http://cygwin.com/ml/cygwin/2006-05/msg00636.html>.


This works fine on the XP machine, but on the W2k3 machine, I can *read* 
but not *alter* (write, change permissions, etc) files on the network 
mounts (local drives are OK though).


I suspect a permission problem on the ssh user and/or something with how 
shares work on 2k3 vs. XP. I'm not sure, however, how to investigate the 
permissions possibility or what I would be looking for.


Any guesses?


Ok, now this is *really* bizarre... if I log in as me, all is OK (minus 
the above issue). If I log in as "Administrator":

- on the XP box, I get "Read from socket failed: Connection reset by peer".
- on the 2k3 box, I can log in, but my network drives all show up as 
'unavailable'.


If I log in as a *different* user (2k3 only, the XP box doesn't know any 
other users), I get a completely different set of network shares.


This implies that the share re-creation is only working for my user, but 
I'm not sure how that is possible, as my sshd service is running as the 
user '.\sshd_server'.


AFAIK, I *did* set up sshd with ssh-host-config; the only thing I 
changed was to re-create the Windows service (all via cygrunsrv) so it 
would run my initialization script instead of the actual sshd executable.


--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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: Handling special characters (\/:*?"<>|) gracefully

[mwoehlke]

Hicks,Mike wrote:
There are a number of special characters that cannot be used in 
filenames on the NTFS filesystem [snip]

[much snipage]


You might want to play around with "managed mounts" ('man mount'), if 
they do what I think I heard they do (namely, "deal" with such things 
for you). Supposedly you can get case sensitivity - in the sense that 
'Readme' and 'README' can co-exist - out of them as well.


(Speaking of case sensitivity, is it a Windows limitation that Cygwin 
can't do this? I'm pretty sure it isn't an NTFS limitation, as Interix 
has true case-sensitivity.)


--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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: Visibility of Samba shares after ssh login

[mwoehlke]

, also TOFU reformatted...

Guenter wrote:

mwoehlke wrote:

Guenter Bachler wrote:

I started the ssh-server on the windows client in order to log-on
to a Linux maschine and vice verse. On the Windows client several
SAMBA shares have been mapped and correctly displayed with the
'mount' command  in the cygwin shell.

Now invoking an ssh login session from the Linux machine on the 
Windows client (under my regular Windows account), the mount

command does not display the SAMBA shares anymore (beginning
with drive letters k)

Is there any simple procedure to remount all SAMBA shares 
automatically in the ssh session?


[snip]
Anyway, does 'net use' on your ssh session show all the "missing" 
drives as "unavailable"?


Yes, 'net use' lists all missing drives as 'unavailable'. 


Ok, that's expected (but helps confirm what's going on).


I am currently playing with a python script using
wshnw.MapNetworkDrive to re-map the network connections.
It starts to work but there are still some error messages
concerning denied access to the samba shares. 


Well, without knowing what those errors are, we can't do much to
help.

You could also try something like the solution I posted in follow-up
to my previous message...

--
Matthew
Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir


--
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: export arrays from cygwin ksh

[mwoehlke]

Thorsten Kampe wrote:

* mwoehlke (2006-05-23 16:37 +)
It does seem like this doesn't work - at least, not how I would expect 
it to - on bash (either on Cygwin or on Linux). Maybe you should try ksh 
on Cygwin.


He said he did. Read the subject of this thread.


Sorry, my apologies...
(Maybe he should try the *right* ksh? ;-) ...as per the second instance 
of this thread.)


--
Matthew
Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir


--
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: slow share = slow scripts?

[mwoehlke]

Larry Hall (Cygwin) wrote:

mwoehlke wrote:
I'm trying to run some scripts off of a slow network share, and it 
takes *forever* in Cygwin (it's OK in Interix).


Looking at an strace (attached) via 'sort -n' shows a LOT of time 
being spent in read(), apparently just after (caused by?) an fstat(), 
which means this feels like an inefficiency somewhere in Cygwin's 
POSIX emulation. Other than "RTFSC", does anyone have any ideas what I 
could do (workarounds, etc) so that I can run scripts in a reasonable 
amount of time? (Might this have anything to do with my share being 
non-writable?)


Take a look at the -x, -E, and -X flags of 'mount'. Perhaps these will help
you.


Hmm, those are mutually contradictory... guess I'll "experiment". Out of 
curiosity, what are any of these expected to do?



Sorry for the .bz2, but 248k seemed a little excessive :-).


And actually sending unsolicited straces to the list is discouraged.


Sorry, didn't know that... it seemed relevant.

Somewhat OT, why does 'strace bash -c foo > /foo_strace' generate a 
file with DOS line-endings? None of my mounts are 'textmode'...


'strace' does not use cygwin1.dll.


Ah, makes sense, thanks.

--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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, gdb and SEH [was RE: 1.5.19: changes have broken Qt3]

[mwoehlke]

clayne@ wrote:

BTW:

Myself, I had just updated to CVS gdb. Currently it looks like SIGINT is busted
(well atleast initiating via ctrl-c) and performance under gdb is crap (probably
because I'm trying to debug something with millions of objects - each with their
own mutexes).


Hmm, build problem maybe? Dave has the right idea. As for speed, do you 
know if you built with optimizations or with debug symbols? That might 
make a difference in speed...


(* Please Configure Your Mailer To Not Use Your E-mail Address As Your 
Name Unless You Really *Want* To Be Spammed)


--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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: slow share = slow scripts?

[mwoehlke]

Larry Hall (Cygwin) wrote:

On 05/25/2006, mwoehlke wrote:

Larry Hall (Cygwin) wrote:
Take a look at the -x, -E, and -X flags of 'mount'. Perhaps these 

will help

you.


Hmm, those are mutually contradictory... guess I'll "experiment". Out 
of curiosity, what are any of these expected to do? 


They are indeed mutually exclusive.  See 'man mount' for an explanation 
of the

flags.  You might want to try -x or -X.


Right, I *was* looking at the man, which is why I was confused. It 
doesn't say why this would help, though; does it somehow allow Cygwin to 
skip the fstat() call? Also, why *is* fstat() so inefficient? Can 
anything be done about it?


I *am* going to play with them, if I can convince Cygwin to let me 
*un*mount the path. :-)


--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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: slow share = slow scripts?

[mwoehlke]

Larry Hall (Cygwin) wrote:

mwoehlke wrote:
I'm trying to run some scripts off of a slow network share, and it 
takes *forever* in Cygwin (it's OK in Interix).


Looking at an strace (attached) via 'sort -n' shows a LOT of time 
being spent in read(), apparently just after (caused by?) an fstat(), 
which means this feels like an inefficiency somewhere in Cygwin's 
POSIX emulation. Other than "RTFSC", does anyone have any ideas what I 
could do (workarounds, etc) so that I can run scripts in a reasonable 
amount of time? (Might this have anything to do with my share being 
non-writable?)



Take a look at the -x, -E, and -X flags of 'mount'. Perhaps these will help
you.


Thanks for the suggestion, but that was mostly counterproductive... :-)

-x -- 16s
-X -- 13s
-f -- 12s
-E -- 10s

...and I was getting 10s before, so either it isn't doing anything, it's 
making it works, or at best isn't helping enough to be useful.


Is there anything I can do about fstat()?

--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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: slow share = slow scripts?

[mwoehlke]

Igor Peshansky wrote:

On Thu, 25 May 2006, mwoehlke wrote:


Larry Hall (Cygwin) wrote:

On 05/25/2006, mwoehlke wrote:

Larry Hall (Cygwin) wrote:

Take a look at the -x, -E, and -X flags of 'mount'. Perhaps these

will help

you.

Hmm, those are mutually contradictory... guess I'll "experiment". Out of
curiosity, what are any of these expected to do?

They are indeed mutually exclusive.  See 'man mount' for an explanation of
the
flags.  You might want to try -x or -X.

Right, I *was* looking at the man, which is why I was confused. It
doesn't say why this would help, though; does it somehow allow Cygwin to
skip the fstat() call? Also, why *is* fstat() so inefficient? Can
anything be done about it?

I *am* going to play with them, if I can convince Cygwin to let me
*un*mount the path. :-)


Just a WAG, but do take a look at the -u and -s flags to mount/umount.
Otherwise, please let us know what exact error message you're getting from
umount.


Nope, wasn't umount'ing.. sorry, my bad. :-)

I was misremembering that Cygwin doesn't have or need a 'umount'. 
Must've been thinking about something else. At any rate, I know I have 
sometimes been able to re-mount drives without first unmounting them.


--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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: slow share = slow scripts?

[mwoehlke]

Larry Hall (Cygwin) wrote:

On 05/25/2006, mwoehlke wrote:
I was misremembering that Cygwin doesn't have or need a 'umount'. 
Must've been thinking about something else. At any rate, I know I have 
sometimes been able to re-mount drives without first unmounting them. 


You can use the '-f' flag to force a remount without 'umount'ing first.
Cygwin has a 'umount' though.


Ooh... and here I always thought '-f' was how you told it to *not* 
mount 'noexec' (which apparently isn't documented?). Ok, I'm all 
confused. :-)


--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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: slow share = slow scripts?

[mwoehlke]

Dave Korn wrote:

On 25 May 2006 18:21, mwoehlke wrote:

Larry Hall (Cygwin) wrote:

On 05/25/2006, mwoehlke wrote:

I was misremembering that Cygwin doesn't have or need a 'umount'.
Must've been thinking about something else. At any rate, I know I have
sometimes been able to re-mount drives without first unmounting them.

You can use the '-f' flag to force a remount without 'umount'ing first.
Cygwin has a 'umount' though.

Ooh... and here I always thought '-f' was how you told it to *not*
mount 'noexec' (which apparently isn't documented?). 


  Umm, sounds like you haven't tried "mount --help" yet?


Nope, I've tried 'man mount', though I'll admit I was looking at the -x, 
-X, -E flags I was pointed at.


Here is what I am talking about:
~$ mount h:/mwoehlke/src /usr/src
mount: defaulting to '--no-executable' flag for speed since native path
   references a remote share.  Use '-f' option to override.
   ^^^

...neither 'mount --help' or 'man mount' makes *any* mention of this 
additional functionality of the '-f' flag. See? I'm *not* imagining 
things. :-)


--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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: slow share = slow scripts?

[mwoehlke]

Gary R. Van Sickle wrote:

From: mwoehlke

[snip]
 Also, why *is* 
fstat() so inefficient?


Short answer:  because it gets a bunch of information about the file that
isn't necessarily available without hitting (open()ing) the file itself.


Like... what? Inode information? Looking at the man page for 'stat' (on 
Linux, anyway; apparently I don't have the libc man pages installed on 
Cygwin), I don't see anything that I would expect to need to *open* the 
file to retrieve.


Way way back in the OP, I mentioned that Interix doesn't have this 
problem, which would imply a "design flaw" in Cygwin. Maybe (probably) 
it is a *necessary* design flaw, BUT...


A while back I was thinking about tying Cygwin into the Interix 
subsystem for the sake of certain file-system calls... and things like 
fstat in particular. If the problem is that Cygwin's fstat 
implementation requires opening the file and Interix's does not, this 
just became a *very* compelling (for me, at least) argument to taking on 
that project.


Please note that I'm not asking anyone to do this... given the response 
I got last time, I don't have any illusions that this will happen short 
of my doing it myself (at which point I will be derided, and my work 
will never leave my office). However, I would appreciate any existing 
knowledge, or even pointers to where to start poking around, that anyone 
would care to share.


--
Matthew
Feed the hippo. Love the hippo. Run from the hippo.


--
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: slow share = slow scripts?

[mwoehlke]

Dave Korn wrote:

On 26 May 2006 16:38, mwoehlke wrote:
[snip]

Way way back in the OP, I mentioned that Interix doesn't have this
problem, which would imply a "design flaw" in Cygwin. Maybe (probably)
it is a *necessary* design flaw, BUT...


  You are now piling pointless and incorrect speculation on your invalid and
groundless assumptions.  This is a waste of time.


I don't consider reducing the possible cause of the to be a waste of time.

On ONE computer, I am running the same command from the same NFS mount, 
using bash-3.1 in both cases (Interix is 3.1.0, Cygwin is 3.1.17). That 
is a /number/ of controlled variables, with Cygwin/Interix being the 
obviously different one. Under those circumstances, I observe a very 
noticeable difference in execution times.


If that isn't a "bug" - and the (constructive) responses I have gotten 
seem to think it isn't - then it is a problem with the implementation of 
Cygwin on top of the Windows subsystem. I classify that as "a problem 
inherent in the design which is necessitated by the underlying 
architecture". Please try to understand that I am not attempting to 
insult Cygwin. In fact, I am trying to shift blame *away* from Cygwin!



[snip]
  See if you can find out where that line of code comes from.  Then read the
source code to the MSVCRT version of stat, which is shipped with VC, to see
how it gets the timestamps etc.  Then disassemble FindFirstFileExW in windbg
and see whether or not it opens the files that it calls.

  Then post again and explain how you think interix could stat a file without
having an open handle to it.


Interix is a different /subsystem/, with a totally different means of 
interacting with the underlying file system (particularly NFS) than the 
Windows subsystem. It probably doesn't make anything even resembling the 
same systems calls as Cygwin.



  Then post again and explain how you managed to tell that cygwin's having to
open the file is a substantial part of the speed difference between cygwin and
interix without having once read the source, profiled the code, or timed or
tested anything.


Sigh. Go back and read my OP. Notice that I attached an strace. Explain 
to me that the detailed profiling/timing information does not qualify as 
"profiling" or "time testing". Please do not make patently false claims 
that I have not attempted to diagnose the problem.


I will of course keep the list up to date of any pertinent findings.

--
Matthew
Feed the hippo. Love the hippo. Run from the hippo.


--
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: slow share = slow scripts?

[mwoehlke]

Christopher Faylor wrote:

On Fri, May 26, 2006 at 10:37:52AM -0500, mwoehlke wrote:
Way way back in the OP, I mentioned that Interix doesn't have this 
problem, which would imply a "design flaw" in Cygwin. Maybe (probably) 
it is a *necessary* design flaw, BUT...


A "necessary" design flaw?  Interesting concept.


Well, sure... something that is known to be problematic (I think this 
qualifies) that is nevertheless necessary because of limitations in 
Windoze. At least, I would have to guess that the slow code is 
necessitated by Windows, since it works better on Interix and 
wonderfully on Linux.


$ time ./foo

real0m0.296s
user0m0.000s
sys 0m0.005s

This is a 50x difference where the difference should be minimal. That 
said, under Interix it still takes almost 2 seconds, which is 7x-ish 
difference, but still nowhere near 50x, so the problem isn't (entirely) 
the NFS client or the latency w.r.t. the share.


Summary:

exec time/ |  little | big   |   stat
platform   |  script |script |
---+-+---+--
Linux  |  0.296s |1.105s | 0.122s(2)
Interix(1) |  1.828s |5.536s |   (3)
Cygwin(1)  | 10.688s | 6m37.578s | 0.350s(4)

Notes:
1 - These are the same physical box.
2 - On Linux, 'stat' took the same amount of time on either script.
3 - My Interix installation apparently doesn't have 'stat', so this 
entry is blank.
4 - The time taken on Cygwin varied a lot, up to about 1s, and was a 
little (but not a lot) longer for the large script. 0.35s is roughly the 
lower bound (for both).


Note that both test computers are sitting next to each other, on the 
same unmanaged switch, talking to the same NFS share on the other side 
of the country (so the hops to get there should be identical). Clearly 
Windows' NFS client's performance is sub-par, but that is only to be 
expected. The question is; what is Cygwin doing - that neither Linux nor 
Interix do - that exasperates the problem so badly? Do I need to be 
going over strace's with a fine-toothed comb?


Clearly, the 6.5+ minute time is unacceptable*. For now I'm taking the 
'copy everything locally' suggestion, but I would like to know why 
Cygwin performs several orders of magnitude(!) worse then either Linux 
or Interix. Also note that the 'stat' behavior seems to eliminate 
[f]stat() as the culprit, leaving the suspicious read()s without an 
obvious trigger.


(* "unacceptable" = "clearly this won't work, and I'll have to try 
something different")


Before Dave Korn decides to flame me (again), I am not asking for an 
immediate fix. I am posting my findings in case anything in them jumps 
out at someone else. I fully intend to track this down *myself* when I 
have the time to do so.



[snip] However, I would appreciate any existing
knowledge, or even pointers to where to start poking around, that anyone 
would care to share.


I think that most of the pointers and insight about what Cygwin does with
fstat are all nicely encapsulated in the source code, specifically
fhandler_disk_file.cc and fhandler.cc .


That qualifies as a pointer; thanks, I appreciate it. :-)

--
Matthew
Feed the hippo. Love the hippo. Run from the hippo.


--
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 3.x path completion problems

[mwoehlke]

burning shadow wrote:
  Like I said, it's unlikely that this is the thing that makes the 
difference, but you could

always have a quick try with the latest snapshot just in case:
http://cygwin.com/snapshots.  It might also be trying the different 
cygwin terminals, xterm

and rxvt as well as plain old dos console.


Oh, by the way. I'm working via SSH using PuTTY client. Maybe this is
the case. I'll try snapshots later, thanks.


For the record, yes it definitely happens with tab-completion.

I've seen a couple of bugs related to prompts with non-printing 
characters. On a Windows console, my two-line prompt that should end 
with a bold white '$' loses the bold attribute... but if I do a tab 
completion that echoes back possibilities, then it is bold unless I try 
to go back past the beginning of the line, at which point it becomes 
non-bold.


Specifically, the following prompt demonstrates the problem, if anyone 
wants to experiment:

export PS1='\[\e[1;36m\]\w\n\[\e[37m\]\$ \[\e[0m\]'
(And yes, it seems to be a bug with the 'set bold' being on the previous 
line, but it works on all other platforms, for example, if I ssh to a 
Linux box from the exact same Cygwin window and use the exact same 
format of prompt, slightly different because I have e.g. \t, \h, etc in it.)


On Konsole (from Linux via ssh, with TERM=linux), I see the exact 
problem you described in the OP. Hitting  fixes the 
cursor so you can see where the *real* end of the line is, but does not 
erase the junk.


Dave, are you saying you can reproduce this in 'stable-latest' but not 
in snapshots? If so, that's good news.


--
Matthew
Ncurses. Blessing console programs since 1993.


--
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: window resizing not updating COLUMNS and LINES

[mwoehlke]

Kenneth Nellis wrote:

mwoehlke wrote:

Kenneth Nellis wrote:

I'm not seeing the LINES and COLUMNS environment variables getting updated
correctly after resizing my terminal window. This occurs whether I'm using
rxvt or xterm. Furthermore, "echo $COLUMNS" and "printenv COLUMNS" don't
agree. (I didn't see relevant articles in the archives.)

This occurs regardless of how "shopt -s checkwinsize" is set.


FWIW, on *my* Cygwin, LINES and COLUMNS aren't even set... go figure.
:-)


Same here...I do my own export to get things started. --Ken


Wait, wait, step back... this in itself sounds like a problem. Can 
anyone on the list verify that Cygwin's bash is setting these *at all*? 
(Of course, Ken's OP seems to imply he has it at least half working, but 
something smells fishy here...)


Bash is *supposed* to set these behind-the-scenes without your doing 
anything. This seems to be how it works on Linux...


Testing with a Windows console window:
$ echo $LINES

$ echo $COLUMNS

$ export LINES COLUMNS
$ echo $LINES

$ echo $COLUMNS

$ bash
$ echo $LINES

$ echo $COLUMNS

$ echo $C
$CC   $COMMONPROGRAMFILES  $COMPUTERNAME  $COMP_WORDBREAKS
$COMSPEC  $CVS_RSH $CYGWIN
$ echo $C $C <-- yeah, that's broken too :-)

...and I see the same thing if I ssh in from Konsole (from a Linux box).

I understand why CGF wants this on cygwin-xfree, but I don't think it 
has anything to do with xfree (I will grant they may be more likely to 
have heard of it).


--
Matthew
Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir


--
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: window resizing not updating COLUMNS and LINES

[mwoehlke]

Samuel Thibault wrote:

mwoehlke, le Wed 31 May 2006 17:19:15 -0500, a écrit :

Kenneth Nellis wrote:

Same here...I do my own export to get things started. --Ken


Wait, wait, step back... this in itself sounds like a problem.


'export COLUMNS' is needed for 'printenv COLUMNS' to work,
since in the printenv case you need the variable to be
transferred to the child printenv process.


Ok, that makes sense, although my understanding is that if the child 
process is 'bash' (including a script run by bash), then it will have a 
non-exported copy of the var set correctly. Or rather, it would/should 
if this was working at all.


--
Matthew
Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir


--
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/

'ps' - is it supposed to do that?

[mwoehlke]

I was looking at 'ps' one day, wishing it would limit its output to just 
"my" processes. Just now, I realized it is... it is showing me all of 
*my* processes, rather than all of the *tty's* processes. On most other 
(real) OS's, I'm used to the limit - sans '-e' - being 'this /tty/', not 
'this /user/'.


So, I was wondering... is there a reason it works this way?

While I'm on the subject, does anyone know/remember if it is possible to 
recognize distinct real consoles (i.e. is it possible to show con/0, 
con/1, etc)?


--
Matthew
The hippo made me do it! What? What do you mean you can't see the hippo?


--
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: window resizing not updating COLUMNS and LINES

[mwoehlke]

Ehud Karni wrote:

On  Wed, 31 May 2006 18:47:24 -0500, mwoehlke wrote:

'export COLUMNS' is needed for 'printenv COLUMNS' to work,
since in the printenv case you need the variable to be
transferred to the child printenv process.

Ok, that makes sense, although my understanding is that if the child
process is 'bash' (including a script run by bash), then it will have a
non-exported copy of the var set correctly. Or rather, it would/should
if this was working at all.



[snip]

My conclusions:

Both rxvt and xterm do their job properly.


Hmm... then I guess Konsole (using ssh) is broken?
Here is what I got from an SSH session using Konsole:

$ stty -a | head -n 1 ; echo $LINES $COLUMNS
speed 38400 baud; rows 71; columns 197; line = 0;

(change the window size)
$ stty -a | head -n 1 ; echo $LINES $COLUMNS
speed 38400 baud; rows 69; columns 196; line = 0;

(change the window size back)
$ stty -a | head -n 1 ; echo $LINES $COLUMNS
speed 38400 baud; rows 71; columns 197; line = 0;

$

...as you can see, in this instance they never worked at all. Seems 
there is an issue with bash being told to update these vars. It doesn't 
work when bash starts up, nor does it work when Konsole is resized, but 
apparently it works if rxvt/xterm is resized (I assume you are running 
both programs locally?).



The export is not needed (LINES and COLUMNS are local variables).
The stty does not set these vars. (both tested separately, not shown).


Right.


The bash variables are not set until the window change size
(until bash gets the SIGWINCH signal ? ).

Since it seems to work fine (almost), I guess the problem is with
cygwin1.dll 1.5.19.


Yup, must be something like that.


BTW. On linux (locally compiled bash) the LINES & COLUMNS are set
 even before changing window size.


I tried (all testing done with Konsole):
- local Linux box
- remote Linux box via ssh
- remote Solaris box via ssh
- remote HP-UX box via telnet
...and all worked as expected.

--
Matthew
Lions and tigers and HIPPOS! Everyone needs a hippo!


--
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/

Populating /var/run/utmp?

[mwoehlke]

I would like to use 'w' on my Cygwin installation. I found 
http://cygwin.com/ml/cygwin/2001-09/msg01177.html, but it only seems to 
work on one of my computers:


$ echo $CYGWIN
binmode tty ntsec
$ w
 13:03:11 up 5 days, 22:30,  0 users,  load average: 0.00, 0.00, 0.00
USER TTYLOGIN@   IDLE   JCPU   PCPU WHAT
$

Is there a different work-around other than setting CYGWIN=tty? (Note 
that I am having the same *symptom*, /var/run/utmp is empty).


--
Matthew
Lions and tigers and HIPPOS! Everyone needs a hippo!


--
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: Populating /var/run/utmp?

[mwoehlke]

Brian Dessent wrote:

mwoehlke wrote:


I would like to use 'w' on my Cygwin installation. I found
http://cygwin.com/ml/cygwin/2001-09/msg01177.html, but it only seems to
work on one of my computers: [snip]


Are you sure you're not trying to
set CYGWIN=tty after the first shell has already initialized?  It won't
work if you do that, it has to be set before.


Hmm... no I'm not sure :-). I am going to try with CYGWIN=tty set in the 
registry (ala Control Panel->System->Advanced->E10t Variables)... that 
seems to work for "on the glass" sessions but I will need to restart 
sshd to test those, and I'm currently using some of those sessions.


Seems to work on *one* computer, anyway.

Thanks...

--
Matthew
Lions and tigers and HIPPOS! Everyone needs a hippo!


--
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: 'ps' - is it supposed to do that?

[mwoehlke]

mwoehlke wrote:
I was looking at 'ps' one day, wishing it would limit its output to just 
"my" processes. Just now, I realized it is... it is showing me all of 
*my* processes, rather than all of the *tty's* processes. On most other 
(real) OS's, I'm used to the limit - sans '-e' - being 'this /tty/', not 
'this /user/'.


So, I was wondering... is there a reason it works this way?


Should I take the resounding silence to mean "yes, that's how we want it 
to work, now go away... WJM after all"?


While I'm on the subject, does anyone know/remember if it is possible to 
recognize distinct real consoles (i.e. is it possible to show con/0, 
con/1, etc)?


Hmm, well I guess CYGWIN=tty makes this go away anyway.

--
Matthew
Look! ...a hippo! *GDRLH!*


--
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: UNIX Network Programming (unpve13e) make failing (AF_INET6 undeclared).

[mwoehlke]

Williams, Gerald S (Jerry) wrote:

Huw wrote:

The next issue I have is:

mcast_leave.c: In function `mcast_leave_source_group':
mcast_leave.c:78: error: storage size of 'mreq' isn't known


I don't know anything about the ip_mreq_source structure,
but it looks to me like the current version may be having
general issues with support for various platforms and
configurations.


Right. One of our products was defining it for the longest time, and 
suddenly it started breaking on Linux, so it seems like it's very spotty 
whether or not the OS will define this structure. RHEL3 doesn't seem to 
have it, but FC4 does. So does Solaris 10 (x86, anyway), but not Solaris 
9 (sparc). My copy of Cygwin seems to have it, but only in 
.


--
Matthew
Who let the hippos out?


--
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: Populating /var/run/utmp?

[mwoehlke]

mwoehlke wrote:

Brian Dessent wrote:

mwoehlke wrote:

I would like to use 'w' on my Cygwin installation. I found
http://cygwin.com/ml/cygwin/2001-09/msg01177.html, but it only seems to
work on one of my computers: [snip]


Are you sure you're not trying to
set CYGWIN=tty after the first shell has already initialized?  It won't
work if you do that, it has to be set before.


Hmm... no I'm not sure :-). I am going to try with CYGWIN=tty set in the 
registry (ala Control Panel->System->Advanced->E10t Variables)... that 
seems to work for "on the glass" sessions but I will need to restart 
sshd to test those, and I'm currently using some of those sessions.


Ok, power failure, NOT how I wanted to reboot... But 'w' is working now; 
thanks again!


--
Matthew
"Sorry. Wrong species." --ST-TNG


--
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: Could not touch file when specify full path in Cygwin in .bat file

[mwoehlke]

[EMAIL PROTECTED] wrote:

Hi, Cygwin support group,

I have problem to touch a file when specify the full path. Here are some 
examples. MKS works fine

-- Filename with special characters
D:\>touch D:[EMAIL PROTECTED]&()[EMAIL PROTECTED]&()_+

[snip]

And, given that I don't see a POSIX-style path anywhere, where exactly 
are you using Cygwin?


This works for me in Cygwin's bash:
/tmp$ touch '[EMAIL PROTECTED]&()[EMAIL PROTECTED]&()_+'
/tmp$ ls
[EMAIL PROTECTED]&()[EMAIL PROTECTED]&()_+  nu.2360  t83c.0

...Maybe you need to escape some characters or use single-quotes (')?

--
Matthew
"Sorry. Wrong species." --ST-TNG


--
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\bin\sh.exe: *** fatal error - couldn't allocate heap, Win32 error 487

[mwoehlke]

Mark Bartel wrote:

Is anybody working on this?


I would quote some relevant context as to what "this" is, but not only 
do you like http://cygwin.com/acronyms/#TOFU and don't use correct 
quoting style, but you seem to have snipped all usable context as well.


You might try http://www.mozilla.com/thunderbird/; I believe its default 
configuration is more friendly. If you can't (or don't want to) use it 
with your e-mail, you can always use news://news.gmane.org and use TB 
only as a newsreader.



It isn't just me, as I've had another person ask me about it in private
email (also on a Thinkpad, an R52 in his case, btw).


Nope, it isn't just you. I've seen a similar error - often if I try to 
ctrl-C things - but it hasn't caused me enough problems (none, really) 
to complain about it.


--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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: Unable to delete directory in Cygwin

[mwoehlke]

Eric Blake wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Gina Verlekar on 6/15/2006 3:53 AM:

Hi,

I have implemented some changes in the linker code for some intermediate
processing. For that I need to create a temporary directory, generate
some intermediate  in it, process those files by calling a function.
After processing of the intermediate files, I delete the intermediate
files and the temporary directory.  
While this logic works fine in the linux, the temporary directory does
not get deleted in cygwin.


Windows is not Linux, and will not allow users to delete in-use
directories (where a directory is considered in-use if it contains files,
or if any process is using that directory as its current working
directory), nor the clean deletion of files that are still open.  POSIX
allows this behavior, and cygwin cannot change Window's implementation of
deletion semantics.  Just because Linux behaves nicer doesn't mean that it
is portable to remove in-use directories.  Fix your code to first close
all outstanding file handles before trying to remove the files, and then
the directory.

That said, cygwin does try to emulate linux, and if someone were to
contribute a patch that would allow cygwin to emulate directory deletion
if it knows that all open handles have also been scheduled for unlinking
at process end, then http://cygwin.com/acronyms/#PTC.


Not a patch, but for the record, it looks like Interix solves this 
problem (http://www.interopsystems.com/tools/tm.aspx?m=9403). Maybe 
Cygwin could do something similar?


(And in case that link dies; apparently Interix has a special 'temp' 
directory where "unlinked" files are sent until their handles are all 
closed.)


--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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: Unable to delete directory in Cygwin

[mwoehlke]

Larry Hall (Cygwin) wrote:

mwoehlke wrote:

Eric Blake wrote:

That said, cygwin does try to emulate linux, and if someone were to
contribute a patch that would allow cygwin to emulate directory deletion
if it knows that all open handles have also been scheduled for unlinking
at process end, then http://cygwin.com/acronyms/#PTC.


Not a patch, but for the record, it looks like Interix solves this 
problem (http://www.interopsystems.com/tools/tm.aspx?m=9403). Maybe 
Cygwin could do something similar?


(And in case that link dies; apparently Interix has a special 'temp' 
directory where "unlinked" files are sent until their handles are all 
closed.)


If you take a look at the cygwin sources, you'll see that Cygwin does
something similar already.  This does not solve the problem for those
that want to unlink and immediately recreate the unlinked entry though...


I'm confused. As I read the post, if I create a file 'bar' in '/foo', 
open the file, and then 'rm -rf /foo', I can't do that. If Cygwin 
"magically redirects" 'bar' to some special place, wouldn't that

a: allow me to unlink '/foo'
b: allow me to then create a new (and different) '/foo/bar'?

I also do not see anywhere that the OP is even trying to do [b].

--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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/

How to debug stuck bash?

[mwoehlke]

I have no idea how to approach this. I am seeing a problem where bash 
occasionally hangs. If I try to attach with gdb, gdb hangs. I can attach 
with Visual Studio, which claims that there is a deadlock, and shows the 
current call at least a half dozen calls deep into ntdll.


Does anyone have any ideas how I might go about investigating this?

--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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: loop through folders

[mwoehlke]

smanna wrote:

Hello I am trying to write a script. This is the thing, I want to loop
through all folders in a certain folder and send all files in these folders
to a java program. The files are somewhere in the neighbourhood of 170.000.
the setup is:
Home
cygwin.sh program.javaFolder
  folder
folder  ...
  folder   folder  ...   
folder   folder  ...
  files  files...
files  files...


help would be completely fantastic!!


This is not a Cygwin question. However, 'find . | xargs ' 
might help you. Or 'for f in find . ; do  $f ; done'.


'man find' and 'man bash' will get you started.

--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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: Thread Injection + Cygwin problems

[mwoehlke]

Kaveh Goudarzi wrote:

Hi,

   I've written a program to detect the invocation of
processes and then inject them with a remote thread in
the hope of getting the cmdLine/cwd and environment
variables of the running process.

[snip]

   I'm not sure how to approach the problem so any advice
would be greatly appreciated.


There are known problems with thread injection and Cygwin. Are you using 
the latest cygwin.dll snapshot?


--
Matthew
...Ruthlessly beating Windows with a hammer until it looks like POSIX.


--
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: Thread Injection + Cygwin problems

[mwoehlke]

Christopher Faylor wrote:

On Mon, Jun 19, 2006 at 06:11:57PM -0500, mwoehlke wrote:

Kaveh Goudarzi wrote:

I've written a program to detect the invocation of processes and then
inject them with a remote thread in the hope of getting the cmdLine/cwd
and environment variables of the running process.

[snip]

I'm not sure how to approach the problem so any advice would be greatly
appreciated.

Is there an obvious reason why attempting to invoke cygwin calls such
as getenv() in an injected thread might result in crashes?  I've also
tried cygwin_internal(CW_SYNC_WINENV) with the same result.  I'm
running Windows XP and have tried the 20060614 snapshot with the same
result.

There are known problems with thread injection and Cygwin.  Are you
using the latest cygwin.dll snapshot?


He said he was running the latest version of the snapshot (I put back
the part that you snipped above).


Missed that; my apologies.

--
Matthew
The hippo made me do it! What? What do you mean you can't see the hippo?


--
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: snapshots: first resort, or last resort?

[mwoehlke]

Science Guy wrote:

In http://cygwin.com/ml/cygwin/2006-06/msg00434.html, Brian said "using the
latest snapshot should always be the first thing you try when encountering a
problem before reporting it to the list."

However, the instructions for installing snapshots at
http://cygwin.com/faq/faq-nochunks.html#faq.setup.snapshots say:  "First,
are you sure you want to do this? Snapshots are risky. They have not been
tested. Use them ONLY if there is a feature or bugfix that you need to try,
and you are willing to deal with any problems, or at the request of a Cygwin
developer."

For a non-expert, such as me, this dichotomy of views is perplexing.  This
is made all the more perplexing because there does not seem to be (I could
not find) a user-readable list of bugs that each snapshot fixes vis-a-vis
the latest release.  So how would a user know whether the "risky" step of
installing a snapshot will have any chance of fixing a particular bug?

-- Joe


You asked, "Should I be eager to try snapshots or nervous?", to which my 
answer is "yes". :-)


If you have a problem, you should try a snapshot. However, you should 
keep in mind that doing so means trying a potentially unstable setup. 
Therefore, when trying a snapshot, you should do as little as possible 
while using that snapshot. If it doesn't fix your problem, it is safest 
to go back to a stable version. If it does, *then* you have to decide if 
you want to use a setup that might be unstable (more so than usual), or 
if you can wait for an official release.


Of course, OSS is always in need of people willing to live on the edge; 
otherwise no testing (or at best, poor testing) happens and the releases 
aren't a whole lot better than the alphas.


--
Matthew
The hippo made me do it! What? What do you mean you can't see the hippo?


--
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: random "fork: Resource temporarily unavailable"

[mwoehlke]

Christopher Faylor wrote:

On Thu, Jun 22, 2006 at 01:47:46PM -0400, Charli Li wrote:

-Original Message-

From: Larry Hall (Cygwin)
Sent: Thursday, June 22, 2006 1:39 PM
To: [EMAIL PROTECTED]
Subject: Re: random "fork: Resource temporarily unavailable"


Wow.  How many times do we have to ask not to quote raw email addresses
in the body of the message?


Ok, since I know my last suggestion went over like a lead balloon, how 
about this? Any time the mailer daemon sees what looks like a raw e-mail 
address in a message, it checks it's "allowed senders" list. If you 
aren't on it, it quarantines your message and makes you add yourself by 
testifying (under oath, if we can manage that ;-)) that you have 
CYMTNQREAIYR'd. That way all the first-timers would at least get a big 
loud warning about what they're doing, and after that it would be 
transparent (only bug a given individual once).


Or we could just drop a hippo on everyone that breaks the rule. ;-)

--
Matthew
"The spiralling shape will make you go insane!" -- They Might Be Giants


--
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: snapshots: first resort, or last resort?

[mwoehlke]

Linda Walsh wrote a lot of stuff about how she wants more flavors and 
frequency of Cygwin releases...


...and as Igor said, . Care to volunteer?

--
Matthew
This line intentionally left blank.


--
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: XP64 problem

[mwoehlke]

skaller wrote:

Hi, I am having the following problem:

(a) I can build my system under Cygwin on Windows XP32/SP1 amd64
  (hostname rosella)

(b) exactly the same build processes generates a segfaulting binary
  on XP64 amd62x2 (hostname budgie)

cyginfo -s for budgie attached. AFAIK this is the very latest
cygwin stuff (ran cygsetup just before the test). Not sure about
the rosella build (dual boot with Linux with which I'm mailing)

The segfaulting program is a statically linked generated
C++ program.

Budgie cygwin is running under Wow64.


FWIW, I run Cygwin on Win2K3 R2 x64 with no problems. However, I mostly 
use Microsoft's 'cl' as the compiler for my own programs.


Did you try using a debugger (like gdb) to see *why* your program is 
SEGV'ing?


--
Matthew
Do not expose to extreme heat, cold, or open flame.


--
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 Understanding Path Issue

[mwoehlke]

Scott Purcell wrote:
I have "CLASSPATHS" and "PATHS" and some "HOME" directories set up. Eg: 
ANT_HOME value=C:/ant/bin


I assume you meant "CLASSPATH" and "PATH".

When I run ant from a "cmd" window all is good. It picks up the value 
and runs fine. But I do not want to use the "cmd" prompt, and would like 
to use cygwin. But when I issue ant I get the dreaded error:
Error: JAVA_HOME is not defined correctly. We cannot execute 
/cygdrive/c/jdk1.5.0_02/bin/java


I do not want to change all my HOME, PATH, values because some of the 
system software uses them as they are. Can I get around this? Is there 
where it makes sense to use a symbolic link?


Nope, symlinks will not help you (or at least, they probably won't).
If the program that looks at a particular environment variable is a 
Cygwin program, then the var should give a POSIX path. Otherwise it 
should give a Windows path. You should only have problems switching 
between the two if you have programs of both flavors looking at the same 
variable (other than PATH which Cygwin handles automagically).


Example: I assume you are using a non-Cygwin Java (I don't believe I 
have even heard of a Cygwin JVM, so that seems likely), therefore your 
JAVAHOME should be a Windows path, regardless of what shell (A cygwin 
*sh vs. Windows cmd) you are using.


Also see 'man cygpath'.

--
Matthew
This message will self destruct in ten centuries.


--
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: Access to Network Drive under ssh

[mwoehlke]

David Greene wrote:

I tried to do a manual mount with no success:

$ net use H: \\samba-drive\dag
H: has a remembered connection to \\samba-drive\dag. Do you
want to overwrite the remembered connection? (Y/N) [Y]:
No valid response was provided.

The strange thing here is that "net use" didn't even wait
for me to answer the question.


Yup, 'net' doesn't understand tty's (which is what you get with ssh). 
Basically, if 'net' needs to ask you anything, it won't work, and your 
only recourse is to complain to Microsoft.


Since you've let the cat out of the bag, my own problem is a little 
stranger. I can see my drives just fine, but for some reason I can't 
write to them (works fine from a 'at the glass' session). Worse, it only 
happens on my Win2K3 computer; my XP one, using almost the exact same 
setup otherwise, is fine.


Anyway, the way I generally get things... well, closer to working, is to 
create a service that calls 'bash -c ', and have 
the script issue a bunch of 'net use  ' commands and then exec 
sshd. That way you don't have to worry about connections being 
remembered, because they will always be created for you when sshd starts up.


--
Matthew
Do not expose to extreme heat, cold, or open flame.


--
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: Access to Network Drive under ssh

[mwoehlke]

David Greene wrote:

mwoehlke wrote:
Anyway, the way I generally get things... well, closer to working, is 
to create a service that calls 'bash -c ', and 
have the script issue a bunch of 'net use  ' commands and 
then exec sshd. That way you don't have to worry about connections 
being remembered, because they will always be created for you when 
sshd starts up.


That doesn't seem to work for me.  When I start the service (I called
it mysshd), I get this in mysshd.log:

No valid response was provided.
 \\samba-mendota\dag. Do you
want to overwrite the remembered connection? (Y/N) [Y]:

An ssh session looks no different than before as far as
network drives are concerned.


You need to first do:
net use /delete h:

...so that you don't get prompted

--
Matthew
Do not expose to extreme heat, cold, or open flame.


--
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: Access to Network Drive under ssh

[mwoehlke]

David Greene wrote:

mwoehlke wrote:

You need to first do:
net use /delete h:

...so that you don't get prompted


Now I get this, which is what happened before I started
sshd as dag.  Except I can still cd to //samba-drive/dag:

$ net use H: \\samba-drive\dag
System error 67 has occurred.

The network name cannot be found.


Are you on a 64-bit Windows by any chance?
If not, I won't be able to tell you why 'net' is being brain-dead, other 
than "hmm, it does that sometimes; good luck!".


--
Matthew
Do not expose to extreme heat, cold, or open flame.


--
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: rsync over ssh hang issue understood

[mwoehlke]

Darryl Miles wrote:
[snip]

 * The outstanding byte count needs to be protected by a mutex.


Are you familiar with the Interlocked* family of functions? Depending on 
what exactly you need to do with the value, a mutex may be unnecessary.


Fascinating discussion, but over my head without taking more time to 
understand it. :-)


--
Matthew
Do not expose to hippos. Doing so may void your warranty.


--
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: rsync over ssh hang issue understood

[mwoehlke]

Darryl Miles wrote:

mwoehlke wrote:

Darryl Miles wrote:
[snip]

 * The outstanding byte count needs to be protected by a mutex.


Are you familiar with the Interlocked* family of functions? Depending 
on what exactly you need to do with the value, a mutex may be 
unnecessary.


Do these function perform buslock prefixed increment/add with memory 
operand.   As per Linux kernel /usr/src/linux/include/asm-i386/atomic.h. 
 Its an atomic add operation that would be needed, but I dont think that 
will be the only thing that will need intra-thread protection.  The 
close() case flag setting might need to be involved too as well as other 
things, like we need serialization.


Um... probably? Did you try looking at them? There is an 
InterlockedExchangeAdd (I think that's the right name... anyway, you 
feed it a pointer and a constant, and you get back the previous value). 
At any rate, anything Linux can do in assembly, Windows can also do, 
also in assembly, with it's own __asm keyword. The syntax is a little 
different, but it's there, and for something as speed-sensitive as I 
would guess pipes are, this sort of optimization is probably a Good Thing.


Mostly, there is an Interlocked function that will save you from inline 
assembly of most assembly instructions that accept the 'lock' prefix.


Of course, if it can't be done without a mutex in assembly, then it 
can't be done without a mutex, and you remain the person (as opposed to 
me) that knows the answer to that question.


--
Matthew
Do not expose to hippos. Doing so may void your warranty.


--
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: cygwing list subscription

[mwoehlke]

Igor Peshansky wrote:

On Fri, 30 Jun 2006, Abdellatif Ezzouhairi wrote:

i'm currently doing simulations with ns-2 using cygwin,
and i need to subscribe to cygwin mailing list
how can i subscribe to this group !


Try , which is one link away from


Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple


HTH,
Igor


You can also check out gmane.org (group gmane.os.cygwin) if you would 
prefer an NTP interface to the list.


--
Matthew
Do not expose to hippos. Doing so may void your warranty.


--
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: Using du.exe to calculate disk usage on a Microsoft cluster server

[mwoehlke]

Will Beldman wrote:

Can anyone tell me under what circumstance the message
du: fts_read failed: Permission denied
would come up. I should be able to troubleshoot things from there if 
only I knew what that error message is really complaining about.


When all else fails, you can try reading the source code (WAEFRTSC? 
:-))... this *is* OSS, after all.


--
Matthew
Do not expose to extreme heat, cold, or open flame.


--
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: Problem with gcc

[mwoehlke]

Guenther Sohler posted a signature three times longer than his message:
Yike! Please use a MUCH shorter signature. Preferably one without 
unenforceable (and, according to Eric Blake and CGF, against ML policy) 
disclaimers, and you might want to reconsider feeding the spammers as well.


See http://sourceware.org/lists.html and 
http://cygwin.com/acronyms/#PCYMTNQREAIYR


--
Matthew
And now back to your regularly scheduled e-mail.


--
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: Accessing network drive with ssh

[mwoehlke]

David Greene wrote:

Corinna Vinschen wrote:

Searching the mailing list archives or looking into the FAQ would have
been of some help.


Rather than let this extremely unhelpful reply be the last word,
I'll relate my experience.  I'm sorry, but it's nearly impossible
to do web searches on this topic.  I know, I spent weeks doing them.

The FAQ has zero useful information about this particular issue.
It should definitely be added.  The FAQ itself sorely needs to
be reorganized.  Too many things are covered under too broad of
topics.  It's very hard to find answers to specific questions.


The problem is that there are so many permutations of the problem that 
what works for one person may or may not work for another. Case in 
point, ...



Basically, you will not be able to access network drives
via /cygdrive or DOS-style drive letters when in an ssh
session.  For some reason "net use" gets very confused in
an ssh environment and the drive mapping just doesn't work.


...I have no problems getting drive letter mapping to work on one 
computer, and the only issue on the other is that the drive is, for some 
reason, read-only.


If drives are publicly readable, what WFM is to issue a bunch of 'net 
use' commands in a script that starts sshd (i.e. my sshd service 
actually runs 'bash -c 

Re: Trouble with readline during make command

[mwoehlke]

Guillot Jeremie wrote:

Hi everyone

I have some troubles with readline library when I want to compile my
program. In my cpp file I have 


#include 


We would be more willing (and able) to help if you gave us some 
indication of what the problem is.



Problem reports: http://cygwin.com/problems.html


--
Matthew
Hey, buddy, if it's OT, TITTTL!


--
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: inetd error

[mwoehlke]

McGraw, Robert P. wrote:

Is there any know problem with running inetd on a Window2003 server?


Yup. Try reading Corrina's reply to your previous message.

--
Matthew
Warning: prolonged exposure to Cygwin may cause addiction.


--
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: inetd error

[mwoehlke]

Robert McGraw wrote:

mwoehlke  tibco.com> writes:

McGraw, Robert P. wrote:

Is there any know problem with running inetd on a Window2003 server?

Yup. Try reading Corrina's reply to your previous message.


Matthew,

At the time I did not realize that this post had anything to do with my previous
post.  Actually I had indicated that I had resolved my problem but Corrina's
post about w2k3 problem was exactly what I was looking for.


Right... as you've noticed, SYSTEM on W2k3 can't do a setuid()... 
technically that isn't an inetd problem, it's a problem experienced by 
some daemons that inetd manages (which was what you were experiencing).



I sent this post before I had a chance to log in an look at my previous post.


Ok... I was looking at the timestamps; you missed by about five hours 
(at least according to Thunderbird). :-)


--
Matthew
Warning: prolonged exposure to Cygwin may cause addiction.


--
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: Possible bug in pgrep (procps)

[mwoehlke]

Bengt-Arne Fjellner wrote:

pgrep from procps-3.2.6-1 when asking for an exact match with arguments seems to
demand an extra space after the argument.
See the following sequence.

No space after the f on the commandline
$ emacs f&
[1] 2072

without extra space
$ pgrep  -x -f "emacs f"

with extra space after f
$ pgrep  -x -f "emacs f "
2072

Bug or my misunderstanding ?


Sure sounds like a bug, unless 'grep "foo"' is no longer supposed to 
match the line "foo "... 'man pgrep' isn't very specific on how the 
pattern matching is supposed to work, so I would assume partial matches 
are expected to work (as they would in grep).


Interestingly enough, on my computer (cygwin 1-5-19.4, procps 3.2.6-1), 
I see the following:


$ sleep 1h&
[1] 2136
$ pgrep -f 'sleep 1h'
2136
$ pgrep -f 'sleep 1h '
2136
$ pgrep -f 'sleep 1h  '
$

(Same results using ""s instead of ''s.)
This also seems wrong; 'sleep 1h ' should not have matched anything IMO. 
It does seem like there is something fishy going on.


--
Matthew
Interix, Sphinterix. Cygwin apps don't crash. :-)


--
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: window command in bash

[mwoehlke]

Buchbinder, Barry (NIH/NIAID) [E] wrote:

Igor Peshansky wrote:

On Tue, 18 Jul 2006, Buchbinder, Barry (NIH/NIAID) [E] wrote:

Did you quote the path or escape the backslashes to protect the
backslashes from the shell interpreting them as escape characters?
E.g., AgBackup.exe /notext 'c:\Alligate\agbackupfiles'
or
AgBackup.exe /notext "c:\Alligate\agbackupfiles"

A minor correction: you still need to escape the backslashes when
using double quotes, so the right way is 


AgBackup.exe /notext "c:\\Alligate\\agbackupfiles"


Here's what bash does:

/c> echo  "c:\Alligate\agbackupfiles"
c:\Alligate\agbackupfiles

Maybe if one has a variable following the backslash:

/c> echo "xyz\$USER"
xyz$USER
/c> echo "xyz\\$USER"
xyz\BBuchbinder


I think the point is that "\\" is ALWAYS safe, whereas "\?" (where "?" 
is some character) may not be.


--
Matthew
Lions and tigers and ...penguins? We're being invaded!


--
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: When ssh'd in, cannot run MS compiler /Zi debug option.

[mwoehlke]

Mark Charney wrote:
I suspect I'm missing some "rights".  This is an issue for me 
on multiple machines running  Windows Server 2003 x64 or for 
32b WinXP.
 
When I try to compile using the debug-option (/Zi) to the 
Microsoft Visual Studio Pro 2005 compiler:

cl /Zi hello.cpp
it only works from within cygwin if I am on the console or 
remote desktop. If I ssh-in to the same machine, it fails with 
a error message:


 Fatal Error C1902: Program database manager mismatch; please 
 check your installation.


Compiling without /Zi works fine anywhere we try it. My best guess is 
that it has to do with some RPC rights required for the debug-symbol 
file (PDB) generation done by the mspdb80.dll . That DLL uses RPC to 
talk to the mspdbsrv.exe. 

Any ideas? Is this a problem because the compiler running as my via 
ssh doesn't have sufficient rights to talk RPC to the mspdbsrv.exe ?  


Actually, you might want to read 
.


This seems to be a problem with cl.exe, NOT Cygwin (and yes, I have the 
exact same problem). At the very least, Interix's SSH has the same 
issue. There is supposed to be a hotfix, the name of which is mentioned 
in another thread linked via the above thread, but you have to go 
through Microsoft support to get it :-(.


(If you do get it, I would really appreciate a copy :-).)

Alternatively, if you figure out how to fix this without the hotfix, I 
trust you will mention it here.


--
Matthew
Now where did I put my hippo?


--
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: Compiling euchre 0.7 n cygwin

[mwoehlke]

Laurent Duperval wrote:

Buster wrote:

This is not a Cygwin-specific problem. In
euchre-0.7/src/gui/Makefile.am, @GTK_LIBS@ should come at the end of
the list of libraries to link, instead of at the beginning. Further
questions (for example, about why 'make install' fails while trying to
invoke automake -- sorry, it's beyond me) should be directed to the
package maintainer.


Excellent! Changing the order of the libs fixed the problem.

I ended up having to change it directly in the Makefile instead of
Makefile.am (I probably could've done it in Makefile.in also).

The reason I thought it was a Cygwin issue is that the same code
compiles fine on Linux (except for a minor ifstream issue).


Right... Linux is forgiving about link order. Most platforms aren't.

--
Matthew
"We're all mad here. I'm mad. You're mad... You must be, or you wouldn't 
have come here." -- The Cheshire Cat



--
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: Compiling euchre 0.7 n cygwin

[mwoehlke]

TITTTLing

Dave Korn wrote:

On 20 July 2006 18:40, mwoehlke wrote:

Laurent Duperval wrote:

Buster wrote:

This is not a Cygwin-specific problem. In
euchre-0.7/src/gui/Makefile.am, @GTK_LIBS@ should come at the end of
the list of libraries to link, instead of at the beginning. Further
questions (for example, about why 'make install' fails while trying to
invoke automake -- sorry, it's beyond me) should be directed to the
package maintainer.

Excellent! Changing the order of the libs fixed the problem.

I ended up having to change it directly in the Makefile instead of
Makefile.am (I probably could've done it in Makefile.in also).

The reason I thought it was a Cygwin issue is that the same code
compiles fine on Linux (except for a minor ifstream issue).

Right... Linux is forgiving about link order. Most platforms aren't.


  Isn't it actually more to do with the fact that Linux tends to use shared
libs, and so if the link order is wrong you get an executable with unresolved
symbols in it, but then those unresolved symbols get resolved anyway at
runtime when the library is loaded by ld.so, whereas here on cygwin we tend to
use static link libs, even when we're linking against a .dll, and so don't get
the equivalent 'second chance' to resolve?


Well, sure, and the fact that the linker *gives* you that second chance. 
Most linkers will fail if there are unresolved symbols, so in that 
sense, Linux ld is more forgiving. The order issue is that if you 
specify the lib before the object, it doesn't know what to import from 
the lib (but I think it stills makes a note that that lib should be 
loaded, no?).


--
Matthew
"We're all mad here. I'm mad. You're mad... You must be, or you wouldn't 
have come here." -- The Cheshire Cat



--
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: When ssh'd in, cannot run MS compiler /Zi debug option.

[mwoehlke]

Mark Charney wrote:

mwoehlke  tibco.com> writes:
 Fatal Error C1902: Program database manager mismatch; please 
 check your installation.

...

Actually, you might want to read 
<http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=357051&SiteID=1>.


This seems to be a problem with cl.exe, NOT Cygwin (and yes, I have the 
exact same problem). At the very least, Interix's SSH has the same 
issue. There is supposed to be a hotfix, the name of which is mentioned 
in another thread linked via the above thread, but you have to go 
through Microsoft support to get it .


(If you do get it, I would really appreciate a copy .)


Thanks. Actually, I'm one of the posters on that thread that that thread links
to.


Ah, didn't check the names. :-)


 I received the hotfix Tuesday (and it does *not* work for me.  (Spent all
day on the phone!) I've got an open case w/ Microsoft and they don't really
understand the issue yet, as far as I can tell. Cygwin baffles them. Now that I
know that i need to add some rights to the sshd_server account for public key
auth, I think I might have a hope of getting help from MS, but not sure yet.


Ok, well please keep us updated; thanks!
(All the same, would you mind passing a copy of that hotfix this way? 
Maybe I'll get lucky...)



Using password authentication does work, and is a sufficent workaround. I'm
still trying to figure out what  Corinna was referring to with this:

add the user account sshd_server resp. SYSTEM to
the list of users which can access the "Program database", whatever
that is.


Right... I didn't quite understand that either, although it sounds like 
Corinna making a WAG about the pdb program (I'm not reassured by 
"whatever that is" :-)). Possibly MS would be more helpful here. 
Although given how unclear the original suggestion was, it's probably 
correct ;-).


For those fortunate enough to be uneducated (i.e. fortunate enough to 
not have to use MS compilers): A "program database" is a .pdb file 
generated alongside a .exe that contains the debugging information (line 
numbers and such). MS, in their "infinite wisdom" decided there should 
be a completely separate tool to generate the critter, which seems to be 
problematic at best. Of course, these are the same folks that built 
identically-named, completely *separate* compilers for 32-bit and 
64-bit. No nice '-m32'/'-m64' flags here!


So, the problem is that something about the pdb tool breaks when using 
password-less login under ssh (whether or not it's Cygwin ssh).


Anyway, my workaround has just been to not use ssh for now.

--
Matthew
"We're all mad here. I'm mad. You're mad... You must be, or you wouldn't 
have come here." -- The Cheshire Cat



--
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: Why are Windows paths broken in make 3.81?

[mwoehlke]

Michael Hirsch wrote:

Here is a sample Makefile that breaks with Gnu Make 3.81-1 under
Cygwin, but works fine with Gnu Make 3.80-1.  We have been writing
these types of Makefiles for years, using both Windows and Cygwin
tools, and this is the first time Make has ever broken like this.

I see in another thread that this is a known issue, though I don't see
it in the changelogs for make 3.81.

Was this a deliberate break with backwards compatibility?  It means
that every single reference to a windows path needs to be wrapped in
cygpath, which is a huge inconvenience.


Yes. See . 
If you are using a POSIX-like "OS" (i.e. Cygwin), you should be using 
POSIX paths. That's not an inconvenience, that's called writing a bad 
makefile. If you aren't using Cygwin for the POSIX environment, you 
should be using MinGW.



Is it broken only on Windows?


That sounds like a silly question... 'are Windows paths only broken on 
Windows?'



Is this a cywin only bug?  What possible reason could there be to
introduce this deliberately?


No, as it is not a "bug". However it is specific to Cygwin. See the 
aforementioned announcement. CGF would have to speak to "why" (and I 
would appreciate if he would, just because I am curious :-)), but I 
would guess it is to "encourage" people to use correct (i.e. POSIX) paths.


--
Matthew
Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir


--
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: Why are Windows paths broken in make 3.81?

[mwoehlke]

Joachim Achtzehnter wrote:

Christopher Faylor wrote:

On Fri, Jul 21, 2006 at 06:03:43PM -0700, Joachim Achtzehnter wrote:
My second post was specifically in response to the claim by mwoehlke 
suggesting that the changes were "not an inconvenience". In this post 
all the issues I mentioned were intended as illustrations of such 
inconveniences, so there was even less implied expectation of somebody 
acting on these. Note, that I wrote that I had already addressed the 
issues caused by deliberate incompatibilities, all I intended to do was 
point out that it *had been* inconvenient.


For the record, I was just trying to point out that the general 
consensus around here seems to be 'don't use DOS paths in Cygwin', and 
was using that to explain what I feel to be one major reason for the 
change. I accept and acknowledge that this change may be inconvenient 
for some people, but it is also my opinion that if you are affected by 
it, you are doing something that was never condoned or officially 
supported in the first place. (And, after all, WJM. ;-))


I am glad you got things working and (I assume, since you say things are 
working) looking POSIX-like.


Personally, every time I see mention of someone using DOS paths in 
Cygwin, or a Cygwin program, I wonder to myself why this works at all :-).


--
Matthew
Warning: This message has not been approved by the FDA.


--
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: Where is complex.h

[mwoehlke]

TV JOE wrote:
 I've a C program referencing complex.h. But make can't find it 
 and the only copy I see is in /usr/include/mingw which I don't

 think is the right version.  Advice welcomed.


No, probably not...

http://cygwin.com/cgi-bin2/package-grep.cgi?grep=/complex.h suggests 
there is one in the Cygwin core source, and one in 'backward' in the GCC 
package, which sounds suspicious (as in, implies that this header is 
deprecated?). I'm just guessing. At any rate, the above link clearly 
shows you a full path where one might/should be located, though it 
doesn't indicate if the "complex.h" is the one you're looking for.


--
Matthew
Warning: This message has not been approved by the FDA.


--
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: Where is complex.h

[mwoehlke]

Christopher Faylor wrote:

On Mon, Jul 24, 2006 at 05:00:37PM -0400, Larry Hall (Cygwin) wrote:

TV JOE wrote:

I've a C program referencing complex.h.  But make can't find it and the
only copy I see is in /usr/include/mingw which I don't think is the
right version.  Advice welcomed.

Try:


That will tell you what packages have complex.h in them.  I expect you
can reasonably narrow down from there the package you need and how to
get at the file you want.


I don't think that there is any cygwin package which provides a usable
complex.h is there?  I don't see one from the above list and, if one was
going to exist, it should come from newlib -- which doesn't seem to be
the case.


I did find these:
(cygwin-1.5.21-1)
cygwin-1.5.21-1/newlib/libc/sys/linux/include/complex.h
(gcc-g++-3.4.4-2)
usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward/complex.h
usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/complex

Now that I noticed the third one, the second one makes sense; it is 
probably a wrapper complaining that you should '#include '. 
However those are C++ headers, not C headers.


The first one does have "newlib" in the path, for whatever that's worth.

--
Matthew
Warning: This message has not been approved by the FDA.


--
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/