On Tue, 6 Aug 2019 19:09:04, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin"
wrote:
> > zero-sized? Irrelevant.
>
> It is actually very relevant. Because executing an empty script results in=
> "success" (exit code 0) -- that creates a false-positive.
Good morning Anton,
Sorry for being bri
I'm noticing that in a high-contention situation (many processes try to get
ahold of a semaphore) semget() on Cygwin starts to return EAGAIN (try again)
after about 62 processes has gotten to call semget() and are actively competing
for the semaphore (i.e. using the semaphore ID semget() returne
On 2019-08-06 09:20, Michael Haubenwallner wrote:
> using 'env -i' to create an empty environment, the SYSTEMROOT and WINDIR
> environment variables are preserved (or recreated):
> $ /usr/bin/env -i /usr/bin/env
> SYSTEMROOT=C:\Windows
> WINDIR=C:\Windows
> And with cygpath, there is the -A, -D,
> You seem to have worked it out already so please send a patch in
> git format-patch foramt to the cygwin-patches mailing list.
I tried :-/
:
Sorry, only subscribers may post. (#5.7.2)
I do not use git to pull Cygwin sources. The last snapshot (that corresponds
to the last-known-stable releas
> I did read the thread.
Really?
> which you confirmed after the fact.
Oh really? Then read again:
In my initial post that started the entire thread I wrote:
> On Unix, an empty file can only be executed (exit code 0) if there's the "x"
> permission granted.
So what's your deal, exactly?
> On Aug 6, 2019, at 4:16 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>
>> Which is why, as Ken said, the size is irrelevant.
>
> Which makes your comment irrelevant as well. Read the thread what I was
> responding and to whom before trolling.
I did read the thread. And Ken's comment was e
I found the problem. I guess there's a number of locations where .ldaprc
can be found. I have an old backup of a Linux home directory under my
cygwin home and that contained a .ldaprc with a TLS_CACERTDIR setting that
makes no sense on my windows box. I removed it and also the ldap.conf I
just cre
> Which is why, as Ken said, the size is irrelevant.
Which makes your comment irrelevant as well. Read the thread what I was
responding and to whom before trolling.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: htt
> On Aug 6, 2019, at 3:39 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via wrote:
>
>> But what's your basis for saying that an empty script shouldn't be
>> executable?
>
> I meant it only in the context of the script file lacking the proper "x"
> permission.
> Of course an empty script _with_ such
> But what's your basis for saying that an empty script shouldn't be executable?
I meant it only in the context of the script file lacking the proper "x"
permission.
Of course an empty script _with_ such permissions allowed must be executable,
and it will always complete with exit code 0.
--
P
On Aug 6 18:54, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> I have noticed a discrepancy between the process priority shown by
> "top" vs. what getpriority() returns.
>
> I'm using the procps-based "top", so it reads the priority value from
> /proc/PID/stat. The value gets there via
On 8/6/2019 3:09 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
>> zero-sized? Irrelevant.
>
> It is actually very relevant. Because executing an empty script results in
> "success" (exit code 0) -- that creates a false-positive.
You were absolutely right on your first complaint, th
Thank you, Achim! I should have thought of that myself. Indeed adding an
appropriate TLS_CACERT to ldap.conf has solved the problem and 2.4.48
ldapsearch is working now.
On Tue, Aug 6, 2019, 12:44 Achim Gratz wrote:
> David Goldberg writes:
> > Correct, openssl s_client works, as does the older
> zero-sized? Irrelevant.
It is actually very relevant. Because executing an empty script results in
"success" (exit code 0) -- that creates a false-positive.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cy
I have noticed a discrepancy between the process priority shown by "top" vs.
what getpriority() returns.
I'm using the procps-based "top", so it reads the priority value from
/proc/PID/stat. The value gets there via code found in "fhandler_process.cc":
/* The BasePriority returned to a 32 bi
On Tue, Aug 6, 2019 at 10:25 AM Corinna Vinschen wrote:
> https://en.wikipedia.org/wiki/Environment_variable#Windows claims that
> "The %SystemDrive% variable is a special system-wide environment
> variable found on Windows NT and its derivatives. Its value is the drive
> upon which the system dir
Here's a fix to squirrel away; using the alt key and pressing the number pad
keys (while holding the alt key) you can enter a ascii character
for example:
ALT 101
https://www.alt-codes.net/
From: cygwin-ow...@cygwin.com on behalf of Dominic
Bragge
Sent: Tuesda
David Goldberg writes:
> Correct, openssl s_client works, as does the older build of ldapsearch. I
> can't find any .ldaprc nor ldap.conf files on my system.
Then work the other way around and create a configuration file that
points to the PKI. It's entirely possible that the compiled-in default
On Aug 6 10:10, Bill Stewart wrote:
> On Tue, Aug 6, 2019 at 9:53 AM Corinna Vinschen wrote:
>
> > How so? SYSTEMDRIVE is the drive SYSTEMROOT is installed on, no?
>
> https://support.microsoft.com/en-us/help/314470/
>
> "The system volume refers to the disk volume that contains the
> hardware
On Tue, Aug 6, 2019 at 9:53 AM Corinna Vinschen wrote:
> How so? SYSTEMDRIVE is the drive SYSTEMROOT is installed on, no?
https://support.microsoft.com/en-us/help/314470/
"The system volume refers to the disk volume that contains the
hardware-specific files that are needed to start Windows, suc
On Aug 6 09:47, Bill Stewart wrote:
> On Tue, Aug 6, 2019 at 9:42 AM Corinna Vinschen wrote:
> >
> > On Aug 6 17:20, Michael Haubenwallner wrote:
> > > Now what I've failed to find is how to query the value for the
> > > "SystemDrive"
> > > environment variable.
> >
> > Just strip it off SYSTEMR
On Tue, Aug 6, 2019 at 9:42 AM Corinna Vinschen wrote:
>
> On Aug 6 17:20, Michael Haubenwallner wrote:
> > Now what I've failed to find is how to query the value for the "SystemDrive"
> > environment variable.
>
> Just strip it off SYSTEMROOT?
IIRC, that will not give the expected value if Windo
On Aug 6 17:20, Michael Haubenwallner wrote:
> Hi,
>
> using 'env -i' to create an empty environment, the SYSTEMROOT and WINDIR
> environment variables are preserved (or recreated):
> $ /usr/bin/env -i /usr/bin/env
> SYSTEMROOT=C:\Windows
> WINDIR=C:\Windows
>
> And with cygpath, there is the
Thank you, Brian that got me to a local build. Unfortunately that has the
same error as the binary installation of 2.4.48. Here are relevant
snippets of the output from each version:
2.4.42 which works:
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 writ
Hi,
using 'env -i' to create an empty environment, the SYSTEMROOT and WINDIR
environment variables are preserved (or recreated):
$ /usr/bin/env -i /usr/bin/env
SYSTEMROOT=C:\Windows
WINDIR=C:\Windows
And with cygpath, there is the -A, -D, -H, -O, -P, -S, -W and even -F flags
to query the value
Clang is using 64-bit absolute addresses when accessing static data in
64-bit mode. This is inefficient because it requires an extra 10-bytes
long instruction for loading an address into a register every time it
needs to access static data. All other compilers use relative addresses.
Example:
On Aug 6 10:33, Corinna Vinschen wrote:
> On Aug 6 03:19, Ken Brown wrote:
> > >>> On 8/5/2019 2:18 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
> > >>> wrote:
> > Hi,
> >
> > Please consider the following shell session:
> >
> > $ cat dummy.c
> > #include
>
Here's another bug report.
Cygwin Clang fails when compiling a complicated program with big
templates. The same program compiles OK on Linux clang.
I have not made a minimal test case because smaller cases compile ok.
The test case is too big for attaching to a mailing list, so I have made
i
On Aug 6 03:19, Ken Brown wrote:
> On 8/5/2019 4:39 PM, Ken Brown wrote:
> > On 8/5/2019 4:19 PM, Thomas Wolff wrote:
> >>
> >> Am 05.08.2019 um 22:01 schrieb Ken Brown:
> >>> On 8/5/2019 2:18 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
> >>> wrote:
> Hi,
>
> Please conside
29 matches
Mail list logo
