Setup installed to c:/cygwin/usr/bin

[Norton Allen]

I have spent some time looking for a reference to this problem, but have not
come across it.

OS: Win2K
Installed cygwin via setup (both download and install), pretty much accepted the
defaults. Installed to C:\cygwin. Worked well.

Returned a few weeks later to add a few more packages. Setup appeared
to work well, but the new packages did not appear in /bin. Upon investigation,
I located the files in C:\cygwin\usr\bin. I moved them into C:\cygwin\bin,
and things seem to be working OK.

Why did they go into C:\cygwin\usr\bin? The standard global mounts are
there under HKLM.

Below is a portion of setup.log.full showing the installation of the man package.
What's with the '///'?

Norton Allen

2002/11/14 19:51:20 Installing file://C:\home\nort-root\My 
Documents\cygpkg/ftp%3a%2f%2fplanetmirror.com%2fpub%2fsourceware%2fcygwi
n/release/man/man-1.5g-2.tar.gz
For filefile://C:\home\nort-root\My 
Documents\cygpkg/ftp%3a%2f%2fplanetmirror.com%2fpub%2fsourceware%2fcygwi
n/release/man/man-1.5g-2.tar.gz ini digest iscc4e32fd649ff255ddd2fe2b4591a002 file 
digest is cc4e32fd649ff255ddd2fe2b4591a002
Installing file cygfile:///usr/
Installing file cygfile:///usr/bin/
Installing file cygfile:///usr/bin/apropos
Installing file cygfile:///usr/bin/man.exe
Installing file cygfile:///usr/bin/man2html.exe
Installing file cygfile:///usr/bin/whatis
Installing file cygfile:///usr/lib/
Installing file cygfile:///usr/lib/man.conf
Installing file cygfile:///usr/man/
Installing file cygfile:///usr/man/man1/
Installing file cygfile:///usr/man/man1/apropos.1
Installing file cygfile:///usr/man/man1/man.1
Installing file cygfile:///usr/man/man1/man2html.1
Installing file cygfile:///usr/man/man1/whatis.1
Installing file cygfile:///usr/man/man5/
Installing file cygfile:///usr/man/man5/man.conf.5
Installing file cygfile:///usr/man/man8/
Installing file cygfile:///usr/man/man8/makewhatis.8
Installing file cygfile:///usr/sbin/
Installing file cygfile:///usr/sbin/makewhatis
compress::~compress called
compress::~compress called
2002/11/14 19:51:27 mbox note: Installation Complete
2002/11/14 19:51:28 Ending cygwin install


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup installed to c:/cygwin/usr/bin

[Norton Allen]

On 15 Nov 2002 at 11:37, Igor Pechtchanski wrote:
> The above is standard setup behavior.  Setup simply unpacks the files
> from a package to the directories from which they have been packaged. 
> It also reads the mount table and resolves directory references
> (cygfile:// is setup's way of indicating the file is in the cygwin
> posix directory tree, the third '/' is actually the root directory).
> 
> In your case, setup doesn't seem to resolve /usr/bin to c:\cygwin\bin
> (a standard mount).  Please post the output of mount to the list.

  C:\cygwin\bin on /usr/bin type system (binmode)
  C:\cygwin\lib on /usr/lib type system (binmode)
  C:\cygwin on / type system (binmode)
  c: on /cygdrive/c type user (binmode,noumount)
  d: on /cygdrive/d type user (binmode,noumount)
  i: on /cygdrive/i type user (binmode,noumount)
  k: on /cygdrive/k type user (binmode,noumount)
  l: on /cygdrive/l type user (binmode,noumount)
  n: on /cygdrive/n type user (binmode,noumount)
  o: on /cygdrive/o type user (binmode,noumount)
  p: on /cygdrive/p type user (binmode,noumount)
  q: on /cygdrive/q type user (binmode,noumount)
  s: on /cygdrive/s type user (binmode,noumount)
  x: on /cygdrive/x type user (binmode,noumount)
  y: on /cygdrive/y type user (binmode,noumount)
  z: on /cygdrive/z type user (binmode,noumount)

> Also, if your mounts turn out to be user mounts, make sure you ran
> setup as the same user that you have cygwin installed for.  Or, better
> yet, remount all standard mounts as system mounts.

It is possible that I was a logged in as a different user for the second install,
but it isn't clear how that would affect setup, since these are system mounts.

-Norton


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup installed to c:/cygwin/usr/bin

[Norton Allen]

Igor Pechtchanski wrote:
> 
> On Fri, 15 Nov 2002, Norton Allen wrote:
> > It is possible that I was a logged in as a different user for the second
> > install, but it isn't clear how that would affect setup, since these are
> > system mounts.
> 
> Just a WAG, but does that other user have user mounts that maybe override
> the system ones?  Try rerunning setup as the same user that did the first
> install, and reinstall, say, the 'man' package.  See if it works for that
> user...

  The other user does not have any other user mounts, so that's not
  it, but I do find that this state of events is reproducable and
  is not a problem for the original installer, but is a problem for
  another user installing additional packages. (i.e. I reinstalled
  man twice, once as the original installer and once as the other
  user. The first did what it was supposed to do, the second
  apparently ignored the system mounts).

> I'm assuming, of course, that you ran 'mount' as the original installing
> user.

  I never explicitly ran mount. Presumably it was run by setup
  during the original install.

   -Norton

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup installed to c:/cygwin/usr/bin

[Norton Allen]

Igor Pechtchanski wrote:
> Hmm, don't know if there is a way in NT to restrict access to HKLM
> registry entries, but it certainly sounds like the second user doesn't see
> these entries...  This might not matter, but is either of them a domain
> user, by any chance?
>
> > > I'm assuming, of course, that you ran 'mount' as the original installing
> > > user.
> >
> >   I never explicitly ran mount. Presumably it was run by setup
> >   during the original install.
> >-Norton
> 
> I meant the 'mount' the output of which you posted to the list.  It would
> be interesting to see the output of 'mount' run by the second user as
> well.

  The mount output I posted was for the second user (not the
  original installer), but the mount output for the original
  installer looks identical. Neither is a domain user.

  I just noticed that the original installer does not have
  any entry for Cygwin under HKEY_USERS whereas the other
  user does. Curious.
-Norton

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup installed to c:/cygwin/usr/bin

[Norton Allen]

Igor Pechtchanski wrote:
> 
> On Fri, 15 Nov 2002, Norton Allen wrote:
> >   I just noticed that the original installer does not have
> >   any entry for Cygwin under HKEY_USERS whereas the other
> >   user does. Curious.
> > -Norton
> 
> Ah, there's your problem!  This was the guess I expressed two messages
> ago:

  Right, but the output of mount claims this has no effect on
  the actual mounts. And certainly as the other user (that
  has an HKEY_USERS entry) I certainly see /bin and /usr/bin
  as the same directory, and I don't see what is in
  c:\cygwin\usr\bin at all. [These points are not a contradicition
  to what you're saying, just reiterating the facts.]

> > Just a WAG, but does that other user have user mounts that maybe
> > override the system ones?
> 
> If the output of mount is identical, then there may be a bug in mount
> processing, as user mounts should take precedence over system ones.  In
> any case, it looks like setup and cygwin view user and system mounts with
> different precedences.  Anyone care to comment on that?

  I would agree with that. It appears to me that setup fails to see
  the system mounts that cygwin sees. -Norton

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ -d ' ' ] && echo yes

[Norton Allen]

Inasmuch as such a directory does not exist, this should
not give any output:

  [ -d ' ' ] && echo yes

I suspect this is not a feature of bash, but more deeply
buried, since

  ls -ld ' '

believes ' ' is a directory and

  ls -la ' '

will give you 'total 0' (no . or .. entries).
It also believes any name consisting of all spaces is
a directory.

On the plus side, you can't create a real directory or
file named ' ', because it thinks one already exists.

  -Norton Allen
  

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ -d ' ' ] && echo yes

[Norton Allen]

Elfyn McBratney wrote:
> 
> > Inasmuch as such a directory does not exist, this should
> > not give any output:
> >
> >   [ -d ' ' ] && echo yes
> >
> > I suspect this is not a feature of bash, but more deeply
> > buried, since
> >
> >   ls -ld ' '
> >
> > believes ' ' is a directory and
> 
> In a way it is. ' ' or '   ' no matter how many spaces is a loopback
> to the current directory AFAIK. If you try to cd to ' ' or '' you will
> see the pwd is /path/directory/you/are/in/.

Are you saying it's a feature? If so, a feature of cygwin or
of Windows? Under the Windows Command Prompt, cd " " does not
complain, and leaves you in the current directory as you
describe, but dir " " gives an error. This is certainly
not how it works under other OSes.

 -Norton
 

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ -d ' ' ] && echo yes

[Norton Allen]

Elfyn McBratney wrote:
> 
> > Are you saying it's a feature? If so, a feature of cygwin or
> > of Windows? Under the Windows Command Prompt, cd " " does not
> > complain, and leaves you in the current directory as you
> > describe, but dir " " gives an error. This is certainly
> > not how it works under other OSes.
> 
> 
> I'm pretty sure it's a feature of SUSv3... Or one of the other POSIXy
> standards.
> 
> However I've been working for hours so my brain is fried and may be spewing
> out random recollections '-)

  FWIW, I've just tested on Linux (of some flavor) and OpenBSD,
  and neither thinks ' ' is a directory.
  
  In any event, I'd like to figure out whether it's a bug or
  a feature under Cygwin so I can move forward.
  
   -Norton
   

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ -d ' ' ] && echo yes

[Norton Allen]

Max Bowsher wrote:
> 
> Norton Allen wrote:
> > Elfyn McBratney wrote:
> >>
> >>> Are you saying it's a feature? If so, a feature of cygwin or
> >>> of Windows? Under the Windows Command Prompt, cd " " does not
> >>> complain, and leaves you in the current directory as you
> >>> describe, but dir " " gives an error. This is certainly
> >>> not how it works under other OSes.
> >>
> >>
> >> I'm pretty sure it's a feature of SUSv3... Or one of the other POSIXy
> >> standards.
> >>
> >> However I've been working for hours so my brain is fried and may be
> >> spewing out random recollections '-)
> >
> >   FWIW, I've just tested on Linux (of some flavor) and OpenBSD,
> >   and neither thinks ' ' is a directory.
> >
> >   In any event, I'd like to figure out whether it's a bug or
> >   a feature under Cygwin so I can move forward.
> 
> It's a bug/feature in Windows. Trying to manipulate such a directory in an
> ordinary cmd shell or in explorer produces spurious error messages and/or
> silent failiures.
> 
> I.e. it falls into the same category as 'aux' and 'foo...' - file names
> which Windows simply won't do.

OK, thanks for the info. I was familiar with the oddities of aux, et. al,
but had not encountered the space thingy. -Norton


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

cygpcre.dll missing after update

[Norton Allen]

Greetings,

  I just updated to 1.5.5, and subsequently, whenever I start
  up bash I get an error stating that cygpcre.dll cannot
  be found. I perused the archives here and saw a few
  references to this problem but no clear solution.

  I tried re-installing the pcre package and installing
  earlier versions of it via setup to no avail.

  I found /bin/cygpcre-0.dll and copied it to cygpcre.dll
  and the problem "went away," but I rather doubt this
  is the correct solution.

  Any suggestions would be most welcome.

  For that matter, if anyone can point me to a reference that
  describes how dll's are named and/or located at runtime,
  that would make me more effective as well.

   -Norton Allen

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

RE: Bug in dlopen() (or following) code in Cygwin1.dll v 1.5.19-4

[Norton Allen]

I just spent a full day tracking down something that is
either very similar or I'm getting thrown off by the
same red herring. [The text here was pulled from a
post on the cygwin-patches list, but the discussion was
redirected here]


On Thu, Mar 02, 2006 at 10:11:39AM -0800, Gary Zablackis wrote:

Since installing Cygwin1.dll v 1.5.19-4, I have a problem with the
computer algebra system SAGE dying at startup with no error messages
(i.e.  I get returned to the bash prompt with no messages of any sort).
I tracked the problem down to verifyable_object_isvalid() in
winsup/thread.cc.  The added the check below corrects this problem:

CHANGELOG:
2006-03-02 Gary Zablackis [EMAIL PROTECTED]
* thread.cc (verifyable_object_isvalid): check for
NULL object or reference


The "efault.faulted()" two lines above your change is supposed to catch
NULL dereferences.


Whoa! This looks like voodoo action-at-a-distance. efault.faulted()
doesn't even get passed the pointer to know whether or not it's
NULL. I'm guessing that it must assume that this function
(verifyable_object_isvalid) will *only* be called with a
particular class of pointers. Is any of this documented anywhere?

Although efault.faulted() is supposed to catch the NULL dereferences,
is there a big downside to double-checking afterwards (particularly
if there are cases where it doesn't catch them?)


 I suspect that you were probably misled by the fact
that gdb might show a SEGV in this function but that is to be expected
(see lots of discussion in the cygwin mailing list about this) and there
are patches pending for gdb which will work around this behavior.


[I did try to find this discussion, but failed. Any hints on what
the subject line was?] FWIW, I also have symptoms of gdb dropping
into the background on certain 'next' commands. Issuing 'fg' gets
me back to where I was going.

Norton Allen


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

RE: Bug in dlopen() (or following) code in Cygwin1.dll v 1.5.19-4

[Norton Allen]

Ah, got it--it behaves like exception handling, but it
doesn't *look* like exception handling. Seems like a
good place to add some comments! ;-) (Offer to submit
a patch, but seeing as I had to ask, I doubt I'm the
right person to do so.) Thanks for clearing this up
for me!

-Norton

On 16 March 2006, Dave Korn wrote:

On 16 March 2006 15:48, Norton Allen wrote:



* thread.cc (verifyable_object_isvalid): check for
NULL object or reference


The "efault.faulted()" two lines above your change is supposed to catch
NULL dereferences.


Whoa! This looks like voodoo action-at-a-distance. 


  Exception handling does that :)  See also setjmp/longjmp.


efault.faulted()
doesn't even get passed the pointer to know whether or not it's
NULL. 


  errno doesn't get passed any pointers, but it still often ends up returning
'EINVAL' when the pointer you pass to a routine is null


Although efault.faulted() is supposed to catch the NULL dereferences,


  Nope, the exception handling is supposed to catch the NULL deref, and set an
error code which is then returned by efault.faulted.

  Take a /look/ at the source for myfault::faulted in cygtls.h, it calls out
to _cygtls::setup_fault, which calls _sjfault, which appears to be a q'n'd
hacked-up version of setjmp in a context where it's going to get called back
by an SEH handler.  So IIUIC, calling 'efault.faulted' will catch any
exception that happens from the point of the call until the point where the
efault object goes out of scope and gets destructed and will cause execution
to jump back to the if... clause.






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

Re: Bug in dlopen() (or following) code in Cygwin1.dll v 1.5.19-4

[Norton Allen]

Eric Blake wrote:

Top-posting reformatted - cygwin.com/acronyms/#TOFU



The "efault.faulted()" two lines above your change is supposed to catch
NULL dereferences.



 Take a /look/ at the source for myfault::faulted in cygtls.h, it calls out
to _cygtls::setup_fault, which calls _sjfault, which appears to be a q'n'd
hacked-up version of setjmp in a context where it's going to get called back
by an SEH handler.  So IIUIC, calling 'efault.faulted' will catch any
exception that happens from the point of the call until the point where the
efault object goes out of scope and gets destructed and will cause execution
to jump back to the if... clause.




Ah, got it--it behaves like exception handling, but it
doesn't *look* like exception handling. Seems like a
good place to add some comments! ;-) (Offer to submit
a patch, but seeing as I had to ask, I doubt I'm the
right person to do so.) Thanks for clearing this up
for me!



The only logical place for such a comment would be at the source
for myfault::faulted, as the idiom of efault.faulted() appears
throughout cygwin.


Agreed.


One more thing to be aware of - the reason cygwin uses
this (IMHO very slick) feature of C++ is that it is more efficient
to assume that code will not fault, and blindly deference
pointers with the minimal overhead of setting up the
setjmp buffer with a pre-installed exception handler already
prepared for this usage, than it is to use a syscall to Window's
routines to validate every pointer before dereferencing it.  On
the exceptional case that the code actually did get passed a
bad pointer, the overhead of the exception handling and longjmp
are slower, but that is okay since it is the exception.

So maybe it looks weird.  C++ is like that!


I would argue that this isn't a feature of C++ in that it cannot be 
implemented within the language but must use assembler for a

specific architecture, but I agree that the paradigm of not needing
to check every case is very cool.

-Norton

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

Creating a custom Cygwin package server

[Norton Allen]

The documentation here:

http://sourceware.org/cygwin-apps/package-server.html

suggests it might be possible to set up a custom Cygwin
package server to install a custom app, but it also says
the necessary tools are not available. Is it possible to
do this? Is there another approach that is more highly
recommended for distribution of a custom app? (one too
specific to warrant inclusion in the main archive.)

Norton Allen

p.s. I apologize if this subject has been revisited
frequently. I just spent about half an hour searching
through the e-mail archives without coming up with
any clues.

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

Re: Creating a custom Cygwin package server

[Norton Allen]

Joshua Daniel Franklin wrote:


Just be aware that you are entering unsupported territory,
and get upset from:

http://xarch.tu-graz.ac.at/publ/cygwin/upset

"Unsupported" means don't ask this mailing list if you have
problems. A good alternative might be:


You can also use "genini" which is meant to be used in place of upset
and is still supported, or rather it still exists in sourceware CVS.

Brian


Thank you both for your responses. I appreciate the meaning of
"Unsupported," and I'm sure there must be some history behind
this, but do you mind if I ask why? It seems as though being
able to build and distribute packages easily is a very useful
feature. Was the dropping of support for upset just a push
to move to genini (without any documentation), or is there
really some other approach that I should be pursuing?

-Norton


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

Re: Creating a custom Cygwin package server

[Norton Allen]

Igor Peshansky wrote:

"upset" was a private script that received too much attention at some
point, and CGF decided that it wasn't worth making a public open-source
project.  Also, "upset"'s functionality was much broader than just
generating setup.ini.  Thus "genini", written for that express purpose.
Yes, "genini" has no documentation, but, IIRC, CGF will consider patches
to it (including documentation patches).  So, it has the potential of
becoming *the* way of generating setup.ini files for custom package
servers.  Anyone can help out.  .
HTH,


Thank you, that's a useful perspective. Hint well taken. I'll try
using it and see how much I can offer in the way of documentation.

-Norton


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

gcc 3.3.3, const symbols and shared libraries

[Norton Allen]

I have seen the discussions at
http://sourceware.org/ml/cygwin/2004-09/msg01101.html
referenced at
http://cygwin.com/ml/cygwin/2005-03/msg00048.html
regarding gcc 3.3.3's placement of const symbols into
rdata which then cannot be properly initialized.
This problem seems pretty fundamental. Can anyone
tell me whether there has been any followup to
this? Is it considered a cygwin problem or a
gcc problem? Has it been addressed in 3.4.1?
What are developers doing? Going back to 3.3.1?
I ask because I just spent two days trying to
compile a number of libraries, and ran into
problems at every turn due to this bug.
-Norton Allen
begin:vcard
fn:Norton Allen
n:Allen;Norton
org:Harvard University;Anderson Group, DEAS/CCB
adr;dom:;;12 Oxford St.;Cambridge;MA;02138
email;internet:[EMAIL PROTECTED]
title:Software Engineer
tel;work:617-495-5922
x-mozilla-html:FALSE
url:http://www.arp.harvard.edu/
version:2.1
end:vcard


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

Pointer to dll-imported function?

[Norton Allen]

Could someone point me to a description of the
details of how shared library functions are
resolved at runtime? I'm trying to debug a
situation where a variable is supposed to
be initialized with a pointer to a dll-imported
function. It appears to be incorrectly
initialized, but I'm not really sure what it
should point to in this case.
-Norton Allen
begin:vcard
fn:Norton Allen
n:Allen;Norton
org:Harvard University;Anderson Group, DEAS/CCB
adr;dom:;;12 Oxford St.;Cambridge;MA;02138
email;internet:[EMAIL PROTECTED]
title:Software Engineer
tel;work:617-495-5922
x-mozilla-html:FALSE
url:http://www.arp.harvard.edu/
version:2.1
end:vcard


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

Re: gcc 3.3.3, const symbols and shared libraries

[Norton Allen]

Gerrit P. Haase wrote:
Norton Allen wrote:
I have seen the discussions at
http://sourceware.org/ml/cygwin/2004-09/msg01101.html
referenced at
http://cygwin.com/ml/cygwin/2005-03/msg00048.html
regarding gcc 3.3.3's placement of const symbols into
rdata which then cannot be properly initialized.
This problem seems pretty fundamental. Can anyone
tell me whether there has been any followup to
this? Is it considered a cygwin problem or a
gcc problem? Has it been addressed in 3.4.1?
What are developers doing? Going back to 3.3.1?

The rule is to not use const symbols in shared libraries
if they are not really const;)
What do you mean by "really?" These are const from
the standpoint of "defined once and never changed
thereafter," but they are not finally defined until
the link against shared libraries.
It's currently an issue because it requires changes
to quite a few packages. In the past week, I had to
remove const declarations from glib-2.6.3 and
gtk+-2.6.4 to get them to compile. Are these changes
that are uniquely required by cygwin, or are these
going to be required for all gcc platforms?
-Norton
begin:vcard
fn:Norton Allen
n:Allen;Norton
org:Harvard University;Anderson Group, DEAS/CCB
adr;dom:;;12 Oxford St.;Cambridge;MA;02138
email;internet:[EMAIL PROTECTED]
title:Software Engineer
tel;work:617-495-5922
x-mozilla-html:FALSE
url:http://www.arp.harvard.edu/
version:2.1
end:vcard


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

Re: bug with built-in commands in bash when redirecting output

[Norton Allen]

The following one liner illustrates a bug in sh:
$ /bin/bash -c '/bin/bash -cx '\''x=`echo hello`'\''' > @x
++ echo hello
+ x=$'hello\r'
$
 

I'm wondering if the problem I am seeing is from the same source. I find 
that 'apachectl stop' no longer works since a recent cygwin update. I 
can see that the PIDFILE is being written with a \r\n line ending. 
'apachectl stop' then reads the file with


   PID=`cat $PIDFILE`

$PID then includes the \r character, and the subsequent kill operation 
fails as a result.


Is there something that changed recently that is causing this to fail 
now? I'm pretty sure this worked until recently.


Norton Allen


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

bug with cat and backticks? (was: bug with built-in ...)

[Norton Allen]

According to Norton Allen on 1/28/2007 1:08 PM:

I'm wondering if the problem I am seeing is from the same source. I find
that 'apachectl stop' no longer works since a recent cygwin update. I
can see that the PIDFILE is being written with a \r\n line ending.
'apachectl stop' then reads the file with

   PID=`cat $PIDFILE`


cat is not a bash builtin, so no this is not the same problem.  Are you
running a script with CRLF line endings on a binary mount?  If so, read
the announcment, and use d2u on your script.
http://cygwin.com/ml/cygwin-announce/2007-01/msg00015.html
<http://cygwin.com/ml/cygwin-announce/2007-01/msg00015.html>



No, this is a text mount:

Cygwin> mount
[cut]
d:\Data on /Data type user (textmode)
[cut]
Cygwin> cd /Data
Cygwin> echo hello >test.txt
Cygwin> xxd test.txt
000: 6865 6c6c 6f0d 0ahello..
Cygwin> foo=`cat test.txt`
Cygwin> echo "'$foo'"
'hello
Cygwin>

Note the trailing quote is missing because of in intervening CR. It 
seems that the discussion of confusion about whether a program should be 
in text mode or binary mode when pipes are involved would still be 
relevant here.


-Norton


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

Re: bug with cat and backticks?

[Norton Allen]

Eric Blake wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Norton Allen on 1/29/2007 8:00 PM:
 


  PID=`cat $PIDFILE`
   


No, this is a text mount:
 



That's the answer.  You are creating PIDFILE with \r\n line endings, but
cat always reads in binary mode.

Try PID=`cat $PIDFILE | d2u` instead.  Or try using the igncr shell option.
 

OK... Note that 'I' am not doing this. This is part of the apachectl 
script, and sticking | d2u in there isn't a very portable solution. 
Perhaps I should just adjust mount points so /var/run is a binary mount 
point.



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

Re: Why binary mode?

[Norton Allen]

Lev Bishop wrote:

On 2/22/07, Sven Severus wrote:

But in a textmode mounted directory, 'echo peng >p.txt' creates
a 6 byte long file containing 'p' 'e' 'n' 'g' '\r' '\n'.
OK, exactly as expected. Now I thought, 'cat p.txt' would open
this file for reading in textmode, according to the default rule.

This is, what I expect, after reading the Cygwin FAQ:
"When processing in text mode, [...] written to the file [...]
you in fact get "Hello\r\n". Upon reading this combination,
the \r is removed [...]".
Why is it in fact not removed when reading with cat?


Because cat is required by posix to read in binmode. Try, for example:
$ echo peng >p.txt && read CO Which apparently means that the original doc he referred to (Cygwin 
User's Guide, chapter "Text and Binary modes" ) should be updated. I 
think the fact that cat reads in binmode is surprising (though it makes 
sense if you think about it) so the behavior should be prominently 
noted. Certainly the shell idiom of using cat to read text files is 
widespread. Makes you wonder whether cat shouldn't have an option added 
to read in text mode (that'd be an upstream question).



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

Re: GCC doesn't create an executable

[Norton Allen]

Dave Korn wrote:

On 04 March 2007 03:59, Bogus Bill wrote:


  Subject line edited, this is NOT an announcement.

  

I have the same problem.  I tried to compile the requisite "Hello, world!"
program, but gcc didn't give any messages, nor generate any output.  Here
are the specifics:



  

$ g++ -v hello.cpp



  

Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -quiet -v -D__CYGWIN32__
-D__CYGW
IN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../
../../../include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../..
/i686-pc-cygwin/lib/../../include/w32api hello.cpp -quiet -dumpbase
hello.cpp -m
tune=pentiumpro -auxbase hello -version -o
/cygdrive/c/DOCUME~1/BILLRI~1/LOCALS~
1/Temp/ccjMjB4s.s




  Looks like the driver works, but the invocation of cc1plus is failing.

  

$ cygcheck /usr/bin/gcc



  That all looked ok.  What do you see from "cygcheck
/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe"?  What (if anything) do you see
from running "/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -v   


Are you sure this failed, or were you perhaps expecting to find an
executable called hello.exe? The output I get is called a.exe.



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

Re: [ANNOUNCEMENT] Updated: OpenSSH-4.6p1-1: Problems!

[Norton Allen]

Brian Dessent wrote:


What kind of backwater system is this that doesn't have support for SSH
v2?  Version 2 has been the default for many, many years, and version 1
is very deprecated/insecure/etc.  Normally you shouldn't even have to
specify the version, as the client should negotiate it with the server.

 

For what it's worth, I'm still running ssh v1 on a QNX4 system. I 
recently tried to port OpenSSH, but found that it requires 64-bit 
integer support in the compiler, and that didn't exist back then.



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

Re: Spurious [ANNOUNCEMENT]s

[Norton Allen]

Carlo Florendo wrote:

No. It does not look fine.

http://www.cygwin.com/ml/cygwin/2007-03/msg00286.html

Why does [ANNOUNCEMENT] keep getting added on the subject.
There is *something* wrong with your mailer. I've removed
it *again*.

And if you look closely at the contents of the above link,
your own message is quoted by your mailer.

There is *something* wrong with your mailer.




These spurious [ANNOUNCEMENT] subjects seem to be popping up from a 
number of people. It seems unlikely that they are all doing this 
intentionally (though I agree the quoting must be a mailer problem.) I 
wonder if there isn't some way the cygwin.com mailman installation 
sometimes gets confused and modifies the subject line.


Oliver, I don't suppose you have a copy of one of your messages in your 
Sent folder that you could send along with full headers to show that it 
didn't have an [ANNOUNCEMENT] subject when it left your machine?



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

Re: Bash still wants to beep during tab completion

[Norton Allen]

Eric Lilja wrote:

Hello, I've changed my .inputrc to:

# base-files version 3.7-1

# To pick up the latest recommended .inputrc content,
# look in /etc/defaults/etc/skel/.inputrc

# Modifying /etc/skel/.inputrc directly will prevent
# setup from updating it.

# The copy in your home directory (~/.inputrc) is yours, please
# feel free to customise it to create a shell
# environment to your liking.  If you feel a change
# would be benifitial to all, please feel free to send
# a patch to the cygwin mailing list.

# the following line is actually
# equivalent to "\C-?": delete-char
"\e[3~": delete-char

# VT
"\e[1~": beginning-of-line
"\e[4~": end-of-line

# kvt
"\e[H": beginning-of-line
"\e[F": end-of-line

# rxvt and konsole (i.e. the KDE-app...)
"\e[7~": beginning-of-line
"\e[8~": end-of-line

# VT220
"\eOH": beginning-of-line
"\eOF": end-of-line

# Allow 8-bit input/output
#set meta-flag on
#set convert-meta off
#set input-meta on
#set output-meta on
$if Bash
  # Don't ring bell on completion
  #set bell-style none

  # or, don't beep at me - show me
  set bell-style visible

  # Filename completion/expansion
  #set completion-ignore-case on
  #set show-all-if-ambiguous on

  # Expand homedir name
  #set expand-tilde on

  # Append "/" to all dirnames
  #set mark-directories on
  #set mark-symlinked-directories on

  # Match all files
  #set match-hidden-files on

  # 'Magic Space'
  # Insert a space character then performs
  # a history expansion in the line
  #Space: magic-space
$endif

But bash still beeps (one time) if I do for example:
$ cd
$ cd  <-- Beeps here
I performed source .inputrc but got some error messages so I restarted 
bash completely instead. What am I missing? cygcheck.out attached
'set bell-style none' works for me, but 'set bell-style visible' works 
as you describe. I get no visible indication, and I still get the bell.


-Norton


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

Re: Stop turning CPAN modules into Cygwin packages

[Norton Allen]

Brian Mathis wrote:
> Because when you package something using a distro's packaging system,
> you can start to have other programs that depend on it install them
> automatically using the package system.  Also, installing from CPAN,
> while very easy to do, does not keep track or even know about a
> distro's package management system.  So if you wanted to remove it
> later, it is not easy to do, and you could easily run into problems
> where you have installed one version from CPAN, then another package
> requires that module, but because you installed via CPAN it doesn't
> know that, and will then install an older version, overwriting your
> CPAN-installed version.
>   
Just two more cents: No one mentioned that CPAN is a source distribution
and cygwin is a binary distribution. For those modules that require
compilation, pre-packaging means the module can be easily installed on a
system that doesn't have a compiler installed.


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

Does clock() work?

[Norton Allen]

I am trying to write a benchmark application, and figured I'd use 
clock() for sub-second resolution timing, but I got non-sensical 
results. I check the cygwin archives, but the only mention I saw was 
that clock() didn't work on Win98. Here's my test code, chktime.c:


   #include 
   #include 
   #include 

   int main( int argc, char **argv ) {
 clock_t cur_time, cps = CLOCKS_PER_SEC;
 int i;

 printf( "CLOCKS_PER_SEC = %ld\n", cps );

 for ( i = 0; i < 8; i++ ) {
   sleep(1);
   cur_time = clock();
   printf( "clock() = %ld\n", cur_time );
 }
 return 0;
   }

and here's the output I get:

   Cygwin> ./chktime
   CLOCKS_PER_SEC = 1000
   clock() = 171
   clock() = 171
   clock() = 171
   clock() = 171
   clock() = 171
   clock() = 171
   clock() = 171
   clock() = 171
   Cygwin>

I would expect the clock() values to increase by approximately 1000 on 
each iteration. (Yes, the sleep() seems to be working, as the lines come 
out at about 1 Hz.)


Is this a known problem? Do others get this result, or do I have a 
corrupted library?


-Norton Allen


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

Re: Does clock() work?

[Norton Allen]

Mr Webber wrote:

CLOCKS_PER_SEC is a machine dependent macro, but not so machine dependent to
recognize that my 32-bit windows box has dual processors.  Not useful for
benchmarking, is it.
  
It's not quite clear to me why multiple processors would affect the 
interpretation of CLOCKS_PER_SEC, or why such a simple model would not 
work in a single-threaded app for basic benchmarking. I'm not talking 
about a utility to launch commercial apps (which might be multithreaded, 
etc.), just:


   * record the current time
   * do something single-threaded
   * record the current time and calculate elapsed time


clock is not the way to go. It is a crude estimation of processor time.  On
regular UNIX times(2) is the function to use -- cygwin does not seem to have
it.
  
Any other suggestions for timing resolution better than one second on 
cygwin?


-Norton


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

Re: Does clock() work?

[Norton Allen]

Greg Chicares wrote:

I get similar results with the same program. According to
C99 7.23.2.1/2,
  "The clock function determines the processor time used."
so I'd guess that sleep() is consuming only wall-clock time.
  

Ah, good catch. Thank you.
Now, I am definitely interested in wall clock elapsed time. Is there 
anything available that will give me real time at resolution greater 
than one second?


-Norton



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

Re: Does clock() work?

[Norton Allen]

Norton Allen wrote:

Greg Chicares wrote:

I get similar results with the same program. According to
C99 7.23.2.1/2,
  "The clock function determines the processor time used."
so I'd guess that sleep() is consuming only wall-clock time.
  

Ah, good catch. Thank you.
Now, I am definitely interested in wall clock elapsed time. Is there 
anything available that will give me real time at resolution greater 
than one second?



I found gettimeofday() that seems to do the trick.
-N


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

Re: cvs import issue

[Norton Allen]

Sorry, red herring. The directory names happen to fall into cvs's 
default ignore category. -N


Norton Allen wrote:
I'm trying to do a 'cvs import' from cygwin and I'm finding that some 
subdirectories get inexplicably skipped. This reminds me of an old bug 
with the perl find routines where they tried to do some optimization 
that used a directory's link count to stop looking for subdirectories 
before processing all the entries. Does this ring a bell with anyone?


Norton Allen

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


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

cvs import issue

[Norton Allen]

I'm trying to do a 'cvs import' from cygwin and I'm finding that some 
subdirectories get inexplicably skipped. This reminds me of an old bug 
with the perl find routines where they tried to do some optimization 
that used a directory's link count to stop looking for subdirectories 
before processing all the entries. Does this ring a bell with anyone?


Norton Allen

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

Re: How to uninstall Cygwin/X (only)

[Norton Allen]

On 4/9/2010 5:56 AM, Paul Bibbings wrote:
> If by "add a right-click context menu to the spinner" you intend to
> retain the current problematic behaviour of the spinner but add the
> context menu by way of avoiding the noted problems of cycling through
> `uninstall', then I would, as a user, see that as an inconsistency.  I
> would expect the two to be alternative ways of achieving the same thing
> and regard the (presumably) silent difference to be a design flaw.  I may
> be missing something, but I'm wondering how it is that, if the pass
> through `install' can put in all the dependencies, continuing to
> `uninstall' can't just take them out again?
>   
So what you want setup to do is remember whether a package was selected
by the user or simply included to satisfy a dependency. Then when a
package is deselected, the dependencies can be reevaluated.


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

getfacl etc.

[Norton Allen]

I'm trying to sort out an NTFS permissions issue, and am a little
confused. I think I've convinced myself that getfacl agrees with Windows
Explorer's Properties -> Security information, but what does Windows
Explorer's "Read Only" checkbox do? I have files that appear to grant
rwx to everyone, yet have this box checked, and getfacl and ls -l don't
give any hint.


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

Re: pdfroff (or groff) broken?

[Norton Allen]

On 9/2/2014 3:30 PM, gjnospam2014-cyg...@yahoo.com wrote:

WJFFM.


This is a standard cygwin acronym [https://cygwin.com/acronyms/] 
indicating that the problem could not be reproduced.




https://cygwin.com/problems.html


This is a request for more information, i.e. following the standard 
procedure for reporting a problem.



Well, gee, thanks for SFA.

FWIW it works fine for me now I have reverted to a previous installation.
Sucks to be anyone else who might encounter this problem in the future

though, huh?


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




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

Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build

[Norton Allen]

On 12/5/2019 2:44 PM, Ken Brown wrote:

Then I wonder what's different about Wilfed's setup that causes an attempt to
open Z: when it's offline.

I'm grasping at straws, but could the difference be related to the fact that his
drive Z: is not a Samba share?  Here's an excerpt from the mount output in one
of his earlier emails (when Z: is online):

V: on /cygdrive/v type smbfs (binary,noacl,posix=0,user,noumount,auto)
W: on /cygdrive/w type smbfs (binary,noacl,posix=0,user,noumount,auto)
X: on /cygdrive/x type smbfs (binary,noacl,posix=0,user,noumount,auto)
Y: on /cygdrive/y type smbfs (binary,noacl,posix=0,user,noumount,auto)
Z: on /cygdrive/z type cifs (binary,noacl,posix=0,user,noumount,auto)
 


Correct me if I'm wrong or misremembering, but I think Corinna 
specifically set 'always available offline', and I do not believe the OP 
used that configuration. I have network drives which are only accessible 
when I am at work, and I do not have 'always available offline' 
selected, yet they are able to persist across sessions where they are 
inaccessible.


I'm sorry to say though that I have not followed this discussion closely 
enough to attempt to reproduce the problem myself.




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

Cygwin parenting issue

[Norton Allen]

I have a project that involves starting a number of programs in the 
background and then monitoring and reporting when they terminate. My 
approach has been to write a small application called 'parent' that 
loops on waitpid() until there are no more children. I invoke it in a 
script like:


#! /bin/bash
program1 &
program2 &
program3 &
exec parent

This of course works under Linux, but under Cygwin, although 'ps' 
documents the parent/child relationship, waitpid() immediately returns 
ECHILD, indicating there are no child processes. If I use the shell's 
waitpid, that works alright, so I am wondering whether the problem is a 
casualty of the exec.


I have a minimal test setup at 
https://github.com/nthallen/test_parenting, along with examples showing 
how it works under Linux and Cygwin.


Is this something that we would expect to work under Cygwin?

-Norton


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

Re: Cygwin parenting issue

[Norton Allen]

On 1/1/2020 6:24 PM, Ken Brown wrote:

This looks like the issue that was reported here:

https://cygwin.com/ml/cygwin/2019-09/msg00263.html

It's been fixed. Try updating the cygwin package.


That is awesome! Thanks for testing and confirming (as I have just done 
as well.)


Here I thought I was up to date...

-Norton




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

Re: Setting termios VMIN > 0 and VTIME > 0 on non blocking file

[Norton Allen]

On 3/11/2020 5:55 PM, Brian Inglis wrote:

VMIN > 0 || VTIME > 0 implies blocking; O_NONBLOCK implies SIGIO delivery; see:


While I agree with everything else you said there, I don't believe 
either of these are true, unless by 'implies' you mean that's how you 
usually do it. I have done a lot of work with non-zero VMIN and/or VTIME 
in non-blocking situations, and I've done non-blocking with different 
approaches to delivery.


--
=========
Norton Allen (he/him/his)
Software Engineer
Harvard University School of Engineering and Applied Sciences
12 Oxford St., Link Bldg. (Office 282)
Cambridge, MA  02138
Phone: (617) 998-5553
=

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

Re: Setting termios VMIN > 0 and VTIME > 0 on non blocking file

[Norton Allen]

On 3/11/2020 9:04 PM, Åke Rehnman via Cygwin wrote:


On 2020-03-11 22:55, Brian Inglis wrote:
VMIN > 0 || VTIME > 0 implies blocking; O_NONBLOCK implies SIGIO 
delivery; see:

https://www.tldp.org/HOWTO/pdf/Serial-Programming-HOWTO.pdf
https://www.cmrr.umn.edu/~strupp/serial.html
https://en.wikibooks.org/wiki/Serial_Programming/termios

also read the man pages carefully and *assume* nothing; functions 
should work

*exactly* as documented: there be dragons!

According to https://www.cmrr.umn.edu/~strupp/serial.html "*Timeouts 
are ignored in canonical input mode or when the/NDELAY/option is set 
on the file via/open/or/fcntl/."*


This leads me to believe the current cygwin implementation is not 
correct. Changing the VMIN and VTIME should have no effect on the 
read() behavior if the file was opened with O_NOBLOCK.
** 



Correct me if I am wrong, but O_NDELAY is not the same as O_NONBLOCK

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

Re: Sv: Named pipes and multiple writers

[Norton Allen]

On 3/26/2020 11:11 AM, Ken Brown via Cygwin wrote:


BTW, I've been working on adding support for multiple readers.  I 
expect to have a first cut ready within a week or two.  Would you have 
any use for that?  If so, I could revive the topic/fifo branch and 
push my patches there for you to test.




Ken, what are the semantics for multiple readers? Do all readers see the 
same data,  or is it first come first served or something else?


--
=
Norton Allen (he/him/his)
Software Engineer
Harvard University School of Engineering and Applied Sciences
12 Oxford St., Link Bldg. (Office 282)
Cambridge, MA  02138
Phone: (617) 998-5553
=

--
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: Sv: Named pipes and multiple writers

[Norton Allen]

On 3/26/2020 12:44 PM, Ken Brown via Cygwin wrote:

On 3/26/2020 12:03 PM, Norton Allen wrote:

On 3/26/2020 11:11 AM, Ken Brown via Cygwin wrote:


BTW, I've been working on adding support for multiple readers.  I 
expect to have a first cut ready within a week or two.  Would you 
have any use for that?  If so, I could revive the topic/fifo branch 
and push my patches there for you to test.




Ken, what are the semantics for multiple readers? Do all readers see 
the same data,  or is it first come first served or something else?


It's first come, first served.  If two readers attempt to read 
simultaneously, it's possible that one will get some of the available 
input and the other will get some more.


The only use case for multiple readers that I've come across of is 
Midnight Commander running under tcsh.  I didn't dig into the code 
enough to know why they do it, or why only under tcsh.  See


https://sourceware.org/pipermail/cygwin/2019-December/243317.html

and

https://cygwin.com/pipermail/cygwin-apps/2019-December/039777.html

That's what got me interested in this.  It would be nice to know if 
there are other use cases.


I suppose it could be used as a simple approach to deploying jobs to 
worker processes, provided a process could guarantee that it received 
enough information to define a job and not more than one. I guess if the 
job definition were fixed length that could work.



--
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: Problems with ssh when I log into my PC using my corporate domain while working from home

[Norton Allen]

On 4/23/2020 2:10 PM, Mark Hansen wrote:

On 4/23/2020 10:26 AM, ASSI wrote:

Mark Hansen writes:

Here is my user id (from the id command) when I log in from the office:

uid=1293438(Mark.Hansen) gid=1049089(Domain Users) ...

Here is the same when I've logged in with the machine at home:

uid=1293438(MAN+User(244862)) gid=1293438

(MAN) is the domain.


That likely means that when you connect from home, you cannot talk to 
the

corporate domain server or you are ion a different domain.  The domain
part is only shown when it isn't the primary domain IIRC and since the
numerical user instead of the name is shown, that SID did not resolve.

The actual problem I'm having is that Cygwin tools like ssh, git, 
etc. can't find my .ssh

directory. They are looking in "/" rather than my home directory.


Depending on how this is set up in your domain, you might need to point
either Cygwin or sshd to use a separate local directory.  You have no
network access on Windows (i.e. you won't be able to access any fils
shares) until you've authenticated with a password.

I tried copying my .ssh directory from my home to "/" and although 
it was created, the

files have the wrong permissions and I'm unable to change them.


You would need to be either an admin and/or the user who installed
Cygwin for that to work, but you shouldn't do that.

Is there something I can tweak to get Cygwin to understand which 
user I am so the ssh

stuff can start working again?


If Cygwin doesn't know who you are, then that means Windows doesn't know
either, so fixing this on the Cygwin side won't get you much further.


Regards,
Achim.



I think Windows knows who I am. I log into the machine using my normal 
domain login
credentials. The machine looks the way it does when I log in when the 
machine is in the
office - the desktop is the same, etc. - it's not acting like I'm a 
new user or anything

like that.

Everything on the Windows side seems to be working fine. The only 
issue I've found is with
Cygwin. Is there a way (short of removing and reinstalling Cygwin) 
that I can get Cygwin
to recognize my current user so ssh and git can know where my home 
directory is located?


I also have had to deal with this problem. You should certainly read 
https://cygwin.com/cygwin-ug-net/ntsec.html.


After much experimenting and consultation with Corinna, we decided the 
best solution for me was:


 * Create /etc/passwd and /etc/group files
 o For /etc/passwd, I included just my account, and I actually
   editted it further to use my preferred username (rather than my
   domain username) and my correct home directory
 * Edit /etc/nsswitch.conf with:
 o passwd: files
 o group: files

This is not the generally recommended configuration, but in the 
situation where you cannot reach the domain server, it may be the best 
alternative. You may or may not need to back these changes out when you 
are back at work. I have not had a problem at work, but we are only 
loosely connected to the domain, so YMMV.


--

=
Norton Allen (he/him/his)
Software Engineer
Harvard University School of Engineering and Applied Sciences
12 Oxford St., Link Bldg. (Office 282)
Cambridge, MA  02138
Phone: (617) 998-5553
=

--
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: How to check cygwin version?

[Norton Allen]

On 7/2/2020 1:20 AM, Brian Inglis wrote:

On 2020-07-01 07:36, Jeffrey Walton via Cygwin wrote:

I think the documentation leaves a lot to be desired... I'm trying to
tell someone what version of Cygwin I am using.

There's a FAQ item at
https://cygwin.com/faq/faq.html#faq.what.version. It gives this
useless advice:

To find the version of the Cygwin DLL installed, you can use uname
as on Linux or cygcheck. Refer to each command's --help output and
the Cygwin User's Guide for more information.

OK, let's try it:

$ cygcheck -v
Usage: cygcheck [-v] [-h] PROGRAM
cygcheck -c [-d] [PACKAGE]
cygcheck -s [-r] [-v] [-h]
cygcheck -k
...

OK, -v is what we need:

$ cygcheck -v cygwin
cygcheck: could not find 'cygwin'

OK, another failure.

RTFM does not work. Why the hell don't you just state how to check the
god damn version?

Do you think it would help if this FAQ entry were changed to read:

1.5. What version of Cygwin is this, anyway?
  To find the version of the Cygwin DLL installed, you can use any of the
Cygwin commands uname -a, uname -srvm, head /proc/version as on Linux, or
cygcheck -V. Refer to each command's --help output or the Cygwin User's Guide
for more information.

and please make any further comments, feedback, or suggestions you think would
help with this entry.

Running the suggested commands with their --help options would have shown you:

$ uname --help
Usage: uname [OPTION]...
Print certain system information.  With no OPTION, same as -s.

   -a, --allprint all information, in the following order,
  except omit -p and -i if unknown:
   -s, --kernel-nameprint the kernel name
   -n, --nodename   print the network node hostname
   -r, --kernel-release print the kernel release
   -v, --kernel-version print the kernel version
   -m, --machineprint the machine hardware name
   -p, --processor  print the processor type (non-portable)
   -i, --hardware-platform  print the hardware platform (non-portable)
   -o, --operating-system   print the operating system
   --help display this help and exit
   --version  output version information and exit

GNU coreutils online help: 
Full documentation at: 
or available locally via: info '(coreutils) uname invocation'

$ cygcheck --help
Usage: cygcheck [-v] [-h] PROGRAM
cygcheck -c [-d] [PACKAGE]
cygcheck -s [-r] [-v] [-h]
cygcheck -k
cygcheck -f FILE [FILE]...
cygcheck -l [PACKAGE]...
cygcheck -p REGEXP
cygcheck --delete-orphaned-installation-keys
cygcheck -h

List system information, check installed packages, or query package database.

At least one command option or a PROGRAM is required, as shown above.

   PROGRAM  list library (DLL) dependencies of PROGRAM
   -c, --check-setupshow installed version of PACKAGE and verify integrity
(or for all installed packages if none specified)
   -d, --dump-only  just list packages, do not verify (with -c)
   -s, --sysinfoproduce diagnostic system information (implies -c)
   -r, --registry   also scan registry for Cygwin settings (with -s)
   -k, --keycheck   perform a keyboard check session (must be run from a
plain console only, not from a pty/rxvt/xterm)
   -f, --find-package   find the package to which FILE belongs
   -l, --list-package   list contents of PACKAGE (or all packages if none given)
   -p, --package-query  search for REGEXP in the entire cygwin.com package
repository (requires internet connectivity)
   --delete-orphaned-installation-keys
Delete installation keys of old, now unused
installations from the registry.  Requires the right
to change the registry.
   -v, --verboseproduce more verbose output
   -h, --help   annotate output with explanatory comments when given
with another command, otherwise print this help
   -V, --versionprint the version of cygcheck and exit

Note: -c, -f, and -l only report on packages that are currently installed. To
   search all official Cygwin packages use -p instead.  The -p REGEXP matches
   package names, descriptions, and names of files/paths within all packages.

I think what is missing in all these suggestions is a clear statement 
that for Cygwin's purposes, the cygwin DLL is considered to be the 
'kernel', so looking for the 'kernel release' gives you the DLL version. 
I think that leap is totally non-obvious.



--
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

cmake suddenly stopped working

[Norton Allen]

Windows 10

Cygwin installed all up to date

cmake 3.17.3-2, which does not appear to have changed since August

Symptoms: cmake fails silently with (or without) any arguments, 
including --help. Exit code is 127


I tried to reinstall cmake, the file appears to be identical

cygcheck -s and cygcheck /usr/bin/cmake both look OK to to me, though 
I'd be happy to upload if anyone is interested.


My AV is ESET. Tried disabling it to no effect.

This could have been caused by a recent cygwin update. The following 
were all installed last Friday. Would anyone like to guess which are 
worth checking? I will cross-check with the cygcheck output for cmake.


Is anyone else seeing this? Any suggestions?

   Nov 13 11:30 gdb.lst.gz
   Nov 13 11:30 git.lst.gz
   Nov 13 11:30 gcc-g++.lst.gz
   Nov 13 11:30 libsource-highlight4.lst.gz
   Nov 13 11:30 openssh.lst.gz
   Nov 13 11:29 gcc-core.lst.gz
   Nov 13 11:29 libboost_regex1.66.lst.gz
   Nov 13 11:29 make.lst.gz
   Nov 13 11:29 libfido2.lst.gz
   Nov 13 11:29 libsource-highlight-common.lst.gz
   Nov 13 11:29 libzstd1.lst.gz
   Nov 13 11:29 libisl22.lst.gz
   Nov 13 11:29 libicu61.lst.gz
   Nov 13 11:29 libguile2.2_1.lst.gz
   Nov 13 11:29 libcbor.lst.gz
   Nov 13 11:29 libjsoncpp24.lst.gz
   Nov 13 11:29 screen.lst.gz
   Nov 13 11:29 libncurses-devel.lst.gz
   Nov 13 11:29 less.lst.gz
   Nov 13 11:29 graphviz.lst.gz
   Nov 13 11:29 file.lst.gz
   Nov 13 11:29 doxygen.lst.gz
   Nov 13 11:29 cygwin-doc.lst.gz
   Nov 13 11:29 bzip2.lst.gz


--
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: cmake suddenly stopped working

[Norton Allen]

On 11/17/2020 5:48 PM, Mark Geisert wrote:

Norton Allen wrote:

Is anyone else seeing this? Any suggestions?


I'm not seeing it.  'cmake --help' works for me.
Does 'ldd /usr/bin/cmake' give any hint? 


ldd did not complain, but your question reminded me that I should try 
running under strace. That produce the complaint:


   The procedure entry point
   _ZNSt19basic_ostringstreamlcSt11char_traitslcESalcEEC1Ev could not
   be located in the dynamic link library C:\cygwin64\bin\cmake.exe

(I had to type that in, as I could not copy from strace's error dialog.)

That looks like it might be an issue with the g++ library? Any chance 
there was a change in the library that might require a recompile/relink?


I will try rolling that one back.


--
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: cmake suddenly stopped working

[Norton Allen]

On 11/17/2020 6:21 PM, Norton Allen wrote:

On 11/17/2020 5:48 PM, Mark Geisert wrote:

Norton Allen wrote:

Is anyone else seeing this? Any suggestions?


I'm not seeing it.  'cmake --help' works for me.
Does 'ldd /usr/bin/cmake' give any hint? 


ldd did not complain, but your question reminded me that I should try 
running under strace. That produce the complaint:


   The procedure entry point
   _ZNSt19basic_ostringstreamlcSt11char_traitslcESalcEEC1Ev could not
   be located in the dynamic link library C:\cygwin64\bin\cmake.exe

(I had to type that in, as I could not copy from strace's error dialog.)

That looks like it might be an issue with the g++ library? Any chance 
there was a change in the library that might require a recompile/relink?


I will try rolling that one back. 



Rolling back to gcc-g++ 9.3.0 did not help.

I did find that entry point string in cmake.exe (all the lowercase 'L's 
I typed in that are actually capital i's. My font makes no distinction) 
and I was able to locate a matching string in 
/lib/gcc/x86_64-pc-cygwin/9.3.0/libstdc++.a, but not in libstdc++.dll.a. 
Running strings on the /usr/bin/cygstdc++-6.dll showed the same 
information. Maybe I need to roll back further!



--
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: cmake suddenly stopped working

[Norton Allen]

On 11/17/2020 6:48 PM, Norton Allen wrote:

On 11/17/2020 6:21 PM, Norton Allen wrote:

On 11/17/2020 5:48 PM, Mark Geisert wrote:

Norton Allen wrote:

Is anyone else seeing this? Any suggestions?


I'm not seeing it.  'cmake --help' works for me.
Does 'ldd /usr/bin/cmake' give any hint? 


ldd did not complain, but your question reminded me that I should try 
running under strace. That produce the complaint:


   The procedure entry point
   _ZNSt19basic_ostringstreamlcSt11char_traitslcESalcEEC1Ev could not
   be located in the dynamic link library C:\cygwin64\bin\cmake.exe

(I had to type that in, as I could not copy from strace's error dialog.)

That looks like it might be an issue with the g++ library? Any chance 
there was a change in the library that might require a recompile/relink?


I will try rolling that one back. 



Rolling back to gcc-g++ 9.3.0 did not help.

I did find that entry point string in cmake.exe (all the lowercase 
'L's I typed in that are actually capital i's. My font makes no 
distinction) and I was able to locate a matching string in 
/lib/gcc/x86_64-pc-cygwin/9.3.0/libstdc++.a, but not in 
libstdc++.dll.a. Running strings on the /usr/bin/cygstdc++-6.dll 
showed the same information. Maybe I need to roll back further!


This seems to be the crux of it. That entry point is simply not in the 
g++ shared library. I have not figured out why this cropped up today, 
since it is not present in the current (10.2.0-1) or previous (9.3.0-2) 
versions. I will trying going back to 7.4.0.1, but it's hard to imagine 
it's been gone so long and I haven't seen the problem before today.


    nort@easwhlpt3425080 /usr/bin
    $ strings cygstdc++-6.dll | grep 
_ZNSt19basic_ostringstreamIcSt11char_traits

    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE3strERKSs
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE4swapERS3_
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1EOS3_
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1ERKSsSt13_Ios_Openmode
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1ESt13_Ios_Openmode
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC2EOS3_
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC2ERKSsSt13_Ios_Openmode
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC2ESt13_Ios_Openmode
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED0Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED1Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED2Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEaSEOS3_

    nort@easwhlpt3425080 /usr/bin
    $ strings cmake.exe | grep _ZNSt19basic_ostringstreamIcSt11char_traits
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED1Ev

Does this seem like a problem that is likely to be resolved by 
rebuilding cmake?



--
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: cmake suddenly stopped working

[Norton Allen]

Rolling back cmake from 3.17.3-2 to 3.14.5-1 seems to have resolved the 
problem.


Any idea why no one else seems to be seeing this problem with 3.17.3-2?


--
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: cmake suddenly stopped working

[Norton Allen]

On 11/18/2020 6:31 AM, Marco Atzeri via Cygwin wrote:

On 18.11.2020 01:24, Norton Allen wrote:
Rolling back cmake from 3.17.3-2 to 3.14.5-1 seems to have resolved 
the problem.


Any idea why no one else seems to be seeing this problem with 3.17.3-2?



I assume you had an incomplete upgrade.

what is the output of "cygcheck cmake" ?


I rolled back forward to 3.17.3-2 and verified that 3.17.3-2 still shows 
the problem:


$ cygcheck cmake
Found: C:\cygwin64\bin\cmake.exe
C:\cygwin64\bin\cmake.exe
  C:\cygwin64\bin\cygwin1.dll
    C:\WINDOWS\system32\KERNEL32.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-rtlsupport-l1-1-0.dll

  C:\WINDOWS\system32\ntdll.dll
  C:\WINDOWS\system32\KERNELBASE.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-processthreads-l1-1-0.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-processthreads-l1-1-1.dll

  C:\Program Files\OpenJDK\jdk-13\bin\api-ms-win-core-heap-l1-1-0.dll
  C:\Program Files\OpenJDK\jdk-13\bin\api-ms-win-core-memory-l1-1-0.dll
  C:\Program Files\OpenJDK\jdk-13\bin\api-ms-win-core-handle-l1-1-0.dll
  C:\Program Files\OpenJDK\jdk-13\bin\api-ms-win-core-synch-l1-1-0.dll
  C:\Program Files\OpenJDK\jdk-13\bin\api-ms-win-core-synch-l1-2-0.dll
  C:\Program Files\OpenJDK\jdk-13\bin\api-ms-win-core-file-l1-1-0.dll
  C:\Program Files\OpenJDK\jdk-13\bin\api-ms-win-core-file-l1-2-0.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-namedpipe-l1-1-0.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-datetime-l1-1-0.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-sysinfo-l1-1-0.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-timezone-l1-1-0.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-localization-l1-2-0.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-processenvironment-l1-1-0.dll

  C:\Program Files\OpenJDK\jdk-13\bin\api-ms-win-core-string-l1-1-0.dll
  C:\Program Files\OpenJDK\jdk-13\bin\api-ms-win-core-debug-l1-1-0.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-errorhandling-l1-1-0.dll

  C:\Program Files\OpenJDK\jdk-13\bin\api-ms-win-core-util-l1-1-0.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-profile-l1-1-0.dll

  C:\Program Files\OpenJDK\jdk-13\bin\api-ms-win-core-file-l2-1-0.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-console-l1-1-0.dll
  C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-console-l1-2-0.dll

  C:\cygwin64\bin\cyggcc_s-seh-1.dll
  C:\cygwin64\bin\cygstdc++-6.dll
  C:\cygwin64\bin\cygarchive-13.dll
    C:\cygwin64\bin\cygbz2-1.dll
    C:\cygwin64\bin\cygiconv-2.dll
    C:\cygwin64\bin\cyglz4-1.dll
    C:\cygwin64\bin\cyglzma-5.dll
    C:\cygwin64\bin\cygnettle-6.dll
    C:\cygwin64\bin\cygxml2-2.dll
  C:\cygwin64\bin\cygz.dll
  C:\cygwin64\bin\cygcurl-4.dll
    C:\cygwin64\bin\cygbrotlidec-1.dll
  C:\cygwin64\bin\cygbrotlicommon-1.dll
    C:\cygwin64\bin\cygcrypto-1.1.dll
    C:\cygwin64\bin\cyggssapi_krb5-2.dll
  C:\cygwin64\bin\cygk5crypto-3.dll
    C:\cygwin64\bin\cygkrb5support-0.dll
  C:\cygwin64\bin\cygintl-8.dll
  C:\cygwin64\bin\cygkrb5-3.dll
    C:\cygwin64\bin\cygcom_err-2.dll
    C:\cygwin64\bin\cygidn2-0.dll
  C:\cygwin64\bin\cygunistring-2.dll
    C:\cygwin64\bin\cyglber-2-4-2.dll
    C:\cygwin64\bin\cygldap-2-4-2.dll
  C:\cygwin64\bin\cygcrypto-1.0.0.dll
  C:\cygwin64\bin\cygsasl2-3.dll
  C:\cygwin64\bin\cygssl-1.0.0.dll
    C:\cygwin64\bin\cygnghttp2-14.dll
    C:\cygwin64\bin\cygpsl-5.dll
    C:\cygwin64\bin\cygssh-4.dll
    C:\cygwin64\bin\cygssl-1.1.dll
  C:\cygwin64\bin\cygjsoncpp-24.dll
  C:\cygwin64\bin\cygrhash-0.dll
  C:\cygwin64\bin\cyguv-1.dll

--
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: cmake suddenly stopped working

[Norton Allen]

On 11/18/2020 5:40 AM, Lemures Lemniscati via Cygwin wrote:

On Tue, 17 Nov 2020 19:24:12 -0500, Norton Allen

Rolling back cmake from 3.17.3-2 to 3.14.5-1 seems to have resolved the problem.

Any idea why no one else seems to be seeing this problem with 3.17.3-2?


If it is caused by incomplete rebasing, a full rebase might make it work.

cf. https://www.cygwin.com/faq.html#faq.using.fixing-fork-failures
|| Force a full rebase: Run rebase-trigger fullrebase, exit all Cygwin programs 
and run Cygwin setup.
Thanks Lem. I gave this a try, but no luck. That does not seem to be my 
problem.

--
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: cmake suddenly stopped working

[Norton Allen]

On 11/18/2020 10:33 AM, Marco Atzeri via Cygwin wrote:

On 18.11.2020 14:54, Norton Allen wrote:

On 11/18/2020 6:31 AM, Marco Atzeri via Cygwin wrote:

On 18.11.2020 01:24, Norton Allen wrote:
Rolling back cmake from 3.17.3-2 to 3.14.5-1 seems to have resolved 
the problem.


Any idea why no one else seems to be seeing this problem with 
3.17.3-2?




I assume you had an incomplete upgrade.

what is the output of "cygcheck cmake" ?


I rolled back forward to 3.17.3-2 and verified that 3.17.3-2 still 
shows the problem:


$ cygcheck cmake
Found: C:\cygwin64\bin\cmake.exe


   C:\Program 
Files\OpenJDK\jdk-13\bin\api-ms-win-core-rtlsupport-l1-1-0.dll


this is strange

Can you try also
   strace -o cmake.out /usr/bin/cmake --version

I expect an error with a specific shared library 


Yes, earlier in the thread I reported running with strace and 
identifying a specific symbol that was missing, apparently from the 
stdc++ library:


This seems to be the crux of it. That entry point is simply not in the 
g++ shared library. I have not figured out why this cropped up today, 
since it is not present in the current (10.2.0-1) or previous 
(9.3.0-2) versions. I will trying going back to 7.4.0.1, but it's hard 
to imagine it's been gone so long and I haven't seen the problem 
before today.


    nort@easwhlpt3425080 /usr/bin
    $ strings cygstdc++-6.dll | grep 
_ZNSt19basic_ostringstreamIcSt11char_traits

_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE3strERKSs
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE4swapERS3_
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1EOS3_
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1ERKSsSt13_Ios_Openmode 


_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1ESt13_Ios_Openmode
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC2EOS3_
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC2ERKSsSt13_Ios_Openmode 


_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC2ESt13_Ios_Openmode
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED0Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED1Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED2Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEaSEOS3_

    nort@easwhlpt3425080 /usr/bin
    $ strings cmake.exe | grep 
_ZNSt19basic_ostringstreamIcSt11char_traits

    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED1Ev


_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1Ev is the symbol 
that popped up in the strace error dialog.



--
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: cmake suddenly stopped working

[Norton Allen]

On 11/18/2020 11:35 AM, Marco Atzeri via Cygwin wrote:

can you try to re-install libstdc++6 ?

$ cygcheck -f /usr/bin/cmake.exe
cmake-3.17.3-2

$ cygcheck -f /usr/bin/cygstdc++-6.dll
libstdc++6-10.2.0-1


Hmm, here's a problem:

  $ cygcheck -f /usr/bin/cygstdc++-6.dll
  libstdc++6-7.4.0-1

This is after doing a reinstall selecting 10.2.0-1 (twice!). Setup 
thinks I have 10.2.0-1 installed (i.e. that's what is displayed as 
current in the GUI), but /etc/setup/installed.db says:


  $ grep stdc /etc/setup/installed.db
  libstdc++6 libstdc++6-7.4.0-1.tar.bz2 0

Hmmm. I've been using a scripted setup procedure that automatically 
downloads the setup program and then starts it with specific arguments. 
For some reason that did not do what I thought it was doing (or what 
*it* thought it was doing).


I did it manually, and low and behold, many packages needed to be updated.

And now everything seems to be behaving as it ought to.

Thanks all for all suggestions offered!


--
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: g++ and c++17 filesystem

[Norton Allen]

On 11/18/2020 3:46 PM, Kristian Ivarsson via Cygwin wrote:

Is there any other use cases for CYGWIN than to build applications running in 
Windows ? Do people use CYGWIN (shell) to operate or monitor their applications 
? For all other use cases than the development (the shell) I cannot see why 
CYGWIN would favour posix-paths over native path’s, but maybe I’m wrong ?


To write software that can be compiled and run under Windows, Linux and 
MacOS.



--
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

Unix Domain Socket Limitation?

[Norton Allen]

In my recent tests, it appears as though it is not possible to 
successfully connect via two Unix Domain sockets from one client 
application to one server application.


Specifically, if I create a server which listens on a Unix Domain socket 
and a client, which attempts to connect() twice, both seem to lock up. 
This is not the behavior under Linux.


I will be happy to work up a minimal example if it is helpful in 
tracking this down. I wanted to start by asking whether this is a known 
limitation and/or if there is something about the Cygwin implementation 
that makes this sort of thing very difficult.



--
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: Unix Domain Socket Limitation?

[Norton Allen]

On 11/26/2020 12:13 PM, Ken Brown wrote:

[Adding the Cygwin list back to the Cc.]

On 11/26/2020 11:27 AM, Norton Allen wrote:

On 11/25/2020 5:27 PM, Ken Brown via Cygwin wrote:

On 11/25/2020 4:47 PM, Norton Allen wrote:
In my recent tests, it appears as though it is not possible to 
successfully connect via two Unix Domain sockets from one client 
application to one server application.


Specifically, if I create a server which listens on a Unix Domain 
socket and a client, which attempts to connect() twice, both seem 
to lock up. This is not the behavior under Linux.


I will be happy to work up a minimal example if it is helpful in 
tracking this down. I wanted to start by asking whether this is a 
known limitation and/or if there is something about the Cygwin 
implementation that makes this sort of thing very difficult.


A minimal example would be extremely helpful.

Corinna can answer questions about limitations in the current 
implementation. But there is a new implementation under development. 
It's in the topic/af_unix branch of the Cygwin git repository if 
you're interested in looking at it.


Corinna began working on this a couple years ago, and I've recently 
been trying to finish it.  I've made quite a bit of progress, but 
there's still more to do and undoubtedly many bugs. So any test 
cases you have would be very useful. 


Thanks Ken,

As it happens, attempting to produce a minimal example suggests my 
problem may be somewhere else. I think I've worked in most of the 
features of my application one by one but have not yet revealed a 
failure.


OK.  But if you ever do have occasion to write small test programs 
involving AF_UNIX sockets, please send them on.  The new AF_UNIX code 
needs as much testing as it can get.


I have finally put together a start of a minimal example, although it 
seems to require a certain level of complexity before tripping on the 
bug. At the moment, I do not believe the issue is related to having 
multiple sockets between the client and server. I am thinking it is some 
sort of race condition related to non-blocking sockets, since I have 
only observed it when both the client and server are using non-blocking 
sockets.


I have yet to plunge into cygwin.dll, but I think I have reached that point.

Here is the code: https://github.com/nthallen/cygwin_unix

Since I have only exercised this on my machine, I would be very 
interested to know if it is reproducible on anyone else's.



--
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: Unix Domain Socket Limitation?

[Norton Allen]

On 11/30/2020 1:14 PM, Ken Brown wrote:
I can reproduce the hang, and it happens if I use the new AF_UNIX code 
also. But what I'm seeing (at least with the new code) isn't exactly 
what you describe.


When the server's first select call returns, accept succeeds.  The 
server then calls select a second time, and that call doesn't return.  
I haven't checked yet to see what's going on in the client, and I may 
not get to that for a while.


That's good news, and seems to be consistent with my theory that it is 
some sort of race condition that might be particularly sensitive to 
system-specific timing. I am compiling cygwin1.dll now.



--
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: Unix Domain Socket Limitation?

[Norton Allen]

On 11/30/2020 6:19 PM, Ken Brown wrote:

On 11/30/2020 1:26 PM, Norton Allen wrote:

On 11/30/2020 1:14 PM, Ken Brown wrote:
I can reproduce the hang, and it happens if I use the new AF_UNIX 
code also. But what I'm seeing (at least with the new code) isn't 
exactly what you describe.


When the server's first select call returns, accept succeeds. The 
server then calls select a second time, and that call doesn't 
return. I haven't checked yet to see what's going on in the client, 
and I may not get to that for a while.


That's good news, and seems to be consistent with my theory that it 
is some sort of race condition that might be particularly sensitive 
to system-specific timing. I am compiling cygwin1.dll now.


Hi Norton,

I think there's a mistake in your test program.  Shouldn't 
client_pselect() be waiting for the socket to be write-ready rather 
than read-ready?  Here's a quote from the Posix page for 'connect':


If the connection cannot be established immediately and O_NONBLOCK is 
set for the file descriptor for the socket, connect() shall fail and 
set errno to [EINPROGRESS], but the connection request shall not be 
aborted, and the connection shall be established asynchronously


When the connection has been established asynchronously, pselect(), 
select(), and poll() shall indicate that the file descriptor for the 
socket is ready for writing.


Yes, you are correct. In fact I had already fixed that bug on another 
branch, then forgot to update it on this one. I also noticed another bug 
in calculating width. Now I am not getting the blocking behavior but 
instead getting the wrong bits set in select(). I think I'd better pick 
this up in the morning when I am thinking straight!



--
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: Unix Domain Socket Limitation?

[Norton Allen]

On 11/30/2020 9:14 PM, Norton Allen wrote:

On 11/30/2020 6:19 PM, Ken Brown wrote:

On 11/30/2020 1:26 PM, Norton Allen wrote:

On 11/30/2020 1:14 PM, Ken Brown wrote:
I can reproduce the hang, and it happens if I use the new AF_UNIX 
code also. But what I'm seeing (at least with the new code) isn't 
exactly what you describe.


When the server's first select call returns, accept succeeds. The 
server then calls select a second time, and that call doesn't 
return. I haven't checked yet to see what's going on in the client, 
and I may not get to that for a while.


That's good news, and seems to be consistent with my theory that it 
is some sort of race condition that might be particularly sensitive 
to system-specific timing. I am compiling cygwin1.dll now.


Hi Norton,

I think there's a mistake in your test program.  Shouldn't 
client_pselect() be waiting for the socket to be write-ready rather 
than read-ready?  Here's a quote from the Posix page for 'connect':


If the connection cannot be established immediately and O_NONBLOCK is 
set for the file descriptor for the socket, connect() shall fail and 
set errno to [EINPROGRESS], but the connection request shall not be 
aborted, and the connection shall be established asynchronously


When the connection has been established asynchronously, pselect(), 
select(), and poll() shall indicate that the file descriptor for the 
socket is ready for writing.


Yes, you are correct. In fact I had already fixed that bug on another 
branch, then forgot to update it on this one. I also noticed another 
bug in calculating width. Now I am not getting the blocking behavior 
but instead getting the wrong bits set in select(). I think I'd better 
pick this up in the morning when I am thinking straight!


Yeah, so now the example no longer blocks for me. Unfortunately these 
bugs are not present in my application, so I will need to keep working 
on this.



--
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: Unix Domain Socket Limitation?

[Norton Allen]

On 11/30/2020 9:22 PM, Norton Allen wrote:
Yeah, so now the example no longer blocks for me. Unfortunately these 
bugs are not present in my application, so I will need to keep working 
on this.




After paring the main application down and back up, I finally narrowed 
in on the condition that was causing this blocking behavior. The issue 
arises when a client connect()s twice to the same server with 
non-blocking unix-domain sockets before calling select().


There are a few pieces to this. With the client configured to connect() 
just once, I can see that the server's select() returns as soon as the 
client calls connect(), but then the server's accept() blocks until the 
client calls select(). That is not proper non-blocking behavior, but it 
appears that the implementation under Cygwin does require that client 
and server both be communicating synchronously to accomplish the 
connect() operation.


I tried running this under Ubuntu 16.04 and found that connect() 
succeeded immediately, so no subsequent select() is required, and there 
does not appear to be a possibility for this collision. That proves to 
hold true even if the server is not waiting in select() to process the 
connect() with accept().


A workaround for this issue may be to keep the socket blocking until 
after connect().


I have pushed the new minimal example program,  'rapid_connects' to 
https://github.com/nthallen/cygwin_unix


The server is run like before as:

   $ ./rapid_connects server

The client can be run in two different modes. To connect with just one 
socket:


   $ ./rapid_connects client1

To connect with two:

   $ ./rapid_connects client2

My immediate strategy will be to develop a workaround for my project. 
Having spent a day inside cygwin1.dll, I can see that I have a steep 
learning curve to make much of a contribution there.



--
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: Unix Domain Socket Limitation?

[Norton Allen]

On 12/3/2020 8:11 PM, Ken Brown wrote:

On 12/2/2020 12:30 PM, Norton Allen wrote:

On 11/30/2020 9:22 PM, Norton Allen wrote:
Yeah, so now the example no longer blocks for me. Unfortunately 
these bugs are not present in my application, so I will need to keep 
working on this.




After paring the main application down and back up, I finally 
narrowed in on the condition that was causing this blocking behavior. 
The issue arises when a client connect()s twice to the same server 
with non-blocking unix-domain sockets before calling select().


There are a few pieces to this. With the client configured to 
connect() just once, I can see that the server's select() returns as 
soon as the client calls connect(), but then the server's accept() 
blocks until the client calls select(). That is not proper 
non-blocking behavior, but it appears that the implementation under 
Cygwin does require that client and server both be communicating 
synchronously to accomplish the connect() operation.


I tried running this under Ubuntu 16.04 and found that connect() 
succeeded immediately, so no subsequent select() is required, and 
there does not appear to be a possibility for this collision. That 
proves to hold true even if the server is not waiting in select() to 
process the connect() with accept().


A workaround for this issue may be to keep the socket blocking until 
after connect().


I have pushed the new minimal example program,  'rapid_connects' to 
https://github.com/nthallen/cygwin_unix


The server is run like before as:

    $ ./rapid_connects server

The client can be run in two different modes. To connect with just 
one socket:


    $ ./rapid_connects client1

To connect with two:

    $ ./rapid_connects client2

My immediate strategy will be to develop a workaround for my project. 
Having spent a day inside cygwin1.dll, I can see that I have a steep 
learning curve to make much of a contribution there.


I'm traveling at the moment and unable to do any testing, but I wonder 
if you're bumping into an issue that was just discussed on the 
cygwin-developers list:


https://cygwin.com/pipermail/cygwin-developers/2020-December/012015.html

A different workaround is described there.

If it's the same issue, then I don't think it will happen with the new 
AF_UNIX implementation.  More in a few days.



It does seem related.

A work around that is working for me is to do a blocking connect() and 
switch to non-blocking when that completes. In my application, the 
connect() generally occurs once at the beginning of a run, so blocking 
for a few milliseconds does not impact responsiveness.



--
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: Unix Domain Socket Limitation?

[Norton Allen]

On 12/5/2020 6:52 PM, Ken Brown wrote:

On 12/4/2020 8:51 AM, Norton Allen wrote:

On 12/3/2020 8:11 PM, Ken Brown wrote:


I'm traveling at the moment and unable to do any testing, but I 
wonder if you're bumping into an issue that was just discussed on 
the cygwin-developers list:


https://cygwin.com/pipermail/cygwin-developers/2020-December/012015.html 



A different workaround is described there.

If it's the same issue, then I don't think it will happen with the 
new AF_UNIX implementation.  More in a few days.



It does seem related.

A work around that is working for me is to do a blocking connect() 
and switch to non-blocking when that completes. In my application, 
the connect() generally occurs once at the beginning of a run, so 
blocking for a few milliseconds does not impact responsiveness.


For the record, I can confirm that (a) the problem occurs with the 
current AF_UNIX implementation and (b) it does not occur with the new 
implementation (on the topic/af_unix branch).  With both client1 and 
client2, I see "connect() apparently succeeded immediately" using the 
new implementation.


The new implementation is not yet ready for prime time, but with any 
luck it might be ready within a few months.


That sounds great, and exactly like the behavior under Linux. I'd 
certainly be happy to test the new implementation as it gets closer, and 
also happy to expand or improve the test apps to cover a wider range of 
functionality and/or usability (e.g. run both client and server via a 
fork.) Feel free to let me know what would be particularly useful.



--
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: GAWK Incorrect Data Display

[Norton Allen]

On 12/19/2020 7:16 PM, Hans-Bernhard Bröker wrote:

Am 20.12.2020 um 00:34 schrieb Jason McGee via Cygwin:
I confirmed there is not a problem with my code by comparing Cygwin 
against Gawk for Windows.


Your presentation of the problem is quite unclear, but the root cause 
is almost certainly not in the code, but in the data.


You're bound to be feeding Windows text files to a Unix tool.  You 
need to reformat the file to Unix format.


I agree. The input likely has  line endings. Cygwin's gawk 
expects just , so the  gets wrapped into the regular line text. 
Your ", 0" is not replacing the beginning of the line, it is 
overprinting it after the .



--
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: Possible issue with newest version of git (v 2.8) under Cygwin

[Norton Allen]

On 5/14/2016 8:03 AM, Adam Dinwoodie wrote:

If I leave off the noacl and do a clone followed by a push and pull we
>end up with the following error in the Windows security tab:
>   The permissions on file.cpp are incorrectly ordered, which may cause
>some entries to be ineffective.

Yes, I've seen that before; it's a problem with the underlying
cygwind1.dll rather than a problem with Git.  I believe the consensus
from people on this list who know more about Windows permissions than me
is that the warning is actually benign and can be ignored.


As I read the Cygwin documentation, the problem is that windows 
permissions and POSIX permissions don't line up very well. In order to 
faithfully reproduce POSIX permissions, Cygwin uses legal but 
non-standard ordering of ACEs. Windows' security tab thinks this is a 
problem, but it really isn't. To quote from the documentation here: 
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files:


   Unfortunately the security tab in the file properties dialog of the
   Windows Explorer insists to rearrange the order of the ACEs to
   canonical order before you can read them. Thank God, the sort order
   remains unchanged if one presses the Cancel button. But don't even
   *think* of pressing OK...

So it would seem the problem as such lies with Windows' security tab.

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

Permissions Problems

[Norton Allen]

I have seen problems similar to those reported in "RE: Possible issue 
with newest version of git (v 2.8) under Cygwin", but I did not want to 
hijack that thread.


For me, the problems have been elusive. Scripts that used to work would 
fail as created directories had bad permissions, but I didn't have time 
to sort them out. In the last week, I finally had time to read through 
the documentation on the ntsec page and try some tests, and of course 
now I'm having trouble reproducing the problems. You'd think that was a 
good thing, right?


I had been using /etc/passwd from mkpasswd, and based on recommendations 
here, I modified nsswitch for passwd: db. This seemed to work fine, and 
I decided I was all set.


Then Windows update rebooted over the weekend, and nothing worked, and 
returning to 'files' resolved the problem.


The exacerbating factor here is that I have a laptop connected to my 
work domain, but we use cached windows credentials when we are not on 
the work LAN (like at home over the weekend). In this scenario, cygwin 
was apparently unable to determine my username, and hence was unable to 
locate my home directory. The username is apparently cached successfully 
if I reboot at work and then go offline, but not if I reboot offline.


Does this mean I need to stay with 'passwd: files db' for the 
foreseeable future, or is it possible to find the username in this scenario?




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

Re: Permissions Problems

[Norton Allen]

On 5/30/2016 6:40 AM, Corinna Vinschen wrote:

On May 16 10:13, Norton Allen wrote:

I have seen problems similar to those reported in "RE: Possible issue with
newest version of git (v 2.8) under Cygwin", but I did not want to hijack
that thread.

For me, the problems have been elusive. Scripts that used to work would fail
as created directories had bad permissions, but I didn't have time to sort
them out. In the last week, I finally had time to read through the
documentation on the ntsec page and try some tests, and of course now I'm
having trouble reproducing the problems. You'd think that was a good thing,
right?

I had been using /etc/passwd from mkpasswd, and based on recommendations
here, I modified nsswitch for passwd: db. This seemed to work fine, and I
decided I was all set.

Then Windows update rebooted over the weekend, and nothing worked, and
returning to 'files' resolved the problem.

The exacerbating factor here is that I have a laptop connected to my work
domain, but we use cached windows credentials when we are not on the work
LAN (like at home over the weekend). In this scenario, cygwin was apparently
unable to determine my username, and hence was unable to locate my home
directory. The username is apparently cached successfully if I reboot at
work and then go offline, but not if I reboot offline.

Does this mean I need to stay with 'passwd: files db' for the foreseeable
future, or is it possible to find the username in this scenario?

It's not the username per se, it's the fact that the db-only setting
doesn't allow o create valid passwd/group entries for your user.

So, yes.  In your scenario you should ideally revert back to "files db"
and create minimal /etc/passwd and /etc/group files.

/etc/passwd may contain only your own user account.  /etc/group
only the domain groups you're member of.  Everything "special" or
"local" will be picked up just fine by Cygwin then.  If there are
also files on your machine owned by some other domain user, it might
be helpful to add that account to /etc/passwd, too.



Great, thanks!


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

Re: /bin/ gets deleted on error

[Norton Allen]

On 4/14/2017 8:42 AM, cyg Simple wrote:

On 4/13/2017 2:43 PM, Brian Inglis wrote:


defensive coding is your friend to avoid disasters:
if [ -n "$foodir" ] && [ -d $foodir/ ]; then
  /bin/rm -fR -- $foodir || exit
else
  echo "Can't find directory '$foodir'"
  exit 2
fi


And even this can be troublesome if you mistype a variable name anywhere
in this code.


Or there are spaces in $foodir


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

Re: RFE: find -d -size 0 => doesn't find empty directories

[Norton Allen]

On 10/31/2018 7:02 PM, L A Walsh wrote:

Something I can use on my /tmp files on linux is a find command:

find /tmp -size 0 -delete

to delete zero-len-files or empty-directories in /tmp.


What flavor of Linux are you using where this works for you? I'm running 
Ubuntu 16.04 at the moment, and I just tried the following in an 
otherwise empty directory:


   $ mkdir b
   $ find . -size 0

The directory 'b' did not show up, hence was not reporting as size 0. 
The man page for -size does not mention any special behavior for 
directories as opposed to regular files, so I would expect Linux to 
never report any directory as size 0, since they always have '.' and 
'..' entries, as you suggested.



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

Re: ssh-agent doesn't die

[Norton Allen]

On 9/26/2019 7:42 PM, Tim Adye wrote:


Is it just me that sees this, or could it be a bug in ssh-agent or 
Cygwin?


I see the same thing (and have never heard of HitmanPro)



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

Re: ssh-agent doesn't die

[Norton Allen]

On 9/26/2019 10:50 PM, Ken Brown wrote:



As a simple test example, consider:

/bin/ssh-agent /bin/sleep 10

While the sleep is still running, ps shows:

    PID    PPID    PGID WINPID   TTY UID    STIME COMMAND
   1694    1693    1694   1576  ?  22534 00:01:10 
/usr/bin/ssh-agent
   1653   1    1653  11740  cons1  22534 00:00:37 /usr/bin/bash
   1693    1653    1693   1552  cons1  22534 00:01:10 /usr/bin/sleep

One oddity is that ssh-agent is listed as a subprocess of sleep

...but this isn't a bug.  ssh-agent forks, and then the parent execs the 
command.


With the salient difference presumably being that the exec is done in 
the parent instead of the child as usual?



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

Re: ssh-agent doesn't die

[Norton Allen]

On 9/27/2019 11:09 AM, Ken Brown wrote:

On 9/27/2019 10:27 AM, Vanda Vodkamilkevich wrote:

Hi,
this may probably be not fully related but I see from time to time a
strange behavior of ssh-agent (running in the background and initially
started by keychain launched in .bashrc) : the agent is running wild (25%
of cpu and never responding). It seems to occur (not systematically) when
network is disconnected and reconnected (this is on a laptop often removed
from the docking system). Do you have any idea how to diagnose the issue
more precisely?

Sorry, but I'm not an expert on ssh-agent.  Everything I said above is based on
doing an internet search and looking briefly at the ssh-agent source code.

My only suggestion would be to attach gdb to the process when it starts running
wild and see if you can figure out why it's inf-looping.  If you don't know how
to do this, someone who does know would have to be able to reproduce the 
problem.
I am not an ssh-agent expert either, but I can report that I have also 
observed this behavior on cygwin. I do not know how to reproduce it.


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

Whither perl-CPAN-Meta-Requirements?

[Norton Allen]

I am trying to install a perl module using cpan (target module not 
available via cygwin setup), and the process is failing due to an 
out-of-date CPAN::Meta::Requirements module. I searched the cygwin 
package list, and perl-CPAN-Meta-Requirements-2.140-2 appears there (I'm 
looking in x86_64), but it does not show up in cygwin setup until I 
uncheck "hide obsolete packages," and then the latest version appears as 
a "dummy". Same with perl-CPAN-Meta. I can apparently select an older 
version (and I may still try that), but I am confused by the packaging.


Did these get absorbed into some other package? I do see some of the 
files exist in perl_base-5.26.1-1, which I have installed, but that 
apparently does not provide a recent enough version of 
CPAN::Meta::Requirements.


Have I entered version hell by using cpan?

Is there a better way?



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

Re: Whither perl-CPAN-Meta-Requirements?

[Norton Allen]

On 12/18/2017 2:29 PM, Achim Gratz wrote:

Norton Allen writes:

I am trying to install a perl module using cpan (target module not
available via cygwin setup), and the process is failing due to an
out-of-date CPAN::Meta::Requirements module.

[…]

This module (like a few others) is built into Perl core itself and no
newer version is available on CPAN yet.  Hence currently there is only a
dummy module available for Cygwin which ensures that any installations
from older Perl versions get uninstalled (you couldn't use them anyway
since they'd be in the installation for the old Perl).


Did these get absorbed into some other package? I do see some of the
files exist in perl_base-5.26.1-1, which I have installed, but that
apparently does not provide a recent enough version of
CPAN::Meta::Requirements.

The installed version is exactly what you are asking for:

$ corelist -v 5.026001 CPAN::Meta::Requirements
CPAN::Meta::Requirements 2.140

You probably also need to install the perl package itself if you
haven't, perl_base is there only for satisfying some common dependencies
without incurring the overhead of a full installation.

Running the cpan shell works for me and it's not requesting me to do any
updates either.


Have I entered version hell by using cpan?

I'm not sure what exactly you did, so I can't comment.  Maybe clean up
your installation, re-install perl and try again?


Regards,
Achim.
Thanks Achim! I think what happened was that somewhere along the line I 
installed something with cpan that wanted to upgrade that module, and I 
had setup to add my cpan updates to a personal directory which I put at 
the front of my Perl5 lib path... When the core got updated, the newer 
version was hidden behind the personal directory. It's always something! 
Reinstalling was next on my list.

-N


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

Re: LLVM JIT based project fails due to undefined HAVE_DLOPEN

[Norton Allen]

On 5/3/2018 11:42 AM, Ory Chowaw-Liebman wrote:

Dear All,

during my work on a programming language I noticed that with the update to LLVM 
5.0.1
the LLVM calls fail to find symbols defined in my executable.
It used to work before the upgrade, and still works fine under windows.
objdump lists the symbols wanted.

With a lot of tracing through the LLVM code, I found that it depends
on HAVE_DLOPEN being defined in a POSIX environment. When
I call GCC with "-E -dM" only
_GLIBCXX_HAVE_DLFCN_H
is defined.

Just using dlopen and friends from my code works fine (though there are o man 
pages).
Should the macros HAVE_DLOPEN and HAVE_DLFCN_H not be defined?

Thanks and best regards,
Ory

Such symbols are not defined by the compiler. They are usually defined 
in a header file that is generated by a configuration script, perhaps 
one named 'configure', which might be generated by the autoconf program, 
possibly combined with other tools from the autotools package. You might 
need to dig into the configuration script to figure out why it decided 
you do not HAVE_DLOPEN or HAVE_DLFCN_H. Perhaps you need to install 
another package, or maybe the script is just broken. There should be a 
log file generated by the script with some details of its determinations.



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

Re: Spam On List

[Norton Allen]

For what it's worth, I think I have a pretty good spam filter, and these 
ads for mailing lists always seem to get through, so they aren't 
particularly easy to catch.



On 5/18/2018 5:03 PM, Erik Soderquist wrote:

On Fri, May 18, 2018 at 4:50 PM, Yaakov Selkowitz wrote:

There is.  It's not perfect.  Depending on how it's tweaked, either we get
false positives or some spam makes it through.  It goes back and forth and
right now it seems were on the latter side.

Personally, I much prefer some getting through rather than false
positives...  being an eternal cat&mouse game, no spam filter will
ever be perfect...

-- Erik

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




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

Re: chmod g+s ineffective

[Norton Allen]

On 7/10/2022 10:33 PM, Eliot Moss wrote:

On 7/10/2022 10:17 PM, Chris Wagner wrote:

On 6/29/2022 9:18 AM, Norton Allen wrote:
On one machine I have, chmod g+s fails to set the sticky bit. 
The >>> command
does not return any error, but ls -l continues to show the bit 
not set.

 $ mkdir foo
 $ chgrp flight foo
 $ chmod g+ws foo
 $ ls -ld foo
 drwxrwxr-x+ 1 nort flight 0 Jun 29 06:50 foo


Hi.  The permission bits are implemented as normal Window's DACLs 
(Discretionary Access List).  +s is implemented magically with the 
NULL SID.  You can view it from Explorer or with icacls.  Try 
checking the return code (echo $?) from chmod. Also try changing 
perms from Explorer.  You might not be able to set the NULL SID for 
some reason.


I'd like to add that, for good reason, the Cygwin DACLs do not conform
to the order of entries that some Windows tools prefer.  Don't let any
Windows program/tool reorder the DACLs!  It will break the Cygwin
functionality, and the Cygwin order does not break Windows functionality.

Right. My experience (Windows 10) is that I cannot change perms from 
Explorer if I don't let them reorder the perms (which I do not).


I have been separated from the machine that exhibits the problem, so I 
have not been able to try the solutions suggested, but expect to have it 
back in a week or so.




--
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: Change mail address

[Norton Allen]

On 9/6/2022 1:21 PM, Federico Kircheis wrote:

Hi,

in the email I received when I registered myself to the cygwin mailing 
list, it was possible to "send" some administrative commands, for 
example:



You can start a subscription for an alternate address,
for example "john@host.domain", just add a hyphen and your
address (with '=' instead of '@') after the command word:



As I am not using the current address as main address anymore, but the 
command does not work; I've received an automatic reply with error 550 
that the address was not found


I've reported the issue to cygwin-apps-ow...@cygwin.com (as suggested 
in the registration email), but never got a response (this was three 
months ago).


Who do I need to contact for updating my mail address?


I am also maintaining a couple of program, I'm mentioning just in case 
it is relevant.


Best

Federico



Have you tried the form here:

https://cygwin.com/mailman/listinfo/cygwin/


--
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: FIFO issues

[Norton Allen]

On 9/19/2022 3:15 PM, Ken Brown wrote:

On 9/18/2022 5:45 PM, Enrico Forestieri wrote:

Hi,

I think I am experiencing a problem with fifos on cygwin. The attached
C source (fifocomm.c) creates two pipes (/tmp/pipe.{in,out}), expecting
to receive inputs from /tmp/pipe.in and replying to /tmp/pipe.out.

Compiling this source on linux and launching it produces on the terminal

1) Opening pipes

and then the program waits for someone to write to /tmp/pipe.in.
Opening another terminal and launching the fifotest.sh script (also
attached) produces on the first terminal

1) Closing pipes
2) Opening pipes

and the program continues waiting for another input, while the other
terminal shows "You sent: foo"

Instead, on cygwin, after launching the program one gets:

1) Opening pipes
1) Closing pipes
2) Opening pipes
2) Closing pipes
3) Opening pipes
3) Closing pipes
4) Opening pipes



meaning that the pipes are continually closed and reopened even if
nobody is writing to /tmp/pipe.in.

Seemingly, the problem is the return value of read() on line 55.
As O_NONBLOCK is set, until no data is available for reading,
read() shouldn't block but should return -1 and set errno to EAGAIN.
After a client that opened the pipe for writing, closes it
(and no other client is using the pipe), read() should return 0 and
only at this point the pipes have to be closed and reopened.

However, on cygwin, read() returns 0 also when nobody is writing to the
input pipe causing the above ping pong. As already said, it works as it
should on linux.


I see what's happening, but I don't see why it's a bug, and I don't 
understand why the Linux behavior is different.


On Cygwin, the call to 'select' in line 44 returns immediately with 
nsel == 1. This seems correct to me, since the man page for 'select' 
says, "A file descriptor is ready for reading if a read operation will 
not block; in particular, a file descriptor is also ready on 
end-of-file."  In the present case a read operation will not block for 
two reasons: first, O_NONBLOCK has been set; second, we're at EOF 
because no process has opened /tmp/pipe.in for writing.  Given that 
we're at EOF, the return value of 0 for the subsequent 'read' is also 
correct.


On Linux, 'select' does not return immediately but instead waits for 
someone to write to the FIFO.


Can someone explain why Linux is right and Cygwin is wrong here? I 
must be missing something obvious.


Ken


This is how I'm reading this, but I have not actually looked at or tried 
the posted code yet:


We use select() specifically when we are using non-blocking I/O. All the 
blocking happens in select() so we can track multiple sockets. If 
select() returns when there is no data available, it's not really doing 
its job, i.e. waiting for data. There are of course particular cases 
where something else (opening, closing) causes select() to return, which 
is normal and expected, but just because the reader is non-blocking is 
not a good reason for select() to return.




--
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: FIFO issues

[Norton Allen]

On 9/19/2022 3:50 PM, Norton Allen wrote:


On 9/19/2022 3:15 PM, Ken Brown wrote:

On 9/18/2022 5:45 PM, Enrico Forestieri wrote:

Hi,

I think I am experiencing a problem with fifos on cygwin. The attached
C source (fifocomm.c) creates two pipes (/tmp/pipe.{in,out}), expecting
to receive inputs from /tmp/pipe.in and replying to /tmp/pipe.out.

Compiling this source on linux and launching it produces on the 
terminal


1) Opening pipes

and then the program waits for someone to write to /tmp/pipe.in.
Opening another terminal and launching the fifotest.sh script (also
attached) produces on the first terminal

1) Closing pipes
2) Opening pipes

and the program continues waiting for another input, while the other
terminal shows "You sent: foo"

Instead, on cygwin, after launching the program one gets:

1) Opening pipes
1) Closing pipes
2) Opening pipes
2) Closing pipes
3) Opening pipes
3) Closing pipes
4) Opening pipes



meaning that the pipes are continually closed and reopened even if
nobody is writing to /tmp/pipe.in.

Seemingly, the problem is the return value of read() on line 55.
As O_NONBLOCK is set, until no data is available for reading,
read() shouldn't block but should return -1 and set errno to EAGAIN.
After a client that opened the pipe for writing, closes it
(and no other client is using the pipe), read() should return 0 and
only at this point the pipes have to be closed and reopened.

However, on cygwin, read() returns 0 also when nobody is writing to the
input pipe causing the above ping pong. As already said, it works as it
should on linux.


I see what's happening, but I don't see why it's a bug, and I don't 
understand why the Linux behavior is different.


On Cygwin, the call to 'select' in line 44 returns immediately with 
nsel == 1. This seems correct to me, since the man page for 'select' 
says, "A file descriptor is ready for reading if a read operation 
will not block; in particular, a file descriptor is also ready on 
end-of-file."  In the present case a read operation will not block 
for two reasons: first, O_NONBLOCK has been set; second, we're at EOF 
because no process has opened /tmp/pipe.in for writing.  Given that 
we're at EOF, the return value of 0 for the subsequent 'read' is also 
correct.


On Linux, 'select' does not return immediately but instead waits for 
someone to write to the FIFO.


Can someone explain why Linux is right and Cygwin is wrong here? I 
must be missing something obvious.


Ken


This is how I'm reading this, but I have not actually looked at or 
tried the posted code yet:


We use select() specifically when we are using non-blocking I/O. All 
the blocking happens in select() so we can track multiple sockets. If 
select() returns when there is no data available, it's not really 
doing its job, i.e. waiting for data. There are of course particular 
cases where something else (opening, closing) causes select() to 
return, which is normal and expected, but just because the reader is 
non-blocking is not a good reason for select() to return.


I should also mention that I use cygwin pipes extensively and have not 
encountered this behavior, so maybe I am doing things differently.




--
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: FIFO issues

[Norton Allen]

On 9/19/2022 5:25 PM, Ken Brown wrote:
You're probably not calling select to check for read ready on 
non-blocking FIFOs that have no writers.


Exactly what I was thinking (while on the bus).



--
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

character device canonical mode

[Norton Allen]

Apparently Cygwin does not support canonical mode on serial devices. On 
input canonical mode will wait for a newline before returning from a 
read(). The bit is cleared/ignored by tcsetattr() as demonstrated by a 
subsequent tcgetattr() in the test program below.


I am wondering if this is because of a fundamental difference between 
the Windows serial device model and POSIX or just because the 
appropriate mappings haven't been implemented. (I have studiously 
avoided Windows programming for decades, and Cygwin has been my enabler!)


My test program:

#include 
#include 
#include 
#include 
#include 
#include 

void check_rv(int rv, const char *where) {
  if (rv) {
    printf("Error %s: %d %s\n", where, errno, strerror(errno));
    exit(1);
  }
}

int main(int argc, char **argv) {
  termios termios_p;
  if (argc != 2) {
    printf("Must specify a serial device\n");
    exit(1);
  }
  int fd = open(argv[1], O_RDWR | O_NONBLOCK);
  check_rv(fd == -1, "opening serial device");
  check_rv(tcgetattr(fd, &termios_p), "from tcgetattr()");
  printf("c_lflag = 0x%X after open\n", termios_p.c_lflag);
  termios_p.c_lflag |= ICANON;
  printf("c_lflag = 0x%X to pass to tcsetattr()\n", termios_p.c_lflag);
  check_rv(tcsetattr(fd, TCSANOW, &termios_p), "from tcsetattr()");
  check_rv(tcgetattr(fd, &termios_p), "from 2nd tcgetattr()");
  printf("c_lflag = 0x%X after tcsetattr()\n", termios_p.c_lflag);
  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

chmod g+s ineffective

[Norton Allen]

On one machine I have, chmod g+s fails to set the sticky bit. The 
command does not return any error, but ls -l continues to show the bit 
not set.


   $ mkdir foo
   $ chgrp flight foo
   $ chmod g+ws foo
   $ ls -ld foo
   drwxrwxr-x+ 1 nort flight 0 Jun 29 06:50 foo

I ran strace, and it looks like the correct system call parameter is 
getting passed.


I am curious as to how the sticky bit is implemented. It isn't obvious 
what underlying Windows functionality (if any) is applied. Ah, just 
checked on a system where this works, and creating a file in the 
directory from the command shell does not set the group, so presumably 
this functionality is all within cygwin. That works for my application, 
except when it doesn't.


Any suggestions on what I should look for?

Cygwin Configuration Diagnostics
Current System Time: Wed Jun 29 13:04:51 2022

Windows 10 Enterprise Ver 10.0 Build 19044 

Path:   C:\cygwin64\usr\local\bin
C:\cygwin64\bin
C:\Program Files (x86)\Intel\iCLS Client
C:\Program Files\Intel\iCLS Client
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0
C:\WINDOWS\System32\OpenSSH
C:\Program Files\MATLAB\R2021a\bin
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL
C:\Program Files\Intel\Intel(R) Management Engine Components\DAL
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT
C:\Program Files\Intel\Intel(R) Management Engine Components\IPT
C:\Users\nort\AppData\Local\Microsoft\WindowsApps

Output from C:\cygwin64\bin\id.exe
UID: 197613(nort)  GID: 197121(None)
197121(None)   197614(flight)
545(Users) 4(INTERACTIVE)
66049(CONSOLE LOGON)   11(Authenticated Users)
15(This Organization)  113(Local account)
4095(CurrentSession)   66048(LOCAL)
262154(NTLM Authentication)401408(Medium Mandatory Level)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

USER = 'nort'
PWD = '/home/nort'
HOME = '/home/nort'

USERDOMAIN = 'EAS-SOFTWAREE1B'
OS = 'Windows_NT'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
PROCESSOR_LEVEL = '6'
PSModulePath = 'C:\Program 
Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules'
CommonProgramW6432 = 'C:\Program Files\Common Files'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
TZ = 'America/New_York'
HOSTNAME = 'EAS-SOFTWAREE1B'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/home/nort'
UATDATA = 'C:\Windows\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77'
USERNAME = 'nort'
LOGONSERVER = '\\EAS-SOFTWAREE1B'
PROCESSOR_ARCHITECTURE = 'AMD64'
LOCALAPPDATA = 'C:\Users\nort\AppData\Local'
COMPUTERNAME = 'EAS-SOFTWAREE1B'
FPS_BROWSER_APP_PROFILE_STRING = 'Internet Explorer'
!:: = '::\'
SYSTEMDRIVE = 'C:'
USERPROFILE = 'C:\Users\nort'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
SYSTEMROOT = 'C:\WINDOWS'
USERDOMAIN_ROAMINGPROFILE = 'EAS-SOFTWAREE1B'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 61 Stepping 4, GenuineIntel'
TMP = '/tmp'
LC_CTYPE = 'en_US.UTF-8'
TERM_PROGRAM = 'mintty'
TERM_PROGRAM_VERSION = '3.6.1'
OneDrive = 'C:\Users\nort\OneDrive'
PROCESSOR_REVISION = '3d04'
FPS_BROWSER_USER_PROFILE_STRING = 'Default'
PROFILEREAD = 'true'
NUMBER_OF_PROCESSORS = '4'
ProgramW6432 = 'C:\Program Files'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
APPDATA = 'C:\Users\nort\AppData\Roaming'
SHELL = '/bin/bash'
TERM = 'xterm'
WINDIR = 'C:\WINDOWS'
ProgramData = 'C:\ProgramData'
SHLVL = '1'
MINTTY_SHORTCUT = '/cygdrive/c/Users/nort/AppData/Roaming/Microsoft/Internet 
Explorer/Quick Launch/User Pinned/TaskBar/Cygwin Terminal.lnk'
PRINTER = 'Microsoft Print to PDF'
PROGRAMFILES = 'C:\Program Files'
ALLUSERSPROFILE = 'C:\ProgramData'
TEMP = '/tmp'
DriverData = 'C:\Windows\System32\Drivers\DriverData'
SESSIONNAME = 'Console'
ProgramFiles(x86) = 'C:\Program Files (x86)'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
HOMEDRIVE = 'C:'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info'
HOMEPATH = '\Users\nort'
ORIGINAL_PATH = '/cygdrive/c/Program Files (x86)/Intel/iCLS 
Client:/cygdrive/c/Program Files/Intel/iCLS 
Client:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program
 Files/MATLAB/R2021a/bin:/cygdrive/c/Program Files (x86)/Intel/Intel(R) 
Management Engine Components/DAL:/cygdrive/c/Program Files/Intel/Intel(R) 
Management Engine Components/DAL:/cygdrive/c/Program Files (x86)/Intel/Intel(R) 
Management Engine Components/IPT:/cygdrive/c/Program Files/Intel/Intel(R) 
Management Engine 
Components/IPT:/cygdrive/c/Users/nort/AppData/Local/Microsoft/WindowsApps'
EXECIGNORE = '*.dll'
VBOX_MSI_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\'
NSPR_NATIVE_THREADS_ONLY = '1'
_ = '/usr/bin/cygcheck'

HKEY_CURR

Re: chmod g+s ineffective

[Norton Allen]

On 6/29/2022 7:39 AM, Andrey Repin wrote:

Greetings, Norton Allen!


On one machine I have, chmod g+s fails to set the sticky bit. The command
does not return any error, but ls -l continues to show the bit not set.
 $ mkdir foo
 $ chgrp flight foo
 $ chmod g+ws foo
 $ ls -ld foo
 drwxrwxr-x+ 1 nort flight 0 Jun 29 06:50 foo

^

$ getfacl foo


I will collect this shortly, but IIRC, getfacl showed it was not set. I 
did see it set there under 'flags' on the system that works.






I ran strace, and it looks like the correct system call parameter is getting 
passed.
I am curious as to how the sticky bit is implemented.

First see if it was set or not.


It isn't obvious what underlying Windows functionality (if any) is applied.

It does. But the big question is, where do you try to do that.
If this is inside Cygwin installation root, then things could work more or
less POSIX'y. If this is outside Cygwin root (f.e. in your system profile), it
may or may not work completely, depends how did you mount /cygdrive prefix.


I will confirm (shortly), but I'm pretty sure these tests were done 
under vanilla /home (so c:\cygwin64\home)






Ah, just checked on a system where this works, and creating a file in the
directory from the
command shell does not set the group, so presumably this functionality is
all within cygwin. That works for my application, except when it doesn't.
Any suggestions on what I should look for?

Look if you could avoid using +s. Isn't DACL enough?


Am I correct that DACL is not available unless I am on a domain? This is 
for a field computer, so connection to a domain is generally more 
problematic than helpful.



--
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: chmod g+s ineffective

[Norton Allen]

On 6/29/2022 9:18 AM, Norton Allen wrote:

On 6/29/2022 7:39 AM, Andrey Repin wrote:

Greetings, Norton Allen!

On one machine I have, chmod g+s fails to set the sticky bit. The 
command

does not return any error, but ls -l continues to show the bit not set.
 $ mkdir foo
 $ chgrp flight foo
 $ chmod g+ws foo
 $ ls -ld foo
 drwxrwxr-x+ 1 nort flight 0 Jun 29 06:50 foo

^

$ getfacl foo


I will collect this shortly, but IIRC, getfacl showed it was not set. 
I did see it set there under 'flags' on the system that works.


   nort@EAS-SOFTWAREE1B ~
   $ ls -ld foo
   drwxrwxr-x 1 nort flight 0 Jun 29 06:25 foo

   nort@EAS-SOFTWAREE1B ~
   $ chmod g+s foo

   nort@EAS-SOFTWAREE1B ~
   $ ls -ld foo
   drwxrwxr-x 1 nort flight 0 Jun 29 06:25 foo

   nort@EAS-SOFTWAREE1B ~
   $ getfacl foo
   # file: foo
   # owner: nort
   # group: flight
   user::rwx
   group::rwx
   other::r-x







I ran strace, and it looks like the correct system call parameter is 
getting passed.

I am curious as to how the sticky bit is implemented.

First see if it was set or not.

It isn't obvious what underlying Windows functionality (if any) is 
applied.

It does. But the big question is, where do you try to do that.
If this is inside Cygwin installation root, then things could work 
more or
less POSIX'y. If this is outside Cygwin root (f.e. in your system 
profile), it
may or may not work completely, depends how did you mount /cygdrive 
prefix.


I will confirm (shortly), but I'm pretty sure these tests were done 
under vanilla /home (so c:\cygwin64\home)



Confirmed (as shown above). Tested in /home/nort on directory /home/nort/foo







Ah, just checked on a system where this works, and creating a file 
in the

directory from the
command shell does not set the group, so presumably this 
functionality is
all within cygwin. That works for my application, except when it 
doesn't.

Any suggestions on what I should look for?

Look if you could avoid using +s. Isn't DACL enough?


Am I correct that DACL is not available unless I am on a domain? This 
is for a field computer, so connection to a domain is generally more 
problematic than helpful.




So is this implemented using DACL under the hood? And is that expected 
to fail without a domain?



--
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: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[Norton Allen via Cygwin]

On 6/29/2024 1:39 AM, Brian Inglis via Cygwin wrote:

Hi folks,

Installed cygwin test to try to diagnose another issue - but not 
involved there.

Attempting to cygport upload - just hung without start ftp connection.
Reran cygport --debug upload and command hanging was ssh-add -l!
Confirmed by rerunning command ssh-add -l from bash.
Killed eventually with series of ctrl-C and ctrl-\.
Reran under strace and output log attached.
No version or help output from ssh-add so:
$ ssh -V
OpenSSH_9.7p1, OpenSSL 3.0.14 4 Jun 2024
After running setup and reinstalling 3.5.3, ssh-add -l works normally, 
and cygport upload succeeds to ftp package.

Only variable was the cygwin version installed.



I have experienced otherwise inexplicable hangs of ssh that have been 
resolved by killing ssh-agent and restarting it. This doesn't happen 
very often, so it is usually mystifying when it does occur -- until I 
remember.




--
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: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[Norton Allen via Cygwin]

On 6/29/2024 5:29 PM, Brian Inglis via Cygwin wrote:

On 2024-06-29 14:20, Norton Allen via Cygwin wrote:

On 6/29/2024 1:39 AM, Brian Inglis via Cygwin wrote:
Installed cygwin test to try to diagnose another issue - but not 
involved there.

Attempting to cygport upload - just hung without start ftp connection.
Reran cygport --debug upload and command hanging was ssh-add -l!
Confirmed by rerunning command ssh-add -l from bash.
Killed eventually with series of ctrl-C and ctrl-\.
Reran under strace and output log attached.
No version or help output from ssh-add so:
$ ssh -V
OpenSSH_9.7p1, OpenSSL 3.0.14 4 Jun 2024
After running setup and reinstalling 3.5.3, ssh-add -l works 
normally, and cygport upload succeeds to ftp package.

Only variable was the cygwin version installed.


I have experienced otherwise inexplicable hangs of ssh that have been 
resolved by killing ssh-agent and restarting it. This doesn't happen 
very often, so it is usually mystifying when it does occur -- until I 
remember.


I have *NEVER* had *ANY* issues using (Open)ssh etc. for remote login, 
shell, commands, file trees, or git (and earlier vcs) access, 
professionally and personally, over many years, releases, and systems, 
mainly from Cygwin/-X shells and sessions (due to using mainly Windows 
desktops with various Unix servers), with/out authorized_keys, 
passphrases, and/or keychain, until these recent instances under the 
test build.


I'm not above suspecting my problems arise from something unique in my 
setup, but it hasn't occurred often enough for me to investigate further.




--
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: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[Norton Allen via Cygwin]

On 6/29/2024 8:21 PM, Norton Allen via Cygwin wrote:


On 6/29/2024 5:29 PM, Brian Inglis via Cygwin wrote:

On 2024-06-29 14:20, Norton Allen via Cygwin wrote:

On 6/29/2024 1:39 AM, Brian Inglis via Cygwin wrote:
Installed cygwin test to try to diagnose another issue - but not 
involved there.

Attempting to cygport upload - just hung without start ftp connection.
Reran cygport --debug upload and command hanging was ssh-add -l!
Confirmed by rerunning command ssh-add -l from bash.
Killed eventually with series of ctrl-C and ctrl-\.
Reran under strace and output log attached.
No version or help output from ssh-add so:
$ ssh -V
OpenSSH_9.7p1, OpenSSL 3.0.14 4 Jun 2024
After running setup and reinstalling 3.5.3, ssh-add -l works 
normally, and cygport upload succeeds to ftp package.

Only variable was the cygwin version installed.


I have experienced otherwise inexplicable hangs of ssh that have 
been resolved by killing ssh-agent and restarting it. This doesn't 
happen very often, so it is usually mystifying when it does occur -- 
until I remember.


I have *NEVER* had *ANY* issues using (Open)ssh etc. for remote 
login, shell, commands, file trees, or git (and earlier vcs) access, 
professionally and personally, over many years, releases, and 
systems, mainly from Cygwin/-X shells and sessions (due to using 
mainly Windows desktops with various Unix servers), with/out 
authorized_keys, passphrases, and/or keychain, until these recent 
instances under the test build.


I'm not above suspecting my problems arise from something unique in my 
setup, but it hasn't occurred often enough for me to investigate further.


It wasn't clear to me whether your problem was readily reproducible. You 
repeated the ssh-add command, and it hung, but you didn't report having 
killed ssh-agent. If it was actually ssh-agent that was hung, I would 
absolutely expect ssh or ssh-add to hang trying to talk to it.


--
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

chmod g+ws unsuccessful, "NULL SID" icacls missing

[Norton Allen via Cygwin]

I briefly raised this issue months ago and am trying to resolve it again 
now.


What I am trying to do is setup permissions so multiple users on one 
machine can share full control over a particular directory hierarchy.


On Linux I have usually been able to make things work with:

   $ mkdir shared_dir
   $ chgrp shared_group shared_dir
   $ chmod g+ws shared_dir
   $ umask 2

User shells are configured with umask 2 so files they create have group 
write. Users belong to shared_group. Files and subdirs created under 
shared_dir are all in group shared_group. Files moved in retain their 
original group, but the group members still have permission to rename or 
delete them.


The problem:

$ chmod g+ws fails to set the 's' bit, and the resulting icacls output 
does not contain any "NULL SID" entries. I am seeing the same problem on 
(at least) two different systems setup by my organization. One of these 
was just re-imaged and I installed Cygwin yesterday with no customized 
configurations. AV is Windows Defender, but I suspect if that were the 
culprit, there would have been more noise.


I suspect there might be a group policy or something that is interfering 
with Cygwin's strategy for implementing POSIX permissions. I am pretty 
sure this worked correctly at some point in the past.


Has anyone encountered this?

Does group policy seem like a likely suspect? Anyone know which 
policy(ies)? I think I might be able to get IT to cut me slack if I knew 
what to ask for.


I have also played with using setfacl directly to add permissions, but 
as anyone who has read about Cygwin file permissions might guess, that 
tends to have mixed/poor results, but I'd be open to any suggestions.



--
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: chmod g+ws unsuccessful, "NULL SID" icacls missing

[Norton Allen via Cygwin]

On 2/8/2023 4:05 PM, Norton Allen via Cygwin wrote:
I briefly raised this issue months ago and am trying to resolve it 
again now.


What I am trying to do is setup permissions so multiple users on one 
machine can share full control over a particular directory hierarchy.


On Linux I have usually been able to make things work with:

   $ mkdir shared_dir
   $ chgrp shared_group shared_dir
   $ chmod g+ws shared_dir
   $ umask 2

User shells are configured with umask 2 so files they create have 
group write. Users belong to shared_group. Files and subdirs created 
under shared_dir are all in group shared_group. Files moved in retain 
their original group, but the group members still have permission to 
rename or delete them.


The problem:

$ chmod g+ws fails to set the 's' bit, and the resulting icacls output 
does not contain any "NULL SID" entries. I am seeing the same problem 
on (at least) two different systems setup by my organization. One of 
these was just re-imaged and I installed Cygwin yesterday with no 
customized configurations. AV is Windows Defender, but I suspect if 
that were the culprit, there would have been more noise.


I suspect there might be a group policy or something that is 
interfering with Cygwin's strategy for implementing POSIX permissions. 
I am pretty sure this worked correctly at some point in the past.


Has anyone encountered this?

Does group policy seem like a likely suspect? Anyone know which 
policy(ies)? I think I might be able to get IT to cut me slack if I 
knew what to ask for.


I have also played with using setfacl directly to add permissions, but 
as anyone who has read about Cygwin file permissions might guess, that 
tends to have mixed/poor results, but I'd be open to any suggestions.




I don't actually have a system on which this is working to compare to, 
so I am not exactly sure how it is supposed to look when it's working 
correctly. The current behavior on  my new uncustomized installation:


   $ cd /home
   $ mkdir foo
   $ ls -ld foo
   drwxr-xr-x 1 nort None 0 Feb  9 12:20 foo

   $ chgrp testflight foo
   $ ls -ld foo
   drwxr-xr-x 1 nort testflight 0 Feb  9 12:20 foo

   $ chmod g+w foo
   $ ls -ld foo
   drwxrwxr-x 1 nort testflight 0 Feb  9 12:21 foo

   $ chmod g+s foo
   $ ls -ld foo
   drwxrwxr-x 1 nort testflight 0 Feb  9 12:21 foo

Comparing getfacl and icacls output between the last two steps indicates 
that chmod g+s foo does exactly nothing. I ran strace on that and see 
that the chmod() call returns zero, but I don't know what's going inside 
that.


Any idea what g+s should be doing? Any more/better information I can 
provide?



--
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: chmod g+ws unsuccessful, "NULL SID" icacls missing

[Norton Allen via Cygwin]

On 2/9/2023 4:09 PM, Corinna Vinschen wrote:

Hi Norton,

On Feb  9 13:25, Norton Allen via Cygwin wrote:

On 2/8/2023 4:05 PM, Norton Allen via Cygwin wrote:

I briefly raised this issue months ago and am trying to resolve it again
now.

What I am trying to do is setup permissions so multiple users on one
machine can share full control over a particular directory hierarchy.

On Linux I have usually been able to make things work with:

    $ mkdir shared_dir
    $ chgrp shared_group shared_dir
    $ chmod g+ws shared_dir
    $ umask 2

User shells are configured with umask 2 so files they create have group
write. Users belong to shared_group. Files and subdirs created under
shared_dir are all in group shared_group. Files moved in retain their
original group, but the group members still have permission to rename or
delete them.

The problem:

$ chmod g+ws fails to set the 's' bit, and the resulting icacls output
does not contain any "NULL SID" entries. I am seeing the same problem on
(at least) two different systems setup by my organization. One of these
was just re-imaged and I installed Cygwin yesterday with no customized
configurations. AV is Windows Defender, but I suspect if that were the
culprit, there would have been more noise.

I suspect there might be a group policy or something that is interfering
with Cygwin's strategy for implementing POSIX permissions. I am pretty
sure this worked correctly at some point in the past.

Has anyone encountered this?

Does group policy seem like a likely suspect? Anyone know which
policy(ies)? I think I might be able to get IT to cut me slack if I knew
what to ask for.

I have also played with using setfacl directly to add permissions, but
as anyone who has read about Cygwin file permissions might guess, that
tends to have mixed/poor results, but I'd be open to any suggestions.


I don't actually have a system on which this is working to compare to, so I
am not exactly sure how it is supposed to look when it's working correctly.
The current behavior on  my new uncustomized installation:
[...]
Any idea what g+s should be doing? Any more/better information I can
provide?

What you observe is a bug in Cygwin, plain and simple.  Without going
into too much detail, part of the problem could never be observed with
older coreutils, which we had to live with for much too long in the
Cygwin distro.  The newer coreutils handles permissions slightly
differently and that dropped the mask from the buggy code.

I applied a patch which, hopefully, fixes this problem (in fact, plural,
"these problems").

A new Cygwin test release 3.5.0-0.162.g498fce80ef33 is just being built
and should be up in an hour or so.  You can simply install it via
Cygwin's setup tool as soon as it's on your favorite mirror.

If it works as desired, it will be part of the next Cygwin bugfix
release 3.4.6.


Thanks,
Corinna


Corinna,

The fix seems to work like a charm! And I am happy to be wrong about the 
source of the problem.




--
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: [ANNOUNCEMENT] Updated: setup (2.925)

[Norton Allen via Cygwin]

On 3/5/2023 9:00 AM, Jon Turney via Cygwin wrote:
- Various fixes around "All Users/"Just For Me" (thanks to Christian 
Franke for investigating these problems):


-- Fix a long-standing bug (since 2012), where installed files are 
owned by the user's primary group, rather than the Adminstrators 
group, when installing for "All Users".
-- We no longer change group back to the user's primary group while 
running postinstall scripts, when installing for "All Users". This was 
only for the benefit of mkgroup/mkpasswd being run by the postinstall 
script, which we don't do any more.
-- Fix "Just For Me" being ignored, when run with Admininstrator 
privileges
-- Fix "All Users" being selectable but basically ineffectual, when 
not run with Admininstrator privileges


Cool! I've just been dealing with multi-user installations for the first 
time in a serious way and encountered some of these issues. Nice to have 
a fix without even asking!




--
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

New install setup fails to create start menu bash link

[Norton Allen via Cygwin]

I have a new Windows 11 machine. I ran setup V2.925 with command-line 
options for my default set of packages, clicked through installation, 
and specified start menu but no desktop icon. Install seemed to go 
smoothly, but while there was a start menu folder for Cygwin with 
documentation, there was no "Cygwin64 Terminal" link.


I found the folder under /ProgramData/Microsoft/Windows/Start\ 
Menu/Programs/Cygwin, and the shortcut was there, but it had the wrong 
permissions. It showed up as ---rwxr-x. I executed chmod u+rx 'Cygwin64 
Terminal.lnk' and restarted, and now it shows up and works as expected.


Please let me know if I can shed any more light on what's going on here.




--
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: rand is not ISO C compliant in Cygwin

[Norton Allen via Cygwin]

On 11/10/2023 3:19 PM, Bruno Haible via Cygwin wrote:

ISO C 23 § 7.24.2.1 and 7.24.2.2 document how rand() and srand() are
expected to behave. In particular:
   "The srand function uses the argument as a seed for a new sequence
of pseudo-random numbers to be returned by subsequent calls to rand.
If srand is then called with the same seed value, the sequence of
pseudo-random numbers shall be repeated. ...
The srand function is not required to avoid data races with other
calls to pseudo-random sequence generation functions. ..."

The two attached programs call srand() in one thread and then rand()
in another thread. There is no data race, since the second thread
is only created after the call to srand() has returned. The behaviour
in Cygwin is that the values in the second thread ignore the srand()
call done in the first thread.


Since the standard is trying to be precise, this reads to me as though 
Cygwin/(newlib?) has chosen to avoid race conditions by making 
pseudo-random sequences in different threads independent. Although the 
standard does not require this, it does not prohibit it either.





How to reproduce the bug:

$ x86_64-pc-cygwin-gcc -Wall rand-in-posix-thread.c
$ ./a

or

$ x86_64-pc-cygwin-gcc -Wall rand-in-isoc-thread.c
$ ./a

Expected output:

Value from main thread: 1583559764
Value from separate thread: 1583559764

Actual output:

Value from main thread: 1583559764
Value from separate thread: 1481765933




--
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: Suggestion: [setup] Add an option to allow user to add "Open Cygwin Terminal Here" to Right-click menu

[Norton Allen via Cygwin]

On 2/10/2024 7:07 AM, Lee via Cygwin wrote:

Note: I hope this change would work on Windows 11 right-click menu. (Because I don't like 
"Show more options" or Shift + Right-click)

I'm still on Windows 10; I have no idea what does/doesn't work on Windows 11


chere gets the option onto the "Show more options" list. I agree that is 
less helpful than it was in Win10. If anyone knows how to get something 
to stay on the primary context menu, that would be great.



--
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: Suggestion: [setup] Add an option to allow user to add "Open Cygwin Terminal Here" to Right-click menu

[Norton Allen via Cygwin]

On 2/10/2024 10:03 AM, Norton Allen via Cygwin wrote:

On 2/10/2024 7:07 AM, Lee via Cygwin wrote:
Note: I hope this change would work on Windows 11 right-click menu. 
(Because I don't like "Show more options" or Shift + Right-click)
I'm still on Windows 10; I have no idea what does/doesn't work on 
Windows 11


chere gets the option onto the "Show more options" list. I agree that 
is less helpful than it was in Win10. If anyone knows how to get 
something to stay on the primary context menu, that would be great.



The Internet answers:

   reg add
   
HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32
   /ve /d "" /f

As found here:

https://answers.microsoft.com/en-us/windows/forum/all/windows-11-right-click-explorer-menu-show-more-as/ba8dafe4-306a-403b-af0d-10a6d1ca0a9a

--
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: Suggestion: [setup] Add an option to allow user to add "Open Cygwin Terminal Here" to Right-click menu

[Norton Allen via Cygwin]

On 2/14/2024 3:00 PM, Brian Inglis via Cygwin wrote:

Surely you mean (-v displays confirmation):

$ regtool add -v 
/proc/registry/HKEY_CURRENT_USER/Software/Classes/CLSID/{86ca1aa0-34aa-4e8b-a509-50c905bae2a2} 


Key {86ca1aa0-34aa-4e8b-a509-50c905bae2a2} created
$ regtool add -v 
/proc/registry/HKEY_CURRENT_USER/Software/Classes/CLSID/{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}/InprocServer32 


Key InprocServer32 created
$ regtool list -pv 
/proc/registry/HKEY_CURRENT_USER/Software/Classes/CLSID/{86ca1aa0-34aa-4e8b-a509-50c905bae2a2} 


InprocServer32\ ()

;^>


But of course! Thanks



--
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: cygport upload seems to ignore SSH_KEY

[Norton Allen via Cygwin]

On 12/18/2024 3:37 PM, Federico Kircheis via Cygwin wrote:

On 18/12/2024 20.38, Eliot Moss wrote:

On 12/18/2024 2:30 PM, Federico Kircheis via Cygwin wrote:

On 05/11/2024 18.31, Federico Kircheis wrote:

On 05/11/2024 18.29, ASSI via Cygwin wrote:

Federico Kircheis via Cygwin writes:

I also did a chmod/chown on the file to ensure that the permission
where correct.
The file with the permission unchanged worked without issues when
moved in ~/.ssh.


Whatever directory that file resides in must be readable only by the
owner or SSH will not use it.


Regard,
Achim.


Mhm, that could be it.
I did not try to modify the permission of the directory.



Nope.

Directory has permission 0700, file has permission 0600, just to be 
sure I've execute chmod on both.

I can access they key but I still experienced the issue


$ ls -la $SSH_KEY
-rw---+ 1 Administrators None 3357 Dec 20  2019 /cygdrive/c/ 
cygport-ps/ssh/id_rsa_cyg


$ ls -la /cygdrive/c/cygport-ps/ssh/
total 13
drws--S---+ 1 Administrators None    0 Jan 14  2023 .
drwxrwx---+ 1 Administrators None    0 Dec 18 10:55 ..
-rw---+ 1 Administrators None 3357 Dec 20  2019 id_rsa_cyg
-rw---+ 1 Administrators None  745 Jul 25  2018 id_rsa_cyg.pub
-rw---+ 1 Administrators None  236 Mar 18  2020 known_hosts


If I manually execute lftp



$ lftp sftp://cygwin:@cygwin.com
lftp cygwin@cygwin.com:~> cd .
cd `.' [Connecting...]


and hangs.

I'm not sure how to debug the issue further, and the relation 
between all tools.



$ sftp sftp://cygwin:@cygwin.com
cygwin:@cygwin.com: Permission denied (publickey).
Connection closed


I guess lftp/sftp does not support the variable SSH_KEY, as I get 
the same "Permission denied (publickey)." error with "ssh -v sftp:// 
cygwin:@cygwin.com", and I see that there is no attempt to use my 
ssh key


Also following command does not report an error:


sftp -i $SSH_KEY sftp://cygwin:@cygwin.com
Connection closed by 8.43.85.97 port 22
Connection closed



Curious.  I'm not an expert, but I tend to put info in my ssh config 
file.  Does that help here?


And, probably grasping at straws, are you sure SSH_KEY is exported :-) ?

Some people who are more expert might have better suggestions ... 
Eliot Moss




Yes, I'm sure it is exported, and currently even copying the file in 
.ssh does not work, which did work last time (I get the exact same 
behavior), thus ATM I'm unable to push an update.


Maybe an issue server-side?

As far as I know, neither sftp nor ssh support the environment variable 
SSH_KEY, but if you are passing it on the command line as below, it 
doesn't need to.


Have you tried adding the '-v' option to report verbose status? That 
will let you know if it is trying to use the specified key.




--
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