Re: Strange behavior when executing programs

On Dec 14 06:38, Frank Redeker via Cygwin wrote: > > > Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: > > On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: > > > On Dec 12 13:46, Frank Redeker via Cygwin wrote: > > > > Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > > > > > On Dec 12

Re: Strange behavior when executing programs

Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: On Dec 12 13:46, Frank Redeker via Cygwin wrote: Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: On Dec 12 11:21, Frank Redeker via Cygwin wrote: $ pwd /cygdrive/s/ado $ realpath /cy

Re: Strange behavior when executing programs

On 2022-12-13 18:54, Jon Turney via Cygwin wrote: On 13/12/2022 16:35, Frank Redeker via Cygwin wrote: I tried to install in fresh VM without success. (No AV installed and the Windows Firewall is off) [...] 2022/12/13 17:04:55 net: Direct Cached mirror list unavailable User-Agent: default i

Re: Strange behavior when executing programs

On 13/12/2022 16:35, Frank Redeker via Cygwin wrote: I tried to install in fresh VM without success. (No AV installed and the Windows Firewall is off) [...] 2022/12/13 17:04:55 net: Direct Cached mirror list unavailable User-Agent: default is "Cygwin-Setup/2.924 (Windows NT 10.0.18362;Win64

Re: Strange behavior when executing programs

Am 12/13/2022 um 3:15 PM schrieb Corinna Vinschen: On Dec 13 13:54, Frank Redeker via Cygwin wrote: Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: On Dec 12 13:46, Frank Redeker via Cygwin wrote: Am 12/12/2022 um 1:12 PM schrieb Corin

Re: Strange behavior when executing programs

On Dec 13 13:54, Frank Redeker via Cygwin wrote: > > > Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: > > On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: > > > On Dec 12 13:46, Frank Redeker via Cygwin wrote: > > > > Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > > > > > On Dec 12

Re: Strange behavior when executing programs

Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: On Dec 12 13:46, Frank Redeker via Cygwin wrote: Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: On Dec 12 11:21, Frank Redeker via Cygwin wrote: $ pwd /cygdrive/s/ado $ realpath /cy

Re: Strange behavior when executing programs

On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: > On Dec 12 13:46, Frank Redeker via Cygwin wrote: > > Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > > > On Dec 12 11:21, Frank Redeker via Cygwin wrote: > > > > $ pwd > > > > /cygdrive/s/ado > > > > > > > > $ realpath /cygdrive/s/ado/msad

Re: [EXTERNAL] Re: Strange behavior when executing programs

Am 12/12/2022 um 4:41 PM schrieb Corinna Vinschen via Cygwin: On Dec 12 15:22, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: Sorry about the earlier typos (and, hence, I suppose for the purposes of the OP). and, hence, I suppose, *would work* for the purposes of the OP. Since r

Re: [EXTERNAL] Re: Strange behavior when executing programs

On Dec 12 16:42, Corinna Vinschen via Cygwin wrote: > On Dec 12 15:29, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > > The problem is that resolved paths may become longer than MAX_PATH. > > > > Oh... But that'd be the same on any other OS that exceeds MAX_PATH, > > symlinking is go

Re: [EXTERNAL] Re: Strange behavior when executing programs

On Dec 12 15:29, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > The problem is that resolved paths may become longer than MAX_PATH. > > Oh... But that'd be the same on any other OS that exceeds MAX_PATH, > symlinking is going to help work around that, > if the full path resolution wa

Re: [EXTERNAL] Re: Strange behavior when executing programs

On Dec 12 15:22, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > Sorry about the earlier typos > > > (and, hence, I suppose for the purposes of the OP). > > and, hence, I suppose, *would work* for the purposes of the OP. > > > Since realpath is supposed to resolve all symlinks, > > I m

RE: [EXTERNAL] Re: Strange behavior when executing programs

Was supposed to be: > symlinking is *NOT* going to help work around that Sorry I am struggling with MS Outlook this morning Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:ht

RE: [EXTERNAL] Re: Strange behavior when executing programs

> The problem is that resolved paths may become longer than MAX_PATH. Oh... But that'd be the same on any other OS that exceeds MAX_PATH, symlinking is going to help work around that, if the full path resolution was requested. BTW, about MAX_PATH -- was it Cygwin's or Windows'? If the former,

RE: [EXTERNAL] Re: Strange behavior when executing programs

corect. Anton Lavrentiev Contractor NIH/NLM/NCBI > -Original Message- > From: Cygwin On Behalf Of > Lavrentiev, > Anton (NIH/NLM/NCBI) [C] via Cygwin > Sent: Monday, December 12, 2022 9:53 AM > To: cygwin@cygwin.com; Frank Redeker > Cc: Corinna Vinschen > Subje

Re: [EXTERNAL] Re: Strange behavior when executing programs

On Dec 12 14:52, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > Let's consider this problem again, but I don't see a quick and easy > > solution. > > $ realpath /cygdrive/s/ado/msadox.dll > /cygdrive/s/ado/msadox.dll<== IMO the problem is actually here > > $ realpath m

RE: [EXTERNAL] Re: Strange behavior when executing programs

> Let's consider this problem again, but I don't see a quick and easy > solution. $ realpath /cygdrive/s/ado/msadox.dll /cygdrive/s/ado/msadox.dll<== IMO the problem is actually here $ realpath msadox.dll /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll Both paths sho

Re: Strange behavior when executing programs

On Dec 12 13:46, Frank Redeker via Cygwin wrote: > Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > > On Dec 12 11:21, Frank Redeker via Cygwin wrote: > > > $ pwd > > > /cygdrive/s/ado > > > > > > $ realpath /cygdrive/s/ado/msadox.dll > > > /cygdrive/s/ado/msadox.dll > > > > > > $ realpath ms

Re: Strange behavior when executing programs

Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: On Dec 12 11:21, Frank Redeker via Cygwin wrote: $ pwd /cygdrive/s/ado $ realpath /cygdrive/s/ado/msadox.dll /cygdrive/s/ado/msadox.dll $ realpath msadox.dll /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll Is there any way to re

Re: Strange behavior when executing programs

On Dec 12 11:21, Frank Redeker via Cygwin wrote: > $ pwd > /cygdrive/s/ado > > $ realpath /cygdrive/s/ado/msadox.dll > /cygdrive/s/ado/msadox.dll > > $ realpath msadox.dll > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > > Is there any way to restore the old behavior. Since wi

Re: Strange behavior of Python Package Index

> I have selected python38-tkinter package for the Cygwin setup. > Tkinter is available when I start python3.8, but when I try to check list of > packages installed with pip3.8, > tkinter is not listed. > It seems that all packages selected from Cygwin setup are missing. > Only packages installe

Re: Strange behavior of Python Package Index

In fact, I have tried with Python 3.6 and Python 3.7 with the same result. It seems path where python modules are stored is different from path used by pip installer. The problem is in that case that command 'pip3.x list' provides a wrong overview of real python packages installed. There is pr

Re: Strange behavior of Python Package Index

Am 06.01.2020 um 15:23 schrieb Kptain: Hi, Something is strange with Python Package Index (PIP): I have selected python38-tkinter package for the Cygwin setup. Tkinter is available when I start python3.8, but when I try to check list of packages installed with pip3.8, tkinter is not li

Re: Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.

On 26.07.2016 22:19, Kaz Kylheku wrote: The test program featured below works fine under the Cygwin console window. If executed from a cmd.exe console, strange things happen with the cmd.exe window. Suddenly, the window spontaneously resizes so that is taller than the desktop. A horizontal scrol

Re: strange behavior with threads...

On Fri, Jul 24, 2009 at 8:43 PM, benadam777 wrote: > > > > jean-luc malet wrote: >> >> I have a X server connection issue >> >> freeglut (./tests/GENERATED/GlutWindowTest): Unable to create direct >> context rendering for window ' ' >> This may hurt performance. >> XIO:  fatal IO error 11 (Resource

Re: strange behavior with threads...

jean-luc malet wrote: > > I have a X server connection issue > > freeglut (./tests/GENERATED/GlutWindowTest): Unable to create direct > context rendering for window ' ' > This may hurt performance. > XIO: fatal IO error 11 (Resource temporarily unavailable) on X server > ":0.0" > after

Re: strange behavior with threads...

On Thu, Jul 23, 2009 at 4:11 PM, Corinna Vinschen wrote: > On Jul 23 15:50, jean-luc malet wrote: >> Hi! >> I've the following code : >> void _Window::Start(void* arg) >> { >>         ThreadArgs args; >>         args.TheWindow=this; >>         args.args=arg; >>         int err = pthread_create(&mai

Re: strange behavior with threads...

On Jul 23 15:50, jean-luc malet wrote: > Hi! > I've the following code : > void _Window::Start(void* arg) > { > ThreadArgs args; > args.TheWindow=this; > args.args=arg; > int err = pthread_create(&main_thread,NULL,_Start, (void*)&args); > if (err) > {

Re: strange behavior with threads...

jean-luc malet wrote: > Hi! > I've the following code : > void _Window::Start(void* arg) > { > ThreadArgs args; This allocates a ThreadArgs struct on the stack. > int err = pthread_create(&main_thread,NULL,_Start, (void*)&args); This passes a pointer to the ThreadArgs struct

Re: Strange behavior of cygwin setup preferences

Lenik wrote: When I have a fresh new installed OS, say XP, and the first time to install cygwin using cygwin setup utility, I can see a lot of components. After the first installation, however it's completed installed or be canceled, Then I launch the setup again, most components are gone. I

Re: strange behavior with perl v 5.8.8

On 9/27/07, Brian Mathis wrote: > On 9/27/07, Andrew Louie wrote: > > Hello, > > > > I've run into a strange adding problem with perl: > > > > when incrementing by 0.1 i get a strange behavior where at some > > arbitrary number, it will append 0.99 to the end of the > > number. > > > > T

Re: strange behavior with perl v 5.8.8

On 9/27/07, Andrew Louie <[EMAIL PROTECTED]> wrote: > Hello, > > I've run into a strange adding problem with perl: > > when incrementing by 0.1 i get a strange behavior where at some > arbitrary number, it will append 0.99 to the end of the > number. > There's an excellent explanation of

Re: strange behavior with perl v 5.8.8

--On Thursday, September 27, 2007 11:14:09 AM -0400 Andrew Louie wrote: when incrementing by 0.1 i get a strange behavior where at some arbitrary number, it will append 0.99 to the end of the number. This is rounding error and applies to all computer systems and all programming langu

Re: strange behavior with perl v 5.8.8

Andrew Louie wrote: Hello, I've run into a strange adding problem with perl: when incrementing by 0.1 i get a strange behavior where at some arbitrary number, it will append 0.99 to the end of the number. test case: -

RE: strange behavior with perl v 5.8.8

On 27 September 2007 16:14, Andrew Louie wrote: > Hello, > > I've run into a strange adding problem with perl: > > when incrementing by 0.1 ... an infinite, non-repeating fraction in binary floating-point, that can only be inexactly approximated ... > i get a strange behavior where at some >

Re: strange behavior with perl v 5.8.8

Nope, not a Cygwin specific issue. I get the same behavior at the same point on Gentoo perl 5.8.8 (x86 dual-Xeon), Debian Etch perl 5.8.8 (x86 P4), and SunOS 5.10 perl 5.8.4. William Sutton On Thu, 27 Sep 2007, Andrew Louie wrote: Hello, I've run into a strange adding problem with perl:

Re: strange behavior of bash

On Wed, Sep 21, 2005 at 06:52:08AM -0600, Eric Blake wrote: > I'm not familiar with DOS promote. Is it some other vendor's shell? Does > it provide its own bash in your home directory, which could explain why > you get a different behavior depending on what directory you are in when > you try to

Re: strange behavior of bash

Thank you very much all for your replies. I think I should clarify somthing first. Windows has two places to set path parameters "Local Machine" and "User environment", what I changed is "local machine" one which means it affects anyone use this pc. 1. I do have /cygwin/bin in my "User environment

RE: strange behavior of bash

Original Message >From: faif cn >Sent: 21 September 2005 10:04 > Thank you Dave > > On 9/20/05, Dave Korn wrote: >>> >>> I deleted some values in Windows Local Environment variable "PATH". >>> My original "HOME" is c:/home/myname/. And then: >> >> it broke. So put them back! >

Re: strange behavior of bash

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 9/21/2005 7:14 AM: >>Your cygcheck was hard to read, as it was not a plain-text attachment >>(hmm, maybe we could update the problem-reporting instructions to tell >>people to create cygcheck.txt instead of cygcheck.o

Re: strange behavior of bash

On Wed, Sep 21, 2005 at 06:52:08AM -0600, Eric Blake wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >According to faif cn on 9/21/2005 3:04 AM: >> >> What I deleted is "borland c" bin directory to avoid cygwin confusing >> two "make" tools. and maybe some other PATH variables which I bel

Re: strange behavior of bash

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to faif cn on 9/21/2005 3:04 AM: > > What I deleted is "borland c" bin directory to avoid cygwin confusing > two "make" tools. and maybe some other PATH variables which I believe > set by some outdated software. It left as Your cygcheck was

Re: strange behavior of bash

At 05:04 AM 9/21/2005, you wrote: >Thank you Dave > >On 9/20/05, Dave Korn korn artimi com> wrote: > ^^^ This is important if you want people to reply to you. >> > I deleted some values in

Re: strange behavior of bash

Thank you Dave On 9/20/05, Dave Korn <[EMAIL PROTECTED]> wrote: > > > > I deleted some values in Windows Local Environment variable "PATH". > > My original "HOME" is c:/home/myname/. And then: > > it broke. So put them back! What I deleted is "borland c" bin directory to avoid cygwin co

RE: strange behavior of bash

Original Message >From: faif cn >Sent: 20 September 2005 17:26 > Hello all, > > I deleted some values in Windows Local Environment variable "PATH". > My original "HOME" is c:/home/myname/. And then: it broke. So put them back! If that doesn't fix it, -> http://cygwin.com/prob

Re: strange behavior of cygpath

Hello, Igor. > On Tue, 21 Jan 2003 23:35:01 -0500 (EST) > [EMAIL PROTECTED](Igor Pechtchanski) said: > Let me make sure I understand what you're trying to do: > You're trying to translate a *Windows* path to a Windows path using > cygpath? I use cygpath in shell scripts. The arguments o

Re: strange behavior of cygpath

On Wed, 22 Jan 2003, Kenji Yamashita wrote: > Hello, > > I found that the behavior of cygpath was strange. > > kenji@ibm[88] cygcheck -c cygwin > Cygwin Package Information > Package Version > cygwin 1.3.18-1 > > Use -h to see help about each section > kenji@ib

Re: Strange behavior of MSVC's printf under cygwin shell?

Well, finally I figured out why the printf text is not displayed right away. You need to turn off the "tty" switch in CYGWIN enviroment variable: set CYGWIN=notty (under DOS prompt, or in autoexec.bat), before starting the bash. Wirawan -- Unsubscribe info: http://cygwin.com/ml/#unsubscri

Re: Strange behavior of MSVC's printf under cygwin shell?

On Tuesday 26 March 2002 09:04, Pietro Toniolo wrote: > Nay, I campiled the proposed program (every package on my side is in the > "Last" status) and, with -no-cygwin, I do have an unbuffered stdout. You mean buffered? > Is it an "undefined behavior" of the c compiler? > But why a different defa

RE: Strange behavior of MSVC's printf under cygwin shell?

> -Original Message- > From: Pietro Toniolo [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 7:04 PM > Is it an "undefined behavior" of the c compiler? > But why a different default behavior, with and without the flag? You get a different C library with, and without the flag

Re: Strange behavior of MSVC's printf under cygwin shell?

"Larry Hall (RFK Partners, Inc)" wrote: > The problem must be at your end. I don't see it here. Looks like you'll > need to debug it more. Nay, I campiled the proposed program (every package on my side is in the "Last" status) and, with -no-cygwin, I do have an unbuffered stdout. Is it an "un

Re: Strange behavior of MSVC's printf under cygwin shell?

Wirawan Purwanto wrote: > Why does the screen output displayed using MSVC's printf subroutine not get > shown immediately under Cygwin shell (bash, specifically)? Rather, it would > wait for a long time before showing the text lines (many lines at once). How > to change this behavior? With -mno-

Re: Strange behavior of MSVC's printf under cygwin shell?

I have frequently seen unpredictable behavior of C prints in terms of their timing. (I'm an old guy and I still debug with prints from time to time). The only way I got predictable results was to do a buffer flush immediately after the print. In my case, if I didn't do that, and the program cra

Re: Strange behavior of MSVC's printf under cygwin shell?

At 04:38 PM 3/25/2002, Wirawan Purwanto wrote: >Hi, > >Why does the screen output displayed using MSVC's printf subroutine not get >shown immediately under Cygwin shell (bash, specifically)? Rather, it would >wait for a long time before showing the text lines (many lines at once). How >to change t

RE: Strange behavior

t; -Original Message- > > From: Chuck Allison [mailto:[EMAIL PROTECTED]] > > Sent: Monday, March 04, 2002 4:08 PM > > To: Richard R. Malloy; Randall R Schulz > > Cc: Ross Smith; [EMAIL PROTECTED] > > Subject: Re: Strange behavior > > > > > > That&

RE: Strange behavior

L PROTECTED]] > Sent: Monday, March 04, 2002 4:08 PM > To: Richard R. Malloy; Randall R Schulz > Cc: Ross Smith; [EMAIL PROTECTED] > Subject: Re: Strange behavior > > > That's the point. They're always redued, so in both cases, > the expression 2.0

Re: Strange behavior

"Ross Smith" <[EMAIL PROTECTED]>; "'Chuck Allison'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, March 03, 2002 9:47 PM Subject: Re: Strange behavior > OK. I'm no IA32 expert can someone explain the following results. (Do > th

Re: Strange behavior

OK. I'm no IA32 expert can someone explain the following results. (Do the floating point registers use guard bits, randomly initialized perhaps?) bool operator==(const Rational& r1, const Rational& r2) { double a=r1.toDouble(), b=r2.toDouble(); cout << ?== a " << a << " " << ?== b " << b <<

RE: Strange behavior

Ross, To call that result "pure luck" denies the fact that digital computers, when properly functioning, are 100% deterministic. Of course, it's not proper floating-point programming, but that doesn't mean "luck" is involved. Randall Schulz Mountain View, CA USA At 18:04 2002-03-03, Ross Sm

RE: Strange behavior

> From: Chuck Allison [mailto:[EMAIL PROTECTED]] > > I have a simple Rational number class and have discovered > weird behavior > with Cygwin's g++. If you look at the very short main program in file > rtest2.cpp, you will see by the output that g++ get's the > wrong answer for > > r1 / r2 ==

Re: Strange behavior

I don't think it's cygwin. Looks like something in gnu (complier or libs?). David --- 72$ uname -a && g++ --version && ./rtest2 Linux milo 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown 2.96 5/4 1 -1/4 1 3/8 1 2/3 0 319$ uname -a && g++ --version ; ./rtest2 SunOS opus 5.7 Generic sun4u