Thanks for all of the responses from everyone.
> If you need to do interactive debugging, run it under cmd or with cygstart.
[Bill Smith] it seems that an ok workaround is for me to use cygstart to start
a command prompt within a Cygwin shell and then in the command prompt, run the
prog
> > Sorry for the lack of info. This is a Windows native console application.
> Here's the source code:
> >
> > #include
> >
> A "console application" doesn't require windows.h but this isn't the issue.
[Bill Smith]
Not sure that I unders
> On 2016-10-13 08:35, Bill Smith wrote:
> > I'm trying to run my Windows C++ application which has a call to
> > DebugBreak() to bring up the popup asking if you want to debug this
> > application or terminate it. If I run the program within Cygwin, the
> > prog
Hi,
I'm trying to run my Windows C++ application which has a call to DebugBreak()
to bring up the popup asking if you want to debug this application or terminate
it. If I run the program within Cygwin, the program just exits.
If I run the application from a Windows command prompt, I get the Wi
tion "file-not-found"
> handler, if you so desire.
[Bill Smith]
A couple of years ago I was involved with porting a very large code base of
makefiles
& shell scripts to work with Cygwin. In our environment, the main issue was
shell scripts calling
*.bat files without the .
Warren Young-2 wrote
> On May 24, 2016, at 6:43 AM, Benjamin Cao <
> becao@
> > wrote:
>>
>> The executable, when run with nm in Cygwin, results in a "no symbols"
>> result, whereas it generates a symbol table in unix.
>
> That’s not what I see here. Given hello.c containing a “Hello, world!”
> $ git add C:\\test\\file <-- this fails despite exit code 0
[Bill Smith]
Does it work if you do:
git add c:/test/file
We use the mixed mode paths extensively with Cygwin in our environment and it
works well. We have the issue of having to work with non-Cygwin aware W
In my particular case, we're seeing this behavior:
7-mode: (//devnas04/largedisk/bsmith/netapp)
:$ //devnas04/largedisk/bsmith/netapp>time ls -ld struct5*
-rw-r--r-- 1 bsmith Domain Users 0 Nov 5 10:25 struct51.log
[snipped]
-rw-r--r-- 1 bsmith Domain Users 0 Nov 5 10:26 struct5z.prf
real0
Hi Achim,
I'm also having this issue but my investigation has found it to be a behavior
specific to C-DOT. This doesn't happen with 7mode. I currently have a support
case open with NetApp to get to the bottom of this behavior. It could be a
Cygwin bug.
> -Original Message-
> From: cy
[Oops, apologies if I messed up the threading as I wasn't subscribed to the
list and noticed there were some replies.]
On 12/29/2015 04:07 PM, Roger Wells wrote:
> a bit more:
> windows 10, mintty, works as hoped.
> windows 10, bash, observe what the OP reported originally
Yes, I'm trying to do
Hi,
I have observed that CTRL-C does not work when using pipes in Cygwin. Is this
a bug? Or is there an issue with my stty settings?
If I do this:
perl -e 'while(1) {sleep 1;}'
CTRL-C works
If I do:
echo foo | perl -e 'while(1) {sleep 1;}'
CTRL-C does not work. I have to use Task Mana
etup.log produced by (setup.exe 2.194.2.15) is attached.
Thank you.
Sincerely,
Bill Smith
[EMAIL PROTECTED]
setup.log.full
Description: Binary data
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation:
12 matches
Mail list logo
