Hello All
I am pretty sure I have found a bug with the NFS module. I
have checked the mailing list, web searches, and whatever else is out
there. I think this problem is unique. I just want to inform the
Cygwin Community so you are all aware.
The remote windows machine has a USB d
> I am going to present the seminar on Cygwin in my organization.In that
> seminar I want to show you can access windows shared folder of any PC
> from Cygwin. To demonstrate that I have tried to mount that windows
> shared folder in cygwin but it didn't work. When I have searched in
> google for i
Neeraj Sahu wrote:
> Hi All,
>
> I am new to the cygwin mailing list. This is my first email to the
> community. I am going to present the seminar on Cygwin in my
> organization.In that seminar I want to show you can access windows
> shared folder of any PC from Cygwin. To demonstrate that I have
Hi All,
I am new to the cygwin mailing list. This is my first email to the community.
I am going to present the seminar on Cygwin in my organization.In that
seminar I want to show you can access windows shared folder of any PC
from Cygwin. To demonstrate that I have tried to mount that windows
sha
I am able to repro this every time:
1. Launch a Windows Server 2003 x64 image (I used ami-dc4daab5) on a high
compute x-large (c1.xlarge) instance of EC2.
2. Install the default cygwin
3. Open up a bash shell
4. Type 'if [ "1" == "1" ]; then echo hello; fi'
5. Watch bash crash
I looked through
On Mon, May 11, 2009 at 02:52:27AM +0200, Piotr Wyderski wrote:
>Christopher Faylor wrote:
>
>>?This isn't a bug in Cygwin.
>
>I've never made a statement that it is.
And I never claimed that you made a statement that it is so I guess
everything is hunky dory.
>It's just an unexpected and undesir
Piotr Wyderski wrote:
> I don't know the reason, just report the program's
> behaviour. But to provide you more context: this
> code is a critical error handler. All it has to do is:
>
> 1. immediately stop the world in a nice way,
> as this thread is all about. When "sig" is suspended,
> no more
Christopher Faylor wrote:
> This isn't a bug in Cygwin.
I've never made a statement that it is. It's just
an unexpected and undesired behaviour I wanted
to get rid of. The context was there to make it
clear what exactly is happening on that particular
control flow path.
> Your takeaway from this
On Mon, May 11, 2009 at 02:07:51AM +0200, Piotr Wyderski wrote:
>Christopher Faylor wrote:
>>Yes, that's the signal thread but I don't know why stopping it would
>>cause any special problems since, if the entire program is stopped, it
>>isn't going to be processing signals.
>
>I don't know the reas
Dave Korn wrote:
> Is there a POSIX way of doing what you want?
I don't think so. This particular module contains
so much concentration of low-level magic (GetThreadSelectorEntry + manual NT_TIB
access in Garry Nebbett's style, to name some
techniques) to extract as accurate machine
state descri
Christopher Faylor wrote:
> Yes, that's the signal thread but I don't know why stopping it would
> cause any special problems since, if the entire program is stopped, it
> isn't going to be processing signals.
I don't know the reason, just report the program's
behaviour. But to provide you more c
On Mon, May 11, 2009 at 12:33:07AM +0200, Piotr Wyderski wrote:
>Christopher Faylor wrote:
>>The closest API to it would be a call to
>>cygwin_internal(CW_GETTHREADNAME, );
>
>Now it works like a charm. The internal thread which suspension leads
>to program hangup is named "sig".
Yes, that's the
Andrew DeFaria wrote:
>> So to recap: I'd like to provide pre-shared key ssh access to a
>> particular username. I cannot, however, use an SMB shared home directory
>> for that user without encountering problems with ssh and permissions.
>>
>> If the above statement is not true and you have any id
Piotr Wyderski wrote:
> Christopher Faylor wrote:
>
>> The closest API to it would be a call to
>> cygwin_internal(CW_GETTHREADNAME, );
>
> Now it works like a charm. The internal thread
> which suspension leads to program hangup
> is named "sig".
This is the signal-listener thread that all cy
David Billinghurst wrote:
> I have a problem with cygwin gfortran 4.3.2 20080827 on cygwin-1.7. Text
> written to stdout (unit 6) is lost when redirected. The problem goes
> away if I add a "close(6)" statement, so the buffer may not be flushed
> properly.
>
> I don't see the problem with vanill
Christopher Faylor wrote:
> The closest API to it would be a call to
> cygwin_internal(CW_GETTHREADNAME, );
Now it works like a charm. The internal thread
which suspension leads to program hangup
is named "sig".
> This is an as-is undocumented interface and we make no guarantees that its
> beha
On Sun, May 10, 2009 at 06:53:21PM +, Mark Geisert wrote:
>So it looks like your original question could be restated as "Is there
>an API in Cygwin that allows an application to enumerate all Cygwin
>threads in the app, including internal Cygwin threads?". I don't know
>of any but maybe somebo
Piotr Wyderski writes:
> > Why assume Cygwin could be the only source of extra threads?
>
> There is no such assumption. But Cygwin is the only
> source of threads that can stop the program entirely,
> so they must be treated in an exceptional way.
Well, I guess you must be aware of *all* sources
Andrew DeFaria wrote:
> I've found that in life if you don't completely solve a problem you tend
> to come back upon it until you do. Dredging up an old issue
> (http://sourceware.org/ml/cygwin/2006-10/msg00553.html) of which Corinna
> commented here: http://sourceware.org/ml/cygwin/2006-10/msg00
I have a problem with cygwin gfortran 4.3.2 20080827 on cygwin-1.7.
Text written to stdout (unit 6) is lost when redirected. The problem
goes away if I add a "close(6)" statement, so the buffer may not be
flushed properly.
I don't see the problem with vanilla gcc-4.4.0 or gcc-trunk, compiled
Corinna Vinschen wrote:
Cygwin is a POSIX environment. The ACLs are set according to POSIX
rules, not according to Win32 rules.
Thanks I'm not criticising Cywin's ACL behaviour just looking for
guidance on anyone who has used 1.7 with existing Windows applications.
In my case I wish to use
Mark Geisert wrote:
> Why assume Cygwin could be the only source of extra threads?
There is no such assumption. But Cygwin is the only
source of threads that can stop the program entirely,
so they must be treated in an exceptional way.
> Wouldn't it make more sense to have your program remember
The file
56032 2007-06-01 07:28 etc/defaults/etc/profile.d/complete.tcsh
in package release/tcsh/tcsh-6.15.00-4.tar.bz2
is missing proper quoting for shell variable expansion, resulting in
errors if $HOME contains spaces in the path - sure bet for cygwin!
The attached patch fixes the problem.
23 matches
Mail list logo
