Re: IBM MQ client application fails on latest cygwin

[Morten Kjærulff via Cygwin]

On Fri, Apr 9, 2021 at 7:26 AM Morten Kjærulff wrote:
>
> On Fri, Apr 9, 2021 at 2:22 AM Takashi Yano wrote:
> >
> > On Thu, 8 Apr 2021 18:30:25 +0200
> > Morten Kjærulff wrote:
> > > Could it be a codepage issue?
> >
> > Maybe.
> >
> > What does chcp.com say in command prompt and in mintty?
>
> 850
>
> > In cygwin 3.2.0, the codepage, when pseudo console is disabled,
> > has been changed from the default codepage of the system to
> > UTF-8 (65001). If pseudo console is disabled in your environment
> > for some reason, this can affect.
> >
> > Please try to change the codepage using chcp.com to the default
> > codepage of the system.
>
> Then it works:
>
> $ cmd
> Microsoft Windows [Version 10.0.17763.1817]
> (c) 2018 Microsoft Corporation. Alle rettigheder forbeholdes.
>
> C:\mhome>set MQSERVER=BROWSE/TCP/mvs1(1414)
> set MQSERVER=BROWSE/TCP/mvs1(1414)
>
> C:\mhome>chcp
> chcp
> Active code page: 65001
>
> C:\mhome>amqsbcgc Q
> amqsbcgc Q
>
> AMQSBCG0 - starts here
> **
>
>  MQCONNX failed with CompCode:2, Reason:2539
> C:\mhome>chcp 850
> chcp 850
> Active code page: 850
>
> C:\mhome>amqsbcgc Q
> amqsbcgc Q
>
> AMQSBCG0 - starts here
> **
>
>  MQOPEN - 'Q'
>  MQOPEN failed with CompCode:2, Reason:2085
>  MQDISC
> C:\mhome>
>
> > The default codepage of the system is used also when the
> > pseudo console is activated, so if possible, I recomend to
> > enable it somehow.
> >
> > The reason why pseudo console is disabled, can be one of:
> > - The system is older than Win10 1809.
> > - disable_pcon is set in environment variable CYGWIN.
> > - Terminal does not have enough capability to enable it. (e.g. TERM=dumb)
> > - The "Legacy console" mode is enabled.
> >   https://docs.microsoft.com/en-us/windows/console/legacymode
>
> For some reason I was running in legacy mode. Turning it off, make
> chcp display '0' under mintty, but my MQ client works:
>
> $ cmd
> Microsoft Windows [Version 10.0.17763.1817]
> (c) 2018 Microsoft Corporation. Alle rettigheder forbeholdes.
>
> C:\mhome>chcp
> Active code page: 0
>
> C:\mhome>set MQSERVER=BROWSE/TCP/mvs1(1414)
>
> C:\mhome>amqsbcgc Q
>
> AMQSBCG0 - starts here
> **
>
>  MQOPEN - 'Q'
>  MQOPEN failed with CompCode:2, Reason:2085
>  MQDISC
> C:\mhome>
>
> >
> > --
> > Takashi Yano

Sorry for replying personally and not to the group.

I have a virtual machine with Windows 7.
It is also a problem here, but here I don't have "legacy mode" in the
command prompt properties.
Any tricks?

/Morten
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ITA] pv

[Marco Atzeri via Cygwin-apps]

On 09.04.2021 01:36, Andrew Schulman via Cygwin-apps wrote:

I want to maintain pv, since it's being orphaned. I lightly updated the old
cygport script, and checked that the latest version, 1.6.6, builds OOTB.
Will upload the new release as soon as it's approved. Thanks, Andrew



updated cygwin-pkg-maint

Regards
Marco

Re: A problem with noacl+umask+chmod result

[Orgad Shaneh via Cygwin]

On Fri, Apr 9, 2021 at 4:50 AM Andrey Repin  wrote:
>
> Greetings, Orgad Shaneh!
>
> > On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh  wrote:
> >>
> >> Hi,
> >>
> >> If a filesystem is mounted with noacl, calling chmod to add write
> >> permissions after umasking this permission doesn't work. Demonstrated
> >> with command-line and C++.
> >>
> >> Did I miss something or is this a real bug? According to umask man, it
> >> should only affect newly created files and directories, but I didn't
> >> find anything that relates to chmod.
> >>
> >> Command-line:
> >> touch foo
> >> ls -l foo
> >> # -rw-r--r-- ... foo
> >> umask 200
> >> chmod 0 foo
> >> ls -l foo
> >> # -r--r--r-- ... foo
> >> chmod 200 foo
> >> ls -l foo
> >> # -r--r--r-- ... foo
> >> # Expected to have rw
>
> > Marco Atzeri replied to the mailing list but did not CC me, so I
> > didn't receive it:
>
> The expectation is that you subscribe to the list of interest.

Why? If I report a bug, I'm interested in this bug, and I don't want
to receive dozens of emails every day about other issues.

Every time you report a bug to a project on github/jira/whatever, you
subscribe to everything in this project?

> >> without ACL you can not expect the POSIX scheme to properly work.
> >> see
> >> https://cygwin.com/cygwin-ug-net/ntsec.html
> >> to understand how Cygwin uses ACL to mimic POSIX permissions
>
> > Thanks Marco!
>
> > I'm well aware of that. I don't expect it to work properly. From what
> > I know, it can only set/unset user write bit. Read bits are always
> > enabled, even on chmod 0.
>
> > What I do expect is that the write bit will not be affected by umask.
> > umask should only affect newly created files, not direct chmod
> > commands.
>
> Yet again: using chmod on noacl filesystem is likely to cause more harm than
> good. You may very well end up with an unusable filesystem until you fix
> permissions by hands.

With noacl, chmod is capable of setting and unsetting the user write
bit, and I expect it to do that.

I actually found this issue because CMake unit tests failed for me on
MSYS which sets noacl.

Anyway, I found the curprit. The problem is not with chmod, but with stat.

fhandler_base::fstat_helper has this line:
  /* This fakes the permissions of all files to match the current umask. */
  buf->st_mode &= ~(cygheap->umask);

So chmod does set the write bit correctly, but stat doesn't report it.

I can see why this is needed, so I'll adapt the CMake tests to workaround this.

Thank you!

- Orgad
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: A problem with noacl+umask+chmod result

[Andrey Repin]

Greetings, Orgad Shaneh!

> On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh  wrote:
>>
>> Hi,
>>
>> If a filesystem is mounted with noacl, calling chmod to add write
>> permissions after umasking this permission doesn't work. Demonstrated
>> with command-line and C++.
>>
>> Did I miss something or is this a real bug? According to umask man, it
>> should only affect newly created files and directories, but I didn't
>> find anything that relates to chmod.
>>
>> Command-line:
>> touch foo
>> ls -l foo
>> # -rw-r--r-- ... foo
>> umask 200
>> chmod 0 foo
>> ls -l foo
>> # -r--r--r-- ... foo
>> chmod 200 foo
>> ls -l foo
>> # -r--r--r-- ... foo
>> # Expected to have rw

> Marco Atzeri replied to the mailing list but did not CC me, so I
> didn't receive it:

The expectation is that you subscribe to the list of interest.

>> without ACL you can not expect the POSIX scheme to properly work.
>> see
>> https://cygwin.com/cygwin-ug-net/ntsec.html
>> to understand how Cygwin uses ACL to mimic POSIX permissions

> Thanks Marco!

> I'm well aware of that. I don't expect it to work properly. From what
> I know, it can only set/unset user write bit. Read bits are always
> enabled, even on chmod 0.

> What I do expect is that the write bit will not be affected by umask.
> umask should only affect newly created files, not direct chmod
> commands.

Yet again: using chmod on noacl filesystem is likely to cause more harm than
good. You may very well end up with an unusable filesystem until you fix
permissions by hands.


-- 
With best regards,
Andrey Repin
Friday, April 9, 2021 4:43:01

Sorry for my terrible english...

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Questions on how to upgrade Apache

[Brian S. Wilson via Cygwin]

On 4/8/2021 1:30 AM, Andrey Repin wrote:

--

Please contact me if you have any questions or concerns.

Sincerely,

Brian S. Wilson
Primary: wil...@ds.net  *(preferred)*
Secondary: wilso...@xfinity.com 
Tertiary: bria...@bellsouth.net 
Phone: +1 (678) 376-9258
Mobile: +1 (678) 232-9357
Address: 1900 Grouse Ct. Lawrenceville, GA 30044-6914



*This message has been digitally signed as a security measure.*



Is there a reason you are using Cygwin build of Apache?
Can't you use native one?
Perhaps he likes using a Posix like environment and can't use a native 
windows Apache installation.  I have a similar issue and used the Cygwin 
instance on an older Windows machine that wasn't much use for anything 
else.  It worked like a charm and could be used to easily test web site 
changes.  All the joy of Posix and no conversion from Windows native 
issues.


OpenPGP_0xF8910FE574F994A6.asc
Description: OpenPGP public key
<>

OpenPGP_signature
Description: OpenPGP digital signature
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: IBM MQ client application fails on latest cygwin

[Takashi Yano via Cygwin]

On Thu, 8 Apr 2021 18:30:25 +0200
Morten Kjærulff wrote:
> Could it be a codepage issue?

Maybe.

What does chcp.com say in command prompt and in mintty?

In cygwin 3.2.0, the codepage, when pseudo console is disabled,
has been changed from the default codepage of the system to
UTF-8 (65001). If pseudo console is disabled in your environment
for some reason, this can affect.

Please try to change the codepage using chcp.com to the default
codepage of the system.

The default codepage of the system is used also when the
pseudo console is activated, so if possible, I recomend to
enable it somehow.

The reason why pseudo console is disabled, can be one of:
- The system is older than Win10 1809.
- disable_pcon is set in environment variable CYGWIN.
- Terminal does not have enough capability to enable it. (e.g. TERM=dumb)
- The "Legacy console" mode is enabled.
  https://docs.microsoft.com/en-us/windows/console/legacymode


-- 
Takashi Yano 
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ITA] pv

[Andrew Schulman via Cygwin-apps]

I want to maintain pv, since it's being orphaned. I lightly updated the old
cygport script, and checked that the latest version, 1.6.6, builds OOTB.
Will upload the new release as soon as it's approved. Thanks, Andrew

Re: [PATCH cygport] Update xorg.cygclass URLs [GOLDSTAR]

[Andrew Schulman via Cygwin-apps]

> On Tue, 2021-01-05 at 15:06 +0100, Achim Gratz wrote:
> > Yaakov Selkowitz via Cygwin-apps writes:
> > > In fact, there are probably a bunch of other http: which could be
> > > converted to https: at this point.  I would suggest anyone who does
> > > that (in separate commit(s)) should get a gold star.
> > 
> > The patch series from Lem plus another handful of cleanups is available
> > at:
> > 
> > https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/URL-updates
> 
> Thank you Lem for the patches, and Achim for gathering them together on a
> branch.  It was surely tedious work, but necessary and much appreciated. 
> These are (finally!) merged, can we get some gold stars please?

Awarded!

https://cygwin.com/goldstars/#LM
https://cygwin.com/goldstars/#AG

Re: AF_UNIX/SOCK_DGRAM is dropping messages

[Ken Brown via Cygwin]

On 4/8/2021 3:47 PM, sten.kristian.ivars...@gmail.com wrote:

Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems

to

drop messages or at least they are not received in the same
order they are  sent


[snip]


Thanks for the test case.  I can confirm the problem.  I'm not
familiar enough with the current AF_UNIX implementation to debug
this easily.  I'd rather spend my time on the new implementation
(on the topic/af_unix branch).  It turns out that your test case
fails there too, but in a completely different way, due to a bug
in sendto for datagrams.  I'll see if I can fix that bug and then try

again.


Ken


Ok, too bad it wasn't our own code base but good that the "mystery"
is verified

I finally succeed to build topic/af_unix (after finding out what
version of zlib was needed), but not with -D__WITH_AF_UNIX to
CXXFLAGS though and thus I haven’t tested it yet

Is it sufficient to add the define to the "main" Makefile or do
you have to add it to all the Makefile:s ? I guess I can find out
though


I do it on the configure line, like this:

../af_unix/configure CXXFLAGS="-g -O0 -D__WITH_AF_UNIX" --

prefix=...



Is topic/af_unix fairly up to date with master branch ?


Yes, I periodically cherry-pick commits from master to topic/af_unix.
I'lldo that again right now.


Either way, I'll be glad to help out testing topic/af_unix


Thanks!


I've now pushed a fix for that sendto bug, and your test case runs
without error on the topic/af_unix branch.


It seems like the test-case do work now with topic/af_unix in
blocking mode, but when using non-blocking (with MSG_DONTWAIT) there
are

some

issues I think

1. When the queue is empty with non-blocking recv(), errno is set to
EPIPE but I think it should be EAGAIN (or maybe the pipe is getting
broken for real of some reason ?)

2. When using non-blocking recv() and no message is written at all,
it seems like recv() blocks forever

3. Using non-blocking recv() where the "client" does send less than
"count" messages, sometimes recv() blocks forever (as well)


My naïve analysis of this is that for the first issue (if any) the
wrong errno is set and for the second issue it blocks if no sendto()
is done after the first recv(), i.e. nothing kicks the "reader thread"
in the butt to realise the queue is empty. It is not super clear
though what POSIX says about creating blocking descriptors and then
using non-blocking-flags with recv(), but this works in Linux any
way


The explanation is actually much simpler.  In the recv code where a
bound datagram socket waits for a remote socket to connect to the
pipe, I simply forget to handle MSG_DONTWAIT.  I've pushed a fix.  Please

retest.

I tested it and now it seems like we get EAGAIN when there's no msg on the
queue, but it seems like the client is blocked as well and that it cannot write
any more messages until it is consumed by the server, so the af_unix.cpp test-
client end prematurely

If using sendto() with MSG_DONTWAIT as well, that is getting a EAGAIN, but
the socket in it self is not a non-blocking socket, it is just the recv() that 
is done
in a non-blocking fashion

As I said earlier, it's a bit fuzzy (or at least for me) what POSIX mean by
non/blocking descriptors combined with non/blocking operations, but as far
as I understand, it should be possible to use blocking sendto()and messages
should be written (as long as some buffer is not filled) at the same time
someone is doing non-blocking recv()

What is your take on this ?


I was thinking of this again and came to the conclusion that the fix 
semantically probably works ok

It was just me that didn't realise that only one message can be on the queue 
simultaneously even in blocking mode

The problem is not functional but merely a performance hog, that I guess you 
have already realised and you mentioned it in previous message but I guess I 
thought it was about some other issue


So, I guess the fix works ok (I haven't done any more tests than with the 
sample program), but I guess out of an throughput aspect I guess it would be a 
good idea to let more messages be written to the queue before the first is 
consumed or so (I guess you already have some thoughts about this?)


I have some thoughts, but nothing definitive yet.  I'll keep thinking.

Ken
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: A problem with noacl+umask+chmod result

[Orgad Shaneh via Cygwin]

On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh  wrote:
>
> Hi,
>
> If a filesystem is mounted with noacl, calling chmod to add write
> permissions after umasking this permission doesn't work. Demonstrated
> with command-line and C++.
>
> Did I miss something or is this a real bug? According to umask man, it
> should only affect newly created files and directories, but I didn't
> find anything that relates to chmod.
>
> Command-line:
> touch foo
> ls -l foo
> # -rw-r--r-- ... foo
> umask 200
> chmod 0 foo
> ls -l foo
> # -r--r--r-- ... foo
> chmod 200 foo
> ls -l foo
> # -r--r--r-- ... foo
> # Expected to have rw

Marco Atzeri replied to the mailing list but did not CC me, so I
didn't receive it:

> without ACL you can not expect the POSIX scheme to properly work.
> see
> https://cygwin.com/cygwin-ug-net/ntsec.html
> to understand how Cygwin uses ACL to mimic POSIX permissions

Thanks Marco!

I'm well aware of that. I don't expect it to work properly. From what
I know, it can only set/unset user write bit. Read bits are always
enabled, even on chmod 0.

What I do expect is that the write bit will not be affected by umask.
umask should only affect newly created files, not direct chmod
commands.

- Orgad
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: EMP Router issue

[cygwinautoreply--- via Cygwin]

>I have been using this same emp router for quite some time on my WIN7 machine 
>but after updating to WIN10, it has quit working.

>The warning I am getting is -
>WARNING: Couldn't compute FAST_CWD pointer. Pease report this problem to the 
>public mailing list gyc...@cygwin.com
>This is causing the router to not start up properly.

>The file version is 1007.9.0.0
>Product version is 1.7.9
>File date is 1/11/2016

>Do you have any suggestions at all to get it working again?


>Thank you,

>Patrick Moore
>Senior Systems Support Engineer
>FECR/NICTD, USA
>E: pmo...@wabtec.com
>C: 219-314-8161

>This email and any attachments are only for use by the intended recipient(s) 
>and may contain legally privileged, confidential, proprietary or otherwise 
>private information. Any unauthorized use, reproduction, dissemination, 
>distribution or other disclosure of the contents of this e-mail or its 
>attachments is strictly prohibited. If you have received this email in error, 
>please notify the sender immediately and delete the original. Neither this 
>information block, the typed name of the sender, nor anything else in this 
>message is intended to constitute an electronic signature unless a specific 
>statement to the contrary is included in this message.

https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

EMP Router issue

[Moore, Patrick]

I have been using this same emp router for quite some time on my WIN7 machine 
but after updating to WIN10, it has quit working.

The warning I am getting is -
WARNING: Couldn't compute FAST_CWD pointer. Pease report this problem to the 
public mailing list gyc...@cygwin.com
This is causing the router to not start up properly.

The file version is 1007.9.0.0
Product version is 1.7.9
File date is 1/11/2016

Do you have any suggestions at all to get it working again?


Thank you,

Patrick Moore
Senior Systems Support Engineer
FECR/NICTD, USA
E: pmo...@wabtec.com
C: 219-314-8161

This email and any attachments are only for use by the intended recipient(s) 
and may contain legally privileged, confidential, proprietary or otherwise 
private information. Any unauthorized use, reproduction, dissemination, 
distribution or other disclosure of the contents of this e-mail or its 
attachments is strictly prohibited. If you have received this email in error, 
please notify the sender immediately and delete the original. Neither this 
information block, the typed name of the sender, nor anything else in this 
message is intended to constitute an electronic signature unless a specific 
statement to the contrary is included in this message.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Questions on how to upgrade Apache

[bzs]

I upgrade apache from sources all the time tho not on cygwin, we use
Linux for that, but the basic idea is the same. My advice, having
looked over other advice here, and your responses:

1. You probably don't want to go to another web server like nginx just
for what you describe.

You would have to reconfigure your entire web server environment
including hosts, server certificates, dependent software (e.g., do
your sites use php?), etc. That can be much more work and subtlety
than just upgrading an apache dot release.

2. Although building apache from source is not very difficult there
are build configuration options and even dependent software (I dunno,
fastcgi, whatever) you would need to navigate.

If you could get the exact build configuration (./configure
...options) that cygwin uses that might make it a lot easier.

That result might "just work" since you're only trying to upgrade a
dot release.

But there may be other issues such as dependent software and
dynamically loaded modules. Fortunately the configuration files
(*.conf) between dot releases should just work, they don't change much
if at all for the releases you describe.

Given their configuration options it might be worth a try if you have
the time and testing environment.

3. But then the pottery shop rule would kick in, you break it, you own
it.

By which I mean where do you go forward from there? Future releases?

You will probably have to build from source forever or find some way
to backtrack back into the binary cygwin releases. For us building and
configuring from sources is fine but TBH on a scale of 1-10 I am an 11
on these things (pardon my modesty :-)).

4. Probably the best advice is:

a) examine why someone thinks you need to do this at all other than
they just like to run the latest and greatest. If it's security flaws
consider that errors in doing this from source or going to another
server entirely could be much more security-error-prone lacking
in-house expertise.

b) If they have such exotic and exacting requirements that they can't
tolerate being behind a few dot releases then they should be willing
to pay an expert to help them meet those requirements (no I'm not
available.)

In all seriousness and apologies to the cygwin crew who I love and
admire the very fact that you're running apache on cygwin makes me
think your requirements can't be too pie-in-the-sky, I'll guess you're
not running Amazon or Shopify etc.

c) Seriously consider a pre-built native Windows apache release.

That should pretty much drop-in and if that seems too difficult the
other options like building from source or switching to another server
will likely be much more difficult.

d) Apply to law school.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

RE: AF_UNIX/SOCK_DGRAM is dropping messages

[Kristian Ivarsson via Cygwin]

> >  Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems
> > to
> >  drop messages or at least they are not received in the same
> >  order they are  sent
> > 
> >  [snip]
> > 
> > > Thanks for the test case.  I can confirm the problem.  I'm not
> > > familiar enough with the current AF_UNIX implementation to debug
> > > this easily.  I'd rather spend my time on the new implementation
> > > (on the topic/af_unix branch).  It turns out that your test case
> > > fails there too, but in a completely different way, due to a bug
> > > in sendto for datagrams.  I'll see if I can fix that bug and then try
> again.
> > >
> > > Ken
> > 
> >  Ok, too bad it wasn't our own code base but good that the "mystery"
> >  is verified
> > 
> >  I finally succeed to build topic/af_unix (after finding out what
> >  version of zlib was needed), but not with -D__WITH_AF_UNIX to
> >  CXXFLAGS though and thus I haven’t tested it yet
> > 
> >  Is it sufficient to add the define to the "main" Makefile or do
> >  you have to add it to all the Makefile:s ? I guess I can find out
> >  though
> > >>>
> > >>> I do it on the configure line, like this:
> > >>>
> > >>>../af_unix/configure CXXFLAGS="-g -O0 -D__WITH_AF_UNIX" --
> > prefix=...
> > >>>
> >  Is topic/af_unix fairly up to date with master branch ?
> > >>>
> > >>> Yes, I periodically cherry-pick commits from master to topic/af_unix.
> > >>> I'lldo that again right now.
> > >>>
> >  Either way, I'll be glad to help out testing topic/af_unix
> > >>>
> > >>> Thanks!
> > >>
> > >> I've now pushed a fix for that sendto bug, and your test case runs
> > >> without error on the topic/af_unix branch.
> > >
> > > It seems like the test-case do work now with topic/af_unix in
> > > blocking mode, but when using non-blocking (with MSG_DONTWAIT) there
> > > are
> > some
> > > issues I think
> > >
> > > 1. When the queue is empty with non-blocking recv(), errno is set to
> > > EPIPE but I think it should be EAGAIN (or maybe the pipe is getting
> > > broken for real of some reason ?)
> > >
> > > 2. When using non-blocking recv() and no message is written at all,
> > > it seems like recv() blocks forever
> > >
> > > 3. Using non-blocking recv() where the "client" does send less than
> > > "count" messages, sometimes recv() blocks forever (as well)
> > >
> > >
> > > My naïve analysis of this is that for the first issue (if any) the
> > > wrong errno is set and for the second issue it blocks if no sendto()
> > > is done after the first recv(), i.e. nothing kicks the "reader thread"
> > > in the butt to realise the queue is empty. It is not super clear
> > > though what POSIX says about creating blocking descriptors and then
> > > using non-blocking-flags with recv(), but this works in Linux any
> > > way
> >
> > The explanation is actually much simpler.  In the recv code where a
> > bound datagram socket waits for a remote socket to connect to the
> > pipe, I simply forget to handle MSG_DONTWAIT.  I've pushed a fix.  Please
> retest.
> 
> I tested it and now it seems like we get EAGAIN when there's no msg on the
> queue, but it seems like the client is blocked as well and that it cannot 
> write
> any more messages until it is consumed by the server, so the af_unix.cpp test-
> client end prematurely
> 
> If using sendto() with MSG_DONTWAIT as well, that is getting a EAGAIN, but
> the socket in it self is not a non-blocking socket, it is just the recv() 
> that is done
> in a non-blocking fashion
> 
> As I said earlier, it's a bit fuzzy (or at least for me) what POSIX mean by
> non/blocking descriptors combined with non/blocking operations, but as far
> as I understand, it should be possible to use blocking sendto()and messages
> should be written (as long as some buffer is not filled) at the same time
> someone is doing non-blocking recv()
> 
> What is your take on this ?

I was thinking of this again and came to the conclusion that the fix 
semantically probably works ok

It was just me that didn't realise that only one message can be on the queue 
simultaneously even in blocking mode

The problem is not functional but merely a performance hog, that I guess you 
have already realised and you mentioned it in previous message but I guess I 
thought it was about some other issue


So, I guess the fix works ok (I haven't done any more tests than with the 
sample program), but I guess out of an throughput aspect I guess it would be a 
good idea to let more messages be written to the queue before the first is 
consumed or so (I guess you already have some thoughts about this?)

Keep up the good work,
Kristian


> > I should add that in all my work so far on the topic/af_unix branch,
> > I've thought mainly about stream sockets.  So there may still be
> > things remaining to be implemented for the datagram case.
> >
> > Ken

--
Problem reports:  

Re: Questions on how to upgrade Apache

[Andrey Repin]

Greetings, Andy Romens!

> I got a question for you all. Our cyber security team is yelling at us to
> update Apache from 2.4.39 to 2.4.46. I have searched far and wide on the web
> to see if there is a way to do that, but so far nothing has turned up. Any
> idea on how to do this or if an updated package will get released soon-ish 
> for Apache?

Is there a reason you are using Cygwin build of Apache?
Can't you use native one?


-- 
With best regards,
Andrey Repin
Thursday, April 8, 2021 8:28:01

Sorry for my terrible english...

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: 3270

[Andrey Repin]

Greetings, Morten Kjærulff!

> I need a new feature in version 4.1alpha7 (Double-clicking on a URL in
> x3270 (on most platforms) and in wc3270 now opens that link in the
> browser).
> Currently I am running wc3270 (native windows) because with that one I
> can configure Right-Ctrl to be ENTER, and as I understand I can't do
> that in c3270 (cygwin).

> Maybe I should just stick with wc3270.

If you don't have a strict requirement to run Cygwin specific build, I would
suggest to stick with native one.


-- 
With best regards,
Andrey Repin
Wednesday, April 7, 2021 19:45:53

Sorry for my terrible english...
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win

[Andrey Repin]

Greetings, Achim Gratz!

> L A Walsh writes:
>> If I move the windows cursor to another editor window in X11,
>> the blinking cursor moves to the new window, but if I move
>> it to a native window, the blinking doesn't stop.
>>
>> Has this always been this way?

> Windows never had "focus follows mouse" in any version I can remember.

It has it in every version starting Windows 95/NT4.

@Linda: try http://joelpurra.com/Projects/X-Mouse_Controls/


-- 
With best regards,
Andrey Repin
Thursday, April 8, 2021 14:18:15

Sorry for my terrible english...

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Questions on how to upgrade Apache

[Glenn Strauss]

On Thu, Apr 08, 2021 at 11:37:13AM -0500, René Berber via Cygwin wrote:
> On 4/8/2021 10:49 AM, Andy Romens via Cygwin wrote:
> 
> > Is there something else Cygwin provides that I should use instead of
> > Apache? Sorry for the elementary questions, I’m still quite new to
> > this :)
> 
> 
> nginx is an alternative (NGINX Open Source. The open source web server).
> 
> Cygwin is at version 1.14.2, current version is 1.19.9 (there's a Windows
> binary at nginx.org).

lighttpd is also an alternative and is kept up-to-date in Cygwin by the
upstream lighttpd maintainer (me)

https://www.cygwin.com/packages/summary/lighttpd-src.html

Latest lighttpd release is lighttpd 1.4.59.
Latest lighttpd available in Cygwin is lighttpd 1.4.59.

Cheers, Glenn
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cannot run executable named setlang

[Orgad Shaneh via Cygwin]

On Thu, Apr 8, 2021 at 3:55 PM Takashi Yano  wrote:
>
> On Thu, 8 Apr 2021 15:25:45 +0300
> Orgad Shaneh wrote:
> > Hi,
> >
> > I cannot run an executable if it is named setlang (case insensitive).
> > It exits with code 127.
> >
> > Example:
> > cp /bin/ls setlang
> > ./setlang -> Error 127
> >
> > I've noticed a difference in ldd output. cygwin dlls appear twice.
> >
> > ldd /bin/ls:
> > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5)
> > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
> > (0x7ffd9bbb)
> > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> > (0x7ffd9b8e)
> > cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
> > cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ff81)
> > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ff83)
> >
> > ldd setlang:
> > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5)
> > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
> > (0x7ffd9bbb)
> > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> > (0x7ffd9b8e)
> > cygwin1.dll => /usr/bin/cygwin1.dll (0xc1)
> > cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17)
> > cygwin1.dll => /usr/bin/cygwin1.dll (0xc1)
> > cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17)
> > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60)
> > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60)
> >
> > Any idea what can cause this?
>
> Isn't this the same issue with:
> https://cygwin.com/pipermail/cygwin/2021-January/247508.html
> ?

Yup, looks like it. Thanks for the reference. We even used the same example :D

- Orgad
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Questions on how to upgrade Apache

[René Berber via Cygwin]

On 4/8/2021 10:49 AM, Andy Romens via Cygwin wrote:

> Is there something else Cygwin provides that I should use instead of
> Apache? Sorry for the elementary questions, I’m still quite new to
> this :)


nginx is an alternative (NGINX Open Source. The open source web server).

Cygwin is at version 1.14.2, current version is 1.19.9 (there's a 
Windows binary at nginx.org).

--
R.Berber

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: IBM MQ client application fails on latest cygwin

[Morten Kjærulff via Cygwin]

On Thu, Apr 8, 2021 at 4:24 PM Morten Kjærulff wrote:
>
> On Thu, Apr 8, 2021 at 4:04 PM Takashi Yano wrote:
> >
> > On Thu, 8 Apr 2021 15:10:54 +0200
> > Morten Kjærulff wrote:
> > > On Thu, Apr 8, 2021 at 2:26 PM Takashi Yano wrote:
> > > >
> > > > On Thu, 8 Apr 2021 20:16:00 +0900
> > > > Takashi Yano wrote:
> > > > > On Thu, 8 Apr 2021 08:04:26 +0200
> > > > > Morten Kjærulff wrote:
> > > > > > On Wed, Apr 7, 2021 at 1:04 PM Takashi Yano wrote:
> > > > > > >
> > > > > > > On Wed, 7 Apr 2021 19:56:24 +0900
> > > > > > > Takashi Yano wrote:
> > > > > > > > On Wed, 7 Apr 2021 11:32:59 +0200
> > > > > > > > Morten Kjærulff wrote:
> > > > > > > > > On Tue, Apr 6, 2021 at 4:37 PM Takashi Yano wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, 6 Apr 2021 15:16:56 +0200
> > > > > > > > > > Morten Kjærulff wrote:
> > > > > > > > > > > When I run it from a windows command prompt, it works 
> > > > > > > > > > > fine.
> > > > > > > > > >
> > > > > > > > > > In this case, did you run MQ client from cygwin shell
> > > > > > > > > > in command prompt? Or run it in cmd.exe?
> > > > > > > > >
> > > > > > > > > what works is:
> > > > > > > > > cmd.exe->bash->script->non-cygwin-mq-client.exe
> > > > > > > > >
> > > > > > > > > what fails is:
> > > > > > > > > cmd.exe->bash->mintty->bash->script->non-cygwin-mq-client.exe
> > > > > > > > >
> > > > > > > > > also fails:
> > > > > > > > > cmd.exe->bash->mintty->bash
> > > > > > > > > and then
> > > > > > > > > cmd /c bash -c 'script' # script->non-cygwin-mq-client.exe
> > > > > > > >
> > > > > > > > Thnaks for the report.
> > > > > > > >
> > > > > > > > What about:
> > > > > > > > mintty->cmd /c bash->non-cygwin-mq-client.exe ?
> > > > > > >
> > > > > > > Do you mean your script starting mq-client by "script" ?
> > > > > > > I meant /usr/bin/script by "script".
> > > > > > >
> > > > > > > > > cmd.exe->bash->script->non-cygwin-mq-client.exe
> > > > > > >
> > > > > > > If so, what about:
> > > > > > > cmd.exe->bash->/usr/bin/script->(your 
> > > > > > > script)->non-cygwin-mq-client.exe ?
> > > > > > >
> > > > > > > --
> > > > > > > Takashi Yano
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I cooked the issue down to this.
> > > > > >
> > > > > > My script:
> > > > > > $ cat tmq.sh
> > > > > > #!/bin/sh
> > > > > >
> > > > > > export MQSERVER='BROWSE/TCP/mvs1(1414)'
> > > > > > amqsbcgc Q
> > > > > >
> > > > > > amqsbcgc is a sample that comes with MQ:
> > > > > > $ which amqsbcgc
> > > > > > /cygdrive/c/Program Files/IBM/WebSphere 
> > > > > > MQ/tools/c/samples/bin64/amqsbcgc
> > > > > >
> > > > > > It is a C program:
> > > > > > $ head /cygdrive/c/Program\ Files/IBM/WebSphere\ 
> > > > > > MQ/tools/c/Samples/amqsbcg0.c
> > > > > > /* @(#) MQMBID sn=p800-008-171121 su=_A5OAkM6qEeemCpCOEyy4yA
> > > > > > pn=samples/c/amqsbcg0.c */
> > > > > > /**/
> > > > > > /*  
> > > > > >   */
> > > > > > /* Program name: AMQSBCG0   
> > > > > >   */
> > > > > > /*  
> > > > > >   */
> > > > > > /* Description : Sample program to read and output the message  
> > > > > >   */
> > > > > > /* descriptor fields, any other message properties  
> > > > > >   */
> > > > > > /* and the message content of all the messages on a 
> > > > > >   */
> > > > > > /* queue
> > > > > >   */
> > > > > > /*> > > > >   */
> > > > > >
> > > > > > When I run it from a bash prompt, started with cmd.exe->bash.exe, I
> > > > > > see correct output (2085 means Q not found, which means that we are
> > > > > > connected ok):
> > > > > > $ ./tmq.sh
> > > > > >
> > > > > > AMQSBCG0 - starts here
> > > > > > **
> > > > > >
> > > > > >  MQOPEN - 'Q'
> > > > > >  MQOPEN failed with CompCode:2, Reason:2085
> > > > > >  MQDISC
> > > > > >
> > > > > > If I start mintty, I see:
> > > > > > $ ./tmq.sh
> > > > > >
> > > > > > AMQSBCG0 - starts here
> > > > > > **
> > > > > >
> > > > > >  MQCONNX failed with CompCode:2, Reason:2539
> > > > > >
> > > > > > I also see errors at the server side, which means that some sort of
> > > > > > connection has been made, but it seems to be garbled.
> > > > > >
> > > > > > When we are "under" mintty it does not matter how I call amqsbcgc, 
> > > > > > it
> > > > > > always fails, here is one example:
> > > > > >
> > > > > > $ ./tmq.sh
> > > > > >
> > > > > > AMQSBCG0 - starts here
> > > > > > **
> > > > > >
> > > > > >  MQCONNX failed with CompCode:2, Reason:2539
> > > > > >
> > > > > > $ cmd
> > > > > > Microsoft Windows [Version 10.0.17763.1817]
> > > > > > (c) 2018 Microsoft Corporation. Alle rettigheder forbeholdes.
> > > >
> > > > Ah, you are using Win10 1809. Then the pseudo console 

Re: Questions on how to upgrade Apache

[Eliot Moss]

On 4/8/2021 11:49 AM, Andy Romens via Cygwin wrote:
> Is there something else Cygwin provides that I should use instead of Apache?
> Sorry for the elementary questions, I’m still quite new to this :)

No.  Cygwin, at its heart, is a Windows library (.dll file) that, when used,
provides a library call environment as close to POSIX (Linux, Unix) as it can,
given that Windows is not Unix.  Programs must be explicitly compiled to use
that library.  Sometimes that need adjustments (patches) to work correctly in
the environment.  Presumably all those patches that would be necessary for
previous version so Apache are in the source package for those previous
versions, and might be enough for building a new version as well.  As you are
probably aware, a number of commonly used Unix programs have been ported to
work under Cygwin.

Alternatively, you can use Windows-native programs and tools.  I personally am
not sure if Apache is available as a Windows-native download, etc.

There is also the Windows Subsystem for Linux, which runs a virtual machine
under which many Unix programs can be installed without modification.

Regards - Eliot Moss
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Questions on how to upgrade Apache

[Andy Romens via Cygwin]

Is there something else Cygwin provides that I should use instead of Apache? 
Sorry for the elementary questions, I’m still quite new to this :)

Thanks,
-Andy

On Apr 8, 2021, at 8:33 AM, Stephen John Smoogen  wrote:




On Thu, 8 Apr 2021 at 10:02, Andy Romens via Cygwin 
mailto:cygwin@cygwin.com>> wrote:
Hi Cygwin (or whoever gets these, I just signed up),

I got a question for you all. I need to update Apache from 2.4.39 to 2.4.46. I 
have searched far and wide on the web to see if there is a way to do that, but 
so far nothing has turned up. Any idea on how to do this or if an updated 
package will get released soon-ish for Apache? Background info, we are running 
Cygwin on a Windows 2012 Server. Anything else, please let me know and I will 
investigate.


It looks like the apache package is obsolete and orphaned currently. You will 
need to compile a version of apache on the cygwin system itself to update to a 
newer version.

https://cygwin.com/cygwin-pkg-maint


Thank you in advance,
-Andy
--
Problem reports:  
https://cygwin.com/problems.html
FAQ:  
https://cygwin.com/faq/
Documentation:
https://cygwin.com/docs.html
Unsubscribe info: 
https://cygwin.com/ml/#unsubscribe-simple


--
Stephen J Smoogen.

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Questions on how to upgrade Apache

[Stephen John Smoogen via Cygwin]

On Thu, 8 Apr 2021 at 10:02, Andy Romens via Cygwin 
wrote:

> Hi Cygwin (or whoever gets these, I just signed up),
>
> I got a question for you all. I need to update Apache from 2.4.39 to
> 2.4.46. I have searched far and wide on the web to see if there is a way to
> do that, but so far nothing has turned up. Any idea on how to do this or if
> an updated package will get released soon-ish for Apache? Background info,
> we are running Cygwin on a Windows 2012 Server. Anything else, please let
> me know and I will investigate.
>
>
It looks like the apache package is obsolete and orphaned currently. You
will need to compile a version of apache on the cygwin system itself to
update to a newer version.

https://cygwin.com/cygwin-pkg-maint



> Thank you in advance,
> -Andy
> --
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>


-- 
Stephen J Smoogen.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: IBM MQ client application fails on latest cygwin

[Takashi Yano via Cygwin]

On Thu, 8 Apr 2021 15:10:54 +0200
Morten Kjærulff wrote:
> On Thu, Apr 8, 2021 at 2:26 PM Takashi Yano wrote:
> >
> > On Thu, 8 Apr 2021 20:16:00 +0900
> > Takashi Yano wrote:
> > > On Thu, 8 Apr 2021 08:04:26 +0200
> > > Morten Kjærulff wrote:
> > > > On Wed, Apr 7, 2021 at 1:04 PM Takashi Yano wrote:
> > > > >
> > > > > On Wed, 7 Apr 2021 19:56:24 +0900
> > > > > Takashi Yano wrote:
> > > > > > On Wed, 7 Apr 2021 11:32:59 +0200
> > > > > > Morten Kjærulff wrote:
> > > > > > > On Tue, Apr 6, 2021 at 4:37 PM Takashi Yano wrote:
> > > > > > > >
> > > > > > > > On Tue, 6 Apr 2021 15:16:56 +0200
> > > > > > > > Morten Kjærulff wrote:
> > > > > > > > > When I run it from a windows command prompt, it works fine.
> > > > > > > >
> > > > > > > > In this case, did you run MQ client from cygwin shell
> > > > > > > > in command prompt? Or run it in cmd.exe?
> > > > > > >
> > > > > > > what works is:
> > > > > > > cmd.exe->bash->script->non-cygwin-mq-client.exe
> > > > > > >
> > > > > > > what fails is:
> > > > > > > cmd.exe->bash->mintty->bash->script->non-cygwin-mq-client.exe
> > > > > > >
> > > > > > > also fails:
> > > > > > > cmd.exe->bash->mintty->bash
> > > > > > > and then
> > > > > > > cmd /c bash -c 'script' # script->non-cygwin-mq-client.exe
> > > > > >
> > > > > > Thnaks for the report.
> > > > > >
> > > > > > What about:
> > > > > > mintty->cmd /c bash->non-cygwin-mq-client.exe ?
> > > > >
> > > > > Do you mean your script starting mq-client by "script" ?
> > > > > I meant /usr/bin/script by "script".
> > > > >
> > > > > > > cmd.exe->bash->script->non-cygwin-mq-client.exe
> > > > >
> > > > > If so, what about:
> > > > > cmd.exe->bash->/usr/bin/script->(your 
> > > > > script)->non-cygwin-mq-client.exe ?
> > > > >
> > > > > --
> > > > > Takashi Yano
> > > >
> > > > Hi,
> > > >
> > > > I cooked the issue down to this.
> > > >
> > > > My script:
> > > > $ cat tmq.sh
> > > > #!/bin/sh
> > > >
> > > > export MQSERVER='BROWSE/TCP/mvs1(1414)'
> > > > amqsbcgc Q
> > > >
> > > > amqsbcgc is a sample that comes with MQ:
> > > > $ which amqsbcgc
> > > > /cygdrive/c/Program Files/IBM/WebSphere 
> > > > MQ/tools/c/samples/bin64/amqsbcgc
> > > >
> > > > It is a C program:
> > > > $ head /cygdrive/c/Program\ Files/IBM/WebSphere\ 
> > > > MQ/tools/c/Samples/amqsbcg0.c
> > > > /* @(#) MQMBID sn=p800-008-171121 su=_A5OAkM6qEeemCpCOEyy4yA
> > > > pn=samples/c/amqsbcg0.c */
> > > > /**/
> > > > /**/
> > > > /* Program name: AMQSBCG0 */
> > > > /**/
> > > > /* Description : Sample program to read and output the message*/
> > > > /* descriptor fields, any other message properties*/
> > > > /* and the message content of all the messages on a   */
> > > > /* queue  */
> > > > /*> > >
> > > > When I run it from a bash prompt, started with cmd.exe->bash.exe, I
> > > > see correct output (2085 means Q not found, which means that we are
> > > > connected ok):
> > > > $ ./tmq.sh
> > > >
> > > > AMQSBCG0 - starts here
> > > > **
> > > >
> > > >  MQOPEN - 'Q'
> > > >  MQOPEN failed with CompCode:2, Reason:2085
> > > >  MQDISC
> > > >
> > > > If I start mintty, I see:
> > > > $ ./tmq.sh
> > > >
> > > > AMQSBCG0 - starts here
> > > > **
> > > >
> > > >  MQCONNX failed with CompCode:2, Reason:2539
> > > >
> > > > I also see errors at the server side, which means that some sort of
> > > > connection has been made, but it seems to be garbled.
> > > >
> > > > When we are "under" mintty it does not matter how I call amqsbcgc, it
> > > > always fails, here is one example:
> > > >
> > > > $ ./tmq.sh
> > > >
> > > > AMQSBCG0 - starts here
> > > > **
> > > >
> > > >  MQCONNX failed with CompCode:2, Reason:2539
> > > >
> > > > $ cmd
> > > > Microsoft Windows [Version 10.0.17763.1817]
> > > > (c) 2018 Microsoft Corporation. Alle rettigheder forbeholdes.
> >
> > Ah, you are using Win10 1809. Then the pseudo console should be
> > supported.
> >
> > > > C:\mhome\mqadm>set MQSERVER=BROWSE/TCP/mvs1(1414)
> > > > set MQSERVER=BROWSE/TCP/mvs1(1414)
> > > >
> > > > C:\mhome\mqadm>amqsbcgc Q
> > > > amqsbcgc Q
> > > >
> > > > AMQSBCG0 - starts here
> > > > **
> > > >
> > > >  MQCONNX failed with CompCode:2, Reason:2539
> > >
> > > In the log above in cmd, input command are echoed twice.
> > > This happens when the pseudo console is not activated. Are you
> > > using Win7 or old Win10? Or do you set CYGWIN=disable_pcon by
> > > any chance?
> > >
> > > If you set CYGWIN=disable_pcon, please try unset it.
> >
> > Probably you set CYGWIN=disable_pcon in .bashrc or elsewhere.
> > Please try to unset it.
> 
> I explicitly have a
> 

Re: Cannot run executable named setlang

[Takashi Yano via Cygwin]

On Thu, 8 Apr 2021 21:55:18 +0900
Takashi Yano wrote:
> On Thu, 8 Apr 2021 15:25:45 +0300
> Orgad Shaneh wrote:
> > Hi,
> > 
> > I cannot run an executable if it is named setlang (case insensitive).
> > It exits with code 127.
> > 
> > Example:
> > cp /bin/ls setlang
> > ./setlang -> Error 127
> > 
> > I've noticed a difference in ldd output. cygwin dlls appear twice.
> > 
> > ldd /bin/ls:
> > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5)
> > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
> > (0x7ffd9bbb)
> > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> > (0x7ffd9b8e)
> > cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
> > cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ff81)
> > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ff83)
> > 
> > ldd setlang:
> > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5)
> > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
> > (0x7ffd9bbb)
> > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> > (0x7ffd9b8e)
> > cygwin1.dll => /usr/bin/cygwin1.dll (0xc1)
> > cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17)
> > cygwin1.dll => /usr/bin/cygwin1.dll (0xc1)
> > cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17)
> > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60)
> > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60)
> > 
> > Any idea what can cause this?
> 
> Isn't this the same issue with:
> https://cygwin.com/pipermail/cygwin/2021-January/247508.html
> ?

Probably you have "setlang.exe" entry in "Program settings" in
Exploit Protection.

-- 
Takashi Yano 
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cannot run executable named setlang

[Marco Atzeri via Cygwin]

On 08.04.2021 14:25, Orgad Shaneh via Cygwin wrote:

Hi,

I cannot run an executable if it is named setlang (case insensitive).
It exits with code 127.

Example:
cp /bin/ls setlang
./setlang -> Error 127



it works for me

what type of AV are you using ?
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Questions on how to upgrade Apache

[Andy Romens via Cygwin]

Hi Cygwin (or whoever gets these, I just signed up),

I got a question for you all. I need to update Apache from 2.4.39 to 2.4.46. I 
have searched far and wide on the web to see if there is a way to do that, but 
so far nothing has turned up. Any idea on how to do this or if an updated 
package will get released soon-ish for Apache? Background info, we are running 
Cygwin on a Windows 2012 Server. Anything else, please let me know and I will 
investigate.

Thank you in advance,
-Andy
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: IBM MQ client application fails on latest cygwin

[Morten Kjærulff via Cygwin]

On Thu, Apr 8, 2021 at 2:26 PM Takashi Yano wrote:
>
> On Thu, 8 Apr 2021 20:16:00 +0900
> Takashi Yano wrote:
> > On Thu, 8 Apr 2021 08:04:26 +0200
> > Morten Kjærulff wrote:
> > > On Wed, Apr 7, 2021 at 1:04 PM Takashi Yano wrote:
> > > >
> > > > On Wed, 7 Apr 2021 19:56:24 +0900
> > > > Takashi Yano wrote:
> > > > > On Wed, 7 Apr 2021 11:32:59 +0200
> > > > > Morten Kjærulff wrote:
> > > > > > On Tue, Apr 6, 2021 at 4:37 PM Takashi Yano wrote:
> > > > > > >
> > > > > > > On Tue, 6 Apr 2021 15:16:56 +0200
> > > > > > > Morten Kjærulff wrote:
> > > > > > > > When I run it from a windows command prompt, it works fine.
> > > > > > >
> > > > > > > In this case, did you run MQ client from cygwin shell
> > > > > > > in command prompt? Or run it in cmd.exe?
> > > > > >
> > > > > > what works is:
> > > > > > cmd.exe->bash->script->non-cygwin-mq-client.exe
> > > > > >
> > > > > > what fails is:
> > > > > > cmd.exe->bash->mintty->bash->script->non-cygwin-mq-client.exe
> > > > > >
> > > > > > also fails:
> > > > > > cmd.exe->bash->mintty->bash
> > > > > > and then
> > > > > > cmd /c bash -c 'script' # script->non-cygwin-mq-client.exe
> > > > >
> > > > > Thnaks for the report.
> > > > >
> > > > > What about:
> > > > > mintty->cmd /c bash->non-cygwin-mq-client.exe ?
> > > >
> > > > Do you mean your script starting mq-client by "script" ?
> > > > I meant /usr/bin/script by "script".
> > > >
> > > > > > cmd.exe->bash->script->non-cygwin-mq-client.exe
> > > >
> > > > If so, what about:
> > > > cmd.exe->bash->/usr/bin/script->(your script)->non-cygwin-mq-client.exe 
> > > > ?
> > > >
> > > > --
> > > > Takashi Yano
> > >
> > > Hi,
> > >
> > > I cooked the issue down to this.
> > >
> > > My script:
> > > $ cat tmq.sh
> > > #!/bin/sh
> > >
> > > export MQSERVER='BROWSE/TCP/mvs1(1414)'
> > > amqsbcgc Q
> > >
> > > amqsbcgc is a sample that comes with MQ:
> > > $ which amqsbcgc
> > > /cygdrive/c/Program Files/IBM/WebSphere MQ/tools/c/samples/bin64/amqsbcgc
> > >
> > > It is a C program:
> > > $ head /cygdrive/c/Program\ Files/IBM/WebSphere\ 
> > > MQ/tools/c/Samples/amqsbcg0.c
> > > /* @(#) MQMBID sn=p800-008-171121 su=_A5OAkM6qEeemCpCOEyy4yA
> > > pn=samples/c/amqsbcg0.c */
> > > /**/
> > > /**/
> > > /* Program name: AMQSBCG0 */
> > > /**/
> > > /* Description : Sample program to read and output the message*/
> > > /* descriptor fields, any other message properties*/
> > > /* and the message content of all the messages on a   */
> > > /* queue  */
> > > /*> >
> > > When I run it from a bash prompt, started with cmd.exe->bash.exe, I
> > > see correct output (2085 means Q not found, which means that we are
> > > connected ok):
> > > $ ./tmq.sh
> > >
> > > AMQSBCG0 - starts here
> > > **
> > >
> > >  MQOPEN - 'Q'
> > >  MQOPEN failed with CompCode:2, Reason:2085
> > >  MQDISC
> > >
> > > If I start mintty, I see:
> > > $ ./tmq.sh
> > >
> > > AMQSBCG0 - starts here
> > > **
> > >
> > >  MQCONNX failed with CompCode:2, Reason:2539
> > >
> > > I also see errors at the server side, which means that some sort of
> > > connection has been made, but it seems to be garbled.
> > >
> > > When we are "under" mintty it does not matter how I call amqsbcgc, it
> > > always fails, here is one example:
> > >
> > > $ ./tmq.sh
> > >
> > > AMQSBCG0 - starts here
> > > **
> > >
> > >  MQCONNX failed with CompCode:2, Reason:2539
> > >
> > > $ cmd
> > > Microsoft Windows [Version 10.0.17763.1817]
> > > (c) 2018 Microsoft Corporation. Alle rettigheder forbeholdes.
>
> Ah, you are using Win10 1809. Then the pseudo console should be
> supported.
>
> > > C:\mhome\mqadm>set MQSERVER=BROWSE/TCP/mvs1(1414)
> > > set MQSERVER=BROWSE/TCP/mvs1(1414)
> > >
> > > C:\mhome\mqadm>amqsbcgc Q
> > > amqsbcgc Q
> > >
> > > AMQSBCG0 - starts here
> > > **
> > >
> > >  MQCONNX failed with CompCode:2, Reason:2539
> >
> > In the log above in cmd, input command are echoed twice.
> > This happens when the pseudo console is not activated. Are you
> > using Win7 or old Win10? Or do you set CYGWIN=disable_pcon by
> > any chance?
> >
> > If you set CYGWIN=disable_pcon, please try unset it.
>
> Probably you set CYGWIN=disable_pcon in .bashrc or elsewhere.
> Please try to unset it.

I explicitly have a
set CYGWIN=
in the .bat file that initially invokes bash.
I do not set CYGWIN= elsewhere (just grep'd for it).

I change my test script to show empy CYGWIN=
$ cat tmq.sh
#!/bin/sh

export MQSERVER='BROWSE/TCP/mvs1(1414)'
echo CYGWIN=$CYGWIN
amqsbcgc Q

$ ./tmq.sh
CYGWIN=

AMQSBCG0 - starts here
**

 MQCONNX failed with CompCode:2, 

Re: Cannot run executable named setlang

[Takashi Yano via Cygwin]

On Thu, 8 Apr 2021 15:25:45 +0300
Orgad Shaneh wrote:
> Hi,
> 
> I cannot run an executable if it is named setlang (case insensitive).
> It exits with code 127.
> 
> Example:
> cp /bin/ls setlang
> ./setlang -> Error 127
> 
> I've noticed a difference in ldd output. cygwin dlls appear twice.
> 
> ldd /bin/ls:
> ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5)
> KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
> (0x7ffd9bbb)
> KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> (0x7ffd9b8e)
> cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
> cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ff81)
> cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ff83)
> 
> ldd setlang:
> ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5)
> KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
> (0x7ffd9bbb)
> KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> (0x7ffd9b8e)
> cygwin1.dll => /usr/bin/cygwin1.dll (0xc1)
> cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17)
> cygwin1.dll => /usr/bin/cygwin1.dll (0xc1)
> cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17)
> cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60)
> cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60)
> 
> Any idea what can cause this?

Isn't this the same issue with:
https://cygwin.com/pipermail/cygwin/2021-January/247508.html
?

-- 
Takashi Yano 
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: IBM MQ client application fails on latest cygwin

[Takashi Yano via Cygwin]

On Thu, 8 Apr 2021 20:16:00 +0900
Takashi Yano wrote:
> On Thu, 8 Apr 2021 08:04:26 +0200
> Morten Kjærulff wrote:
> > On Wed, Apr 7, 2021 at 1:04 PM Takashi Yano wrote:
> > >
> > > On Wed, 7 Apr 2021 19:56:24 +0900
> > > Takashi Yano wrote:
> > > > On Wed, 7 Apr 2021 11:32:59 +0200
> > > > Morten Kjærulff wrote:
> > > > > On Tue, Apr 6, 2021 at 4:37 PM Takashi Yano wrote:
> > > > > >
> > > > > > On Tue, 6 Apr 2021 15:16:56 +0200
> > > > > > Morten Kjærulff wrote:
> > > > > > > When I run it from a windows command prompt, it works fine.
> > > > > >
> > > > > > In this case, did you run MQ client from cygwin shell
> > > > > > in command prompt? Or run it in cmd.exe?
> > > > >
> > > > > what works is:
> > > > > cmd.exe->bash->script->non-cygwin-mq-client.exe
> > > > >
> > > > > what fails is:
> > > > > cmd.exe->bash->mintty->bash->script->non-cygwin-mq-client.exe
> > > > >
> > > > > also fails:
> > > > > cmd.exe->bash->mintty->bash
> > > > > and then
> > > > > cmd /c bash -c 'script' # script->non-cygwin-mq-client.exe
> > > >
> > > > Thnaks for the report.
> > > >
> > > > What about:
> > > > mintty->cmd /c bash->non-cygwin-mq-client.exe ?
> > >
> > > Do you mean your script starting mq-client by "script" ?
> > > I meant /usr/bin/script by "script".
> > >
> > > > > cmd.exe->bash->script->non-cygwin-mq-client.exe
> > >
> > > If so, what about:
> > > cmd.exe->bash->/usr/bin/script->(your script)->non-cygwin-mq-client.exe ?
> > >
> > > --
> > > Takashi Yano
> > 
> > Hi,
> > 
> > I cooked the issue down to this.
> > 
> > My script:
> > $ cat tmq.sh
> > #!/bin/sh
> > 
> > export MQSERVER='BROWSE/TCP/mvs1(1414)'
> > amqsbcgc Q
> > 
> > amqsbcgc is a sample that comes with MQ:
> > $ which amqsbcgc
> > /cygdrive/c/Program Files/IBM/WebSphere MQ/tools/c/samples/bin64/amqsbcgc
> > 
> > It is a C program:
> > $ head /cygdrive/c/Program\ Files/IBM/WebSphere\ 
> > MQ/tools/c/Samples/amqsbcg0.c
> > /* @(#) MQMBID sn=p800-008-171121 su=_A5OAkM6qEeemCpCOEyy4yA
> > pn=samples/c/amqsbcg0.c */
> > /**/
> > /**/
> > /* Program name: AMQSBCG0 */
> > /**/
> > /* Description : Sample program to read and output the message*/
> > /* descriptor fields, any other message properties*/
> > /* and the message content of all the messages on a   */
> > /* queue  */
> > /*> 
> > When I run it from a bash prompt, started with cmd.exe->bash.exe, I
> > see correct output (2085 means Q not found, which means that we are
> > connected ok):
> > $ ./tmq.sh
> > 
> > AMQSBCG0 - starts here
> > **
> > 
> >  MQOPEN - 'Q'
> >  MQOPEN failed with CompCode:2, Reason:2085
> >  MQDISC
> > 
> > If I start mintty, I see:
> > $ ./tmq.sh
> > 
> > AMQSBCG0 - starts here
> > **
> > 
> >  MQCONNX failed with CompCode:2, Reason:2539
> > 
> > I also see errors at the server side, which means that some sort of
> > connection has been made, but it seems to be garbled.
> > 
> > When we are "under" mintty it does not matter how I call amqsbcgc, it
> > always fails, here is one example:
> > 
> > $ ./tmq.sh
> > 
> > AMQSBCG0 - starts here
> > **
> > 
> >  MQCONNX failed with CompCode:2, Reason:2539
> > 
> > $ cmd
> > Microsoft Windows [Version 10.0.17763.1817]
> > (c) 2018 Microsoft Corporation. Alle rettigheder forbeholdes.

Ah, you are using Win10 1809. Then the pseudo console should be
supported.

> > C:\mhome\mqadm>set MQSERVER=BROWSE/TCP/mvs1(1414)
> > set MQSERVER=BROWSE/TCP/mvs1(1414)
> > 
> > C:\mhome\mqadm>amqsbcgc Q
> > amqsbcgc Q
> > 
> > AMQSBCG0 - starts here
> > **
> > 
> >  MQCONNX failed with CompCode:2, Reason:2539
> 
> In the log above in cmd, input command are echoed twice.
> This happens when the pseudo console is not activated. Are you
> using Win7 or old Win10? Or do you set CYGWIN=disable_pcon by
> any chance?
> 
> If you set CYGWIN=disable_pcon, please try unset it.

Probably you set CYGWIN=disable_pcon in .bashrc or elsewhere.
Please try to unset it.

-- 
Takashi Yano 
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Cannot run executable named setlang

[Orgad Shaneh via Cygwin]

Hi,

I cannot run an executable if it is named setlang (case insensitive).
It exits with code 127.

Example:
cp /bin/ls setlang
./setlang -> Error 127

I've noticed a difference in ldd output. cygwin dlls appear twice.

ldd /bin/ls:
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5)
KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
(0x7ffd9bbb)
KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
(0x7ffd9b8e)
cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ff81)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ff83)

ldd setlang:
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5)
KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
(0x7ffd9bbb)
KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
(0x7ffd9b8e)
cygwin1.dll => /usr/bin/cygwin1.dll (0xc1)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17)
cygwin1.dll => /usr/bin/cygwin1.dll (0xc1)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60)

Any idea what can cause this?

Thanks,
- Orgad
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: IBM MQ client application fails on latest cygwin

[Takashi Yano via Cygwin]

On Thu, 8 Apr 2021 08:04:26 +0200
Morten Kjærulff wrote:
> On Wed, Apr 7, 2021 at 1:04 PM Takashi Yano wrote:
> >
> > On Wed, 7 Apr 2021 19:56:24 +0900
> > Takashi Yano wrote:
> > > On Wed, 7 Apr 2021 11:32:59 +0200
> > > Morten Kjærulff wrote:
> > > > On Tue, Apr 6, 2021 at 4:37 PM Takashi Yano wrote:
> > > > >
> > > > > On Tue, 6 Apr 2021 15:16:56 +0200
> > > > > Morten Kjærulff wrote:
> > > > > > When I run it from a windows command prompt, it works fine.
> > > > >
> > > > > In this case, did you run MQ client from cygwin shell
> > > > > in command prompt? Or run it in cmd.exe?
> > > >
> > > > what works is:
> > > > cmd.exe->bash->script->non-cygwin-mq-client.exe
> > > >
> > > > what fails is:
> > > > cmd.exe->bash->mintty->bash->script->non-cygwin-mq-client.exe
> > > >
> > > > also fails:
> > > > cmd.exe->bash->mintty->bash
> > > > and then
> > > > cmd /c bash -c 'script' # script->non-cygwin-mq-client.exe
> > >
> > > Thnaks for the report.
> > >
> > > What about:
> > > mintty->cmd /c bash->non-cygwin-mq-client.exe ?
> >
> > Do you mean your script starting mq-client by "script" ?
> > I meant /usr/bin/script by "script".
> >
> > > > cmd.exe->bash->script->non-cygwin-mq-client.exe
> >
> > If so, what about:
> > cmd.exe->bash->/usr/bin/script->(your script)->non-cygwin-mq-client.exe ?
> >
> > --
> > Takashi Yano
> 
> Hi,
> 
> I cooked the issue down to this.
> 
> My script:
> $ cat tmq.sh
> #!/bin/sh
> 
> export MQSERVER='BROWSE/TCP/mvs1(1414)'
> amqsbcgc Q
> 
> amqsbcgc is a sample that comes with MQ:
> $ which amqsbcgc
> /cygdrive/c/Program Files/IBM/WebSphere MQ/tools/c/samples/bin64/amqsbcgc
> 
> It is a C program:
> $ head /cygdrive/c/Program\ Files/IBM/WebSphere\ MQ/tools/c/Samples/amqsbcg0.c
> /* @(#) MQMBID sn=p800-008-171121 su=_A5OAkM6qEeemCpCOEyy4yA
> pn=samples/c/amqsbcg0.c */
> /**/
> /**/
> /* Program name: AMQSBCG0 */
> /**/
> /* Description : Sample program to read and output the message*/
> /* descriptor fields, any other message properties*/
> /* and the message content of all the messages on a   */
> /* queue  */
> /*
> When I run it from a bash prompt, started with cmd.exe->bash.exe, I
> see correct output (2085 means Q not found, which means that we are
> connected ok):
> $ ./tmq.sh
> 
> AMQSBCG0 - starts here
> **
> 
>  MQOPEN - 'Q'
>  MQOPEN failed with CompCode:2, Reason:2085
>  MQDISC
> 
> If I start mintty, I see:
> $ ./tmq.sh
> 
> AMQSBCG0 - starts here
> **
> 
>  MQCONNX failed with CompCode:2, Reason:2539
> 
> I also see errors at the server side, which means that some sort of
> connection has been made, but it seems to be garbled.
> 
> When we are "under" mintty it does not matter how I call amqsbcgc, it
> always fails, here is one example:
> 
> $ ./tmq.sh
> 
> AMQSBCG0 - starts here
> **
> 
>  MQCONNX failed with CompCode:2, Reason:2539
> 
> $ cmd
> Microsoft Windows [Version 10.0.17763.1817]
> (c) 2018 Microsoft Corporation. Alle rettigheder forbeholdes.
> 
> C:\mhome\mqadm>set MQSERVER=BROWSE/TCP/mvs1(1414)
> set MQSERVER=BROWSE/TCP/mvs1(1414)
> 
> C:\mhome\mqadm>amqsbcgc Q
> amqsbcgc Q
> 
> AMQSBCG0 - starts here
> **
> 
>  MQCONNX failed with CompCode:2, Reason:2539

In the log above in cmd, input command are echoed twice.
This happens when the pseudo console is not activated. Are you
using Win7 or old Win10? Or do you set CYGWIN=disable_pcon by
any chance?

If you set CYGWIN=disable_pcon, please try unset it.

-- 
Takashi Yano 
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Updating pngcheck

[Lemures Lemniscati via Cygwin-apps]

https://sourceware.org/pipermail/cygwin/2021-March/248073.html
On Sat, 13 Mar 2021 22:33:27 +0900, Lemures Lemniscati
> Hi!
> 
> Is there any plan to update pngcheck?
> 
> Currently, we have pngcheck 2.3.0-1.
> https://www.cygwin.com/packages/summary/pngcheck-src.html
> 
> And, recently, some vulnerabilities have been fixed in its upstream.
> http://www.libpng.org/pub/png/apps/pngcheck.html

Hi, Jari Aalto.

Here is a cygport file, which could be a candidate for pngcheck-3.0.2.

Regards,

Lem


NAME="pngcheck"
VERSION=3.0.2
RELEASE=1
CATEGORY="Graphics"
SUMMARY="PNG file format checker"
DESCRIPTION="\
pngcheck verifies the integrity of PNG, JNG and MNG files (by checking
the internal 32-bit CRCs, a.k.a. checksums, and decompressing the image
data); it can optionally dump almost all of the chunk-level information
in the image in human-readable form. For example, it can be used to
print the basic statistics about an image (dimensions, bit depth, etc.);
to list the color and transparency info in its palette (assuming it has
one); or to extract the embedded text annotations.
This is a command-line program with batch capabilities.
"
HOMEPAGE="http://www.libpng.org/pub/png/apps/pngcheck.html;
SRC_URI="http://www.libpng.org/pub/png/src/pngcheck-${VERSION}.tar.gz;


BUILD_REQUIRES="\
  zlib-devel\
"


_CYGPORT_RESTRICT_postinst_doc_=1

src_compile () {
  cd ${B}
  lndirs
  cygmake -f Makefile.unx CC=${CC} CFLAGS="${CFLAGS}"
}

src_install () {
  cd ${B}
  dobin *.exe

  doman *.1
  dodoc CHANGELOG* LICENSE* README*

  doman gpl/*.1
  docinto gpl
  dodoc gpl/COPYING*
}

RE: X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win

[Lemke, Michael SF/HZA-ZIC2]

On April 7, 2021 8:47 PM Achim Gratz wrote:
>L A Walsh writes:
>> If I move the windows cursor to another editor window in X11,
>> the blinking cursor moves to the new window, but if I move
>> it to a native window, the blinking doesn't stop.
>>
>> Has this always been this way?
>
>Windows never had "focus follows mouse" in any version I can remember.
>

It has had it since Windows95 or so and it is my default setting on 
any PC I use. Attached is a little program I wrote a long time ago that 
turns the feature on or off. Compile with `gcc xmouse.c` or mingw.

Something like this was included in the Windows PowerToys as xmouse.exe.

Michael
#define WINVER 0x0500
#include 
#include 
 
/* gcc -mno-cygwin -mwindows  ... */
 
void ErrorExit(LPTSTR lpszFunction, DWORD dw) 
{ 
LPVOID lpMsgBuf;
LPVOID lpDisplayBuf;
//DWORD dw = GetLastError(); 
 
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER | 
FORMAT_MESSAGE_FROM_SYSTEM,
NULL,
dw,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) ,
0, NULL );
 
lpDisplayBuf = LocalAlloc(LMEM_ZEROINIT, 
strlen(lpMsgBuf)+strlen(lpszFunction)+40); 
wsprintf(lpDisplayBuf, 
"%s failed with error %d: %s", 
lpszFunction, dw, lpMsgBuf); 
MessageBox(NULL, lpDisplayBuf, "Error", MB_OK); 
 
LocalFree(lpMsgBuf);
LocalFree(lpDisplayBuf);
ExitProcess(dw); 
}
 
 
 
int WINAPI WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow) {
//int main (void) {
 
   BOOL xmouse = FALSE;
 
   DWORD status;
 
   if( !(status=SystemParametersInfo( SPI_GETACTIVEWINDOWTRACKING,
  0,
  ,
  0
 )) ) {
  ErrorExit("Get mouse status",status);
   }

   if( !(status=SystemParametersInfo( SPI_SETACTIVEWNDTRKZORDER,
  0,
  (PVOID)FALSE,
  SPIF_UPDATEINIFILE || 
SPIF_SENDWININICHANGE
)) ) {
  ErrorExit("Set mouse status",status);
   }

   if( !(status=SystemParametersInfo( SPI_SETACTIVEWNDTRKTIMEOUT,
  0,
  (PVOID)100,
  SPIF_UPDATEINIFILE || 
SPIF_SENDWININICHANGE
)) ) {
  ErrorExit("Set mouse status",status);
   }

   xmouse = !xmouse;
   if( !(status=SystemParametersInfo( SPI_SETACTIVEWINDOWTRACKING,
  0,
  (PVOID)xmouse,
  SPIF_UPDATEINIFILE || 
SPIF_SENDWININICHANGE
)) ) {
  ErrorExit("Set mouse status",status);
   }
   printf( "X mouse is now %s.\n", xmouse ? "on" : "off" );
 
   return 0;
}
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win

[L A Walsh]

On 2021/04/07 11:46, Achim Gratz wrote:

L A Walsh writes:
  

If I move the windows cursor to another editor window in X11,
the blinking cursor moves to the new window, but if I move
it to a native window, the blinking doesn't stop.

Has this always been this way?



Windows never had "focus follows mouse" in any version I can remember.
  

It's been in every version since at least Win98, but required
either some special utility to set it or editing the registry.

They do have a focus follows mouse setting, but one that always raises
the the window in question, which can still duplicate the problem
of switching to a win-window where it gets focus and X11 may not
know it.

First thing I have on my desktop is 1-click to activate -- same as
web settings.  I have RSI issues and trying to double click on things
really causes the irritation level to go up quickly.  That means
I can select by hovering -- that setting is in the folder options
under Tools when you look at a folder.  Single-click to open items, and
underline icon titles consistent w/my browser.

In the Mouse or Ease-of-access settings, one can choose to activate a window
by hovering over it with the mouse.

The one that still takes a registry setting since Win98 days. is
true focus follows mouse w/o the window being raised.  There's still a
configurable delay before the focus changes -- usually 175-250ms, or the
moving your cursor across the screen would cause a bunch of windows to
raise in the default configuration.  The 175 works for me.

But it has to do with HKEY_CURRENT_USER\Control 
Panel\Desktop\UserPreferencesMask.

It's a 8-byte binary value.  I always see the low-order nibble of the first
byte set to '1'(like 0xb1). 



So that hasn't changed for me since win98 but whether or not xprograms
have blinking cursors that stop blinking or hide when you type are things
that have been added in that time, but I've never seen the cursor keep
going like I do most recently, when the focus goes off the X-window to
a Win-window.

I notice you zoomed in on windows being able to change focus by moving
the cursor to a different window w/no click involved.  Did something change
in that area in X11 where it was changed to need to see a click before
changing?

Thanks!



Regards,
Achim.
  

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

RE: AF_UNIX/SOCK_DGRAM is dropping messages

[Kristian Ivarsson via Cygwin]

>  Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems
> to
>  drop messages or at least they are not received in the same
>  order they are  sent
> 
>  [snip]
> 
> > Thanks for the test case.  I can confirm the problem.  I'm not
> > familiar enough with the current AF_UNIX implementation to debug
> > this easily.  I'd rather spend my time on the new implementation
> > (on the topic/af_unix branch).  It turns out that your test case
> > fails there too, but in a completely different way, due to a bug
> > in sendto for datagrams.  I'll see if I can fix that bug and then try 
> > again.
> >
> > Ken
> 
>  Ok, too bad it wasn't our own code base but good that the "mystery"
>  is verified
> 
>  I finally succeed to build topic/af_unix (after finding out what
>  version of zlib was needed), but not with -D__WITH_AF_UNIX to
>  CXXFLAGS though and thus I haven’t tested it yet
> 
>  Is it sufficient to add the define to the "main" Makefile or do you
>  have to add it to all the Makefile:s ? I guess I can find out
>  though
> >>>
> >>> I do it on the configure line, like this:
> >>>
> >>>../af_unix/configure CXXFLAGS="-g -O0 -D__WITH_AF_UNIX" --
> prefix=...
> >>>
>  Is topic/af_unix fairly up to date with master branch ?
> >>>
> >>> Yes, I periodically cherry-pick commits from master to topic/af_unix.
> >>> I'lldo that again right now.
> >>>
>  Either way, I'll be glad to help out testing topic/af_unix
> >>>
> >>> Thanks!
> >>
> >> I've now pushed a fix for that sendto bug, and your test case runs
> >> without error on the topic/af_unix branch.
> >
> > It seems like the test-case do work now with topic/af_unix in blocking
> > mode, but when using non-blocking (with MSG_DONTWAIT) there are
> some
> > issues I think
> >
> > 1. When the queue is empty with non-blocking recv(), errno is set to
> > EPIPE but I think it should be EAGAIN (or maybe the pipe is getting
> > broken for real of some reason ?)
> >
> > 2. When using non-blocking recv() and no message is written at all, it
> > seems like recv() blocks forever
> >
> > 3. Using non-blocking recv() where the "client" does send less than
> > "count" messages, sometimes recv() blocks forever (as well)
> >
> >
> > My naïve analysis of this is that for the first issue (if any) the
> > wrong errno is set and for the second issue it blocks if no sendto()
> > is done after the first recv(), i.e. nothing kicks the "reader thread"
> > in the butt to realise the queue is empty. It is not super clear
> > though what POSIX says about creating blocking descriptors and then
> > using non-blocking-flags with recv(), but this works in Linux any way
> 
> The explanation is actually much simpler.  In the recv code where a bound
> datagram socket waits for a remote socket to connect to the pipe, I simply
> forget to handle MSG_DONTWAIT.  I've pushed a fix.  Please retest.

I tested it and now it seems like we get EAGAIN when there's no msg on the 
queue, but it seems like the client is blocked as well and that it cannot write 
any more messages until it is consumed by the server, so the af_unix.cpp 
test-client end prematurely

If using sendto() with MSG_DONTWAIT as well, that is getting a EAGAIN, but the 
socket in it self is not a non-blocking socket, it is just the recv() that is 
done in a non-blocking fashion

As I said earlier, it's a bit fuzzy (or at least for me) what POSIX mean by 
non/blocking descriptors combined with non/blocking operations, but as far as I 
understand, it should be possible to use blocking sendto()and messages should 
be written (as long as some buffer is not filled) at the same time someone is 
doing non-blocking recv()

What is your take on this ?

> I should add that in all my work so far on the topic/af_unix branch, I've
> thought mainly about stream sockets.  So there may still be things remaining
> to be implemented for the datagram case.
> 
> Ken
#include 
#include 

#undef AF_UNIX
#define AF_UNIX 31

#include 

#include 
#include 
#include 

#include 
#include 


// $ g++ --std=gnu++17 af_unix.cpp

const char* const path = "address";
const int count = 10;
const int size = BUFSIZ * 1;

int client()
{
const int fd = socket( AF_UNIX, SOCK_DGRAM, 0);

if( fd == -1)
{
perror( "socket error");
return -1;
}

struct sockaddr_un address{};

strcpy( address.sun_path, path);
address.sun_family = AF_UNIX;

char buffer[size] = {};

for( int idx = 0; idx < count; ++idx)
{
memcpy( buffer, , sizeof idx);

fprintf( stdout, "client idx: %d\n", idx);

const ssize_t result = sendto( fd, buffer, size, 0, (struct 
sockaddr*), sizeof address);

// Assume the whole chunk can be sent
if( result != size)
{
perror( "sendto error");
return -1;
}
}

close( fd);
return 0;
}

int server()
{