Re: Warning message in Astrotortilla 0.8 Alpha-1
>Using Astrotortilla 0.8 Alpha-1, while doing a blind solve, the message bel= >ow appears on the second and third lines of the LogWindow: >Line 2:=C2=A0 0[main} bash 12504 find_fast_cwd: WARNING: Couldn't compute F= >AST_CWD pointer. Please report this problem to=20 >Line 3:=C2=A0 the public mailing list cygwin@cygwin.com >I'm reporting it. The program still works. https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- 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
Issue:"fatal error - can't create tty_list::mutex" with cygwin1.5 gcc3.4.4 on windows 10
Hi, all Recently our operation system will upgrade to windows10 and we have many projects built by cygwin1.5 with GCC3.4.4, so we try to do validation by run the gcc3.4.4 test suite on windows10, as the title description, I got a error: gcc 17812 C:\cygwin\bin\gcc.exe: *** fatal error - can't create tty_list::mutex 'cygwin1S4.tty_list::mutex.0', Win32 error 6 so any advice supplied, please? Thanks. -- Sent from: http://cygwin.1069669.n5.nabble.com/Cygwin-list-f3.html -- 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
2019 CCTV Accessories for Partner
Hello, Dear Manager, Good day, This is Kevin from INSTARGO, original CCTV Accessories supplier. We are factory produce a wide range of CCTV Accessories, POE switch, Tester, Power Supply, IR Lighting, BNC Connector, CCTV Housing & Bracket,Wire/Cable, Microphone,Video Balun, Lens, package etc. All of the products are high quality with 100% QC test before shipping. Welcome your inquiry. Regards, Kevin
Re: bash bug, setup, or permissions?
Hi, did you fix the issue? If do, please give me some suggestions since I encounter the same error recently. Thanks very much. -- Sent from: http://cygwin.1069669.n5.nabble.com/Cygwin-list-f3.html -- 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
Warning message in Astrotortilla 0.8 Alpha-1
Using Astrotortilla 0.8 Alpha-1, while doing a blind solve, the message below appears on the second and third lines of the LogWindow: Line 2: 0[main} bash 12504 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to Line 3: the public mailing list cygwin@cygwin.com I'm reporting it. The program still works. -- 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
using chown with SMB3 network share
I've read every web page I could find that was related to the subject, but still coming up empty. None of the standard solutions of updating /etc/passwd or /etc/group or removing same seem to work: The environment: Cygwin (patched less than 2 weeks behind current) running in a VM under a domain admin account. It runs as a service that is used for archive and restore of files. The network shares are Isilon exporting SMB2+. There are some default ACLs in place. * The user can create, modified, or delete any file put into the restore directory. No problem. * setfacl works to change permissions * the creation/owner of the file looks ok. There's no 'unknown group' message (typical question on StackExchange) * chown and chmod fail with 'invalid argument'. It doesn't whether I do it by a uid or a name, it fails with invalid argument * icacls can be used to give full access to a file, but it's not the same as changing ownership and changing permissions to match how they were when they got archived.. * chown/chmod work fine on the local NTFS filesystem under the VM, just not against the Isilon SMB share. Thoughts on where to go from here? pEpkey.asc Description: application/pgp-keys -- 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 bash script removing equal sign
Am 25.04.2019 um 18:11 schrieb Peter Palaparthy: > Cygwin bash script is removing equals sign from command call. On what basis did you conclude it was bash doing that, and not, say, make? > *Here is the relevant command in my makefile.* > *$(elabcmd) = $(XELAB_DEFAULT) \-generic VERSION=10* I believe for that to be a syntactically valid line in a Makefile would take some more Makefile code on top of it. If you don't show the actual file you use (or a suitably trimmed, yet self-contained abstract of it), you're making it impossibly hard for people to help you. > *compile:$(elabcmd)* Same problem here. signature.asc Description: OpenPGP digital signature
Re: Cygwin bash script removing equal sign
On 4/25/2019 12:11 PM, Peter Palaparthy wrote: Cygwin bash script is removing equals sign from command call. How do I escape it so that = is sent to command? I tried different things like escaping = with \ and enclosing it with "" and '' but none of them worked. *Here is the relevant command in my makefile.* *$(elabcmd) = $(XELAB_DEFAULT) \-generic VERSION=10* *compile:$(elabcmd)* *Here is the result:* cygwin prompt:> make compile *Running: xelab.exe -generic VERSION 10* *(note that the equal sign is not there)* I want *xelab.exe -generic VERSION=10* - I am not sure you need the \ on the - - I wonder about the $(elabcmd) = ... My expectation would be elabcmd = ... - compile: ... is giving a dependency. It seems you want a rule. In make, this would look more like: compile: xelab.exe xelab.exe -generic VERSION=10 Making this more parameterized: elabcmd = xelab.exe -generic VERSION=10 compile: xelab.exe $(elabcmd) (Note: There is a TAB (not space), before that last $(elabcmd).) Anyway, while I am happy to help a little, this is a generic Make question, not specific to Cygwin ... EM -- 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: bug: cygwin-devel v3.0.2-1 socket.h does not #define MSG_EOR per the POSIX standard
Am 25.04.2019 um 17:48 schrieb Eric Blake: > On 4/25/19 10:28 AM, Brian Inglis wrote: >> Would it be allowed and valid to #define MSG_EOR 0 to simplify lack of >> support? > > No, because that implies that EVERY send() call is requesting MSG_EOR > and that it never fails. And maybe more importantly, it's explicitly required to be non-zero. -- 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: bug: cygwin-devel v3.0.2-1 socket.h does not #define MSG_EOR per the POSIX standard
On Apr 24 15:50, Eric Blake wrote: > On 4/24/19 3:36 PM, Hans-Bernhard Bröker wrote: > > Am 24.04.2019 um 19:54 schrieb Eliot Moss: > >> On 4/24/2019 12:43 PM, Corinna Vinschen wrote: > > > >>> Since MSG_EOR isn't implemented in the underlying transport layer, > >>> there's no way to implement it in userspace. That's why it's not > >>> defined in Cygwin's headers. If you have an idea how to implement > >>> this in plain userspace, feel free to provide patches. > >> > >> I don't have a direct interest in this issue, but I do have a wondering. > >> If Cygwin fails to define an error code -- even if the error cannot > >> actually happen under Cygwin -- isn't that a problem when trying to > >> compile imported software? > > > > Well, MSG_EOR is not an error, but we can certainly do better than not > defining it at all. My suggestion for the least-cost implementation: > > - add a define for MSG_EOR to a non-zero value that is bitwise distinct > from other required MSG_ values > - return EOPNOTSUPP on attempts to use the flag in > send()/sendmsg()/sendto() (POSIX permits that failure for protocols that > don't support it - and none of Cygwin's protocols support it) > - optionally, document that MSG_EOR will never be set in the results > returned by recvmsg() (POSIX says it will only be set on protocols that > support it - and none of Cygwin's protocols support it) > > This will at least let software compile that attempts to use it, and > hopefully that software is robust to the fact that send() may reject the > flag and that recvmsg() cannot reliably report use of that flag. Interesting. I really thought it's better that a programm does not compile, rather than it compiles and misbehaves from the POV of the developer. I added the MSG_EOR definition and send(2) and friends return EOPNOTSUPP now. I uploaded a snapshot to https://cygwin.com/snapshots/ with this change. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Cygwin bash script removing equal sign
Cygwin bash script is removing equals sign from command call. How do I escape it so that = is sent to command? I tried different things like escaping = with \ and enclosing it with "" and '' but none of them worked. *Here is the relevant command in my makefile.* *$(elabcmd) = $(XELAB_DEFAULT) \-generic VERSION=10* *compile:$(elabcmd)* *Here is the result:* cygwin prompt:> make compile *Running: xelab.exe -generic VERSION 10* *(note that the equal sign is not there)* I want *xelab.exe -generic VERSION=10* Thanks for any help. -- 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: bug: cygwin-devel v3.0.2-1 socket.h does not #define MSG_EOR per the POSIX standard
On 4/25/19 10:28 AM, Brian Inglis wrote: >> - add a define for MSG_EOR to a non-zero value that is bitwise distinct >> from other required MSG_ values >> - return EOPNOTSUPP on attempts to use the flag in >> send()/sendmsg()/sendto() (POSIX permits that failure for protocols that >> don't support it - and none of Cygwin's protocols support it) >> >> although I personally thought POSIX was clear enough that MSG_EOR is >> required to be defined, even if only so that it can trigger send() >> errors showing that it is unsupported. > > Would it be allowed and valid to #define MSG_EOR 0 to simplify lack of > support? No, because that implies that EVERY send() call is requesting MSG_EOR and that it never fails. Defining it to a distinct non-zero value makes it possible to report EOPNOTSUPP. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: bug: cygwin-devel v3.0.2-1 socket.h does not #define MSG_EOR per the POSIX standard
On 2019-04-24 14:50, Eric Blake wrote: > On 4/24/19 3:36 PM, Hans-Bernhard Bröker wrote: >> Am 24.04.2019 um 19:54 schrieb Eliot Moss: >>> On 4/24/2019 12:43 PM, Corinna Vinschen wrote: >> Since MSG_EOR isn't implemented in the underlying transport layer, there's no way to implement it in userspace. That's why it's not defined in Cygwin's headers. If you have an idea how to implement this in plain userspace, feel free to provide patches. >>> >>> I don't have a direct interest in this issue, but I do have a wondering. >>> If Cygwin fails to define an error code -- even if the error cannot >>> actually happen under Cygwin -- isn't that a problem when trying to >>> compile imported software? >> > > Well, MSG_EOR is not an error, but we can certainly do better than not > defining it at all. My suggestion for the least-cost implementation: > > - add a define for MSG_EOR to a non-zero value that is bitwise distinct > from other required MSG_ values > - return EOPNOTSUPP on attempts to use the flag in > send()/sendmsg()/sendto() (POSIX permits that failure for protocols that > don't support it - and none of Cygwin's protocols support it) > - optionally, document that MSG_EOR will never be set in the results > returned by recvmsg() (POSIX says it will only be set on protocols that > support it - and none of Cygwin's protocols support it) > > This will at least let software compile that attempts to use it, and > hopefully that software is robust to the fact that send() may reject the > flag and that recvmsg() cannot reliably report use of that flag. > >> >> Either way, as Standardese goes, this is sufficiently unclear that it >> IMHO calls for a defect report to the governing body of this standard. > > You're welcome to do so: > http://austingroupbugs.net/main_page.php > > although I personally thought POSIX was clear enough that MSG_EOR is > required to be defined, even if only so that it can trigger send() > errors showing that it is unsupported. Would it be allowed and valid to #define MSG_EOR 0 to simplify lack of support? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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
Now rate your web page highly
Hi Cygwin, I'm Audrey Sometimes a loss of your website visibility is rather straightforward. If you're entirely out of luck, and worried that your website might be experiencing a visibility loss, you're in the right place. By means of a new technology, you can learn how you can get on top of search engines. This technology is not based on Pay Per Click model. You pay fixed price for keyword and we give you exclusive rights to keywords during a full year with guaranteed minimum amount of traffic on each keyword. If you want to see how it works, you can: 1. Go to our website and try online demo. 2. Enter the keywords that you want to own and your website cygwin com. 3. See the result of the online demo. See you shortly, Audrey -- 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
