Re: Problem with Cygwin 2.4.0-0.18 release
Hi, On Tue, Jan 12, 2016 at 5:05 PM, Corinna Vinschen wrote: > I tried to workaround this problem by "upgrading" the DLL load > mechanism to use the facilities available since Vista. In theory > this should work fine for you. I uploaded a new developer snapshot > to https://cygwin.com/snapshots/ Please give it a try. Sadly still getting the same error. ismail -- 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: getaddrinfo fails with EAI_NODATA for some valid hosts with A records
Corinna Vinschen cygwin.com> writes: > On Jan 7 15:39, Brian Inglis wrote: >> getaddrinfo fails with err 7 EAI_NODATA for some valid hosts with A records. >> Err 7 EAI_NODATA is mapped from WSANO_DATA err 11004 in Windows. >> Can anyone reproduce failure with problem host name below? > > Yes, I can reproduce it, and it's a total surprise. > I have no idea why Windows' getaddrinfo chokes on leapsecond.utcd.org > at all. Especially when after just one getaddrinfo call, the DNS cache is populated with: leapsecond.utcd.org Record Name . . . . . : leapsecond.utcd.org Record Type . . . . . : 1 Time To Live . . . . : 600 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 244.34.36.97 so the DNS server is being contacted and responding normally, but it would appear Windows GAI is failing to use that info. Has this been reproduced on W10 so we can report this upstream? Is there any support without an account for upstream W7 reports? -- 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: Problems with lxml package
On Tue, Jan 12, 2016 at 6:30 PM, Yaakov Selkowitz wrote: > On 2016-01-12 03:34, Christian-Manuel Röderer wrote: >> >> Sorry, just forgot the "3" in the names above. I have python3-lxml >> installed (as well >> as python-lxml) and also have the same problem with python2 (see below). >> etree seems to be missing. > > http://lxml.de/tutorial.html > http://lxml.de/compatibility.html Sorry, I don't understand how this helps. In the script I want to run I am using lxml functionality so using a different ElementTree will not work. Also, the script runs on a Debian with python3-lxml installed and used to run in cygwin in the past. Kind regards, Chris -- 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: Problem with Cygwin 2.4.0-0.18 release
Ismail Donmez i10z.com> writes: > Sadly still getting the same error. No such problems for a server runnning 2012R2 here... Regards, Achim. -- 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: Problem with Cygwin 2.4.0-0.18 release
On Jan 13 09:59, Ismail Donmez wrote: > Hi, > > On Tue, Jan 12, 2016 at 5:05 PM, Corinna Vinschen > wrote: > > I tried to workaround this problem by "upgrading" the DLL load > > mechanism to use the facilities available since Vista. In theory > > this should work fine for you. I uploaded a new developer snapshot > > to https://cygwin.com/snapshots/ Please give it a try. > > Sadly still getting the same error. That doesn't make sense. The new code has a fallback which is identical to the code in -0.17. No offence, but are you *sure* you're using the snapshot DLL? Uname on 64 bit should print: $ uname -srvm $ CYGWIN_NT-6.1 2.4.0(0.293/5/3) 2016-01-12 14:54 x86_64 Can you re-check, please? [...testing myself...] Ok, so I just set up sshd on a W7 64 bit machine and I can actually reproduce the problem with -0.18. However, it starts to work fine for me with the snapshot! So I added debug output to the Cygwin DLL and there's something strange going on on W7 64. When loading ws2_32.dll in this single instance of logging in to sshd, the LoadLibrary call to ws2_32.dll fails in one of the child processes with a stack overflow. The *next* call to LoadLibrary works fine, though. My debug output inspected the stack. Quick introduction for those not overly familiar with this stuff: - AllocationBase is the memory address the stack has been reserved at. - StackLimit is the lowest address of the committed region on the stack. StackLimit is always > AllocationBase and < StackBase. - FramePointer is the value of the $ebp register which denotes the current stack usage in this function. FramePointer is always > StackLimit and < StackBase. - StackBase is the uppermost address of the stack, the address from where the stack grows downward. Given this, low values of StackLimit mean a high stack pressure, high values a low stack pressure. Here are the stack values on Windows 10 before and after the LoadLibrary call to ws2_32.dll which works on W10 and W8.1 but fails on W7: AllocationBaseFramePointer StackLimitStackBase Windows 10: before: 0xFFE0 0xAE60 0xBE80 0x1 after : 0xFFE0 0x9000 0xBE80 0x1 Windows 8.1: before: 0xFFE0 0xAE60 0xBE80 0x1 after : 0xFFE0 0xAE60 0xBE80 0x1 Windows 7: 0xFFE0 0xAE60 0xBE80 0x1 0xFFE0 0xFFE01000 0xBE80 0x1 ^^ So, before the call to LoadLibrary, the stack is completely correct, as on W10 and W8.1. However, after the LoadLibrary call, the StackLimit has changed to the maximum possible value. What does that mean? For some reason LoadLibrary(ws2_32.dll) took up all space available on the stack and then failed because there was no more stack. Interesting enough, the *next* call to LoadLibrary then worked as expected. Why this happens? I have no idea. Probably a bug in W7. So, Ismail, please test again if you're really using the snapshot DLL. The fact that I can reproduce the problem *and* fix it by running the snapshot, *and* reproducibly create the error on W7, but not on W8.1 or W10 indicates to me that this sould be fixed for you as well. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Problem with Cygwin 2.4.0-0.18 release
On Wed, Jan 13, 2016 at 12:45 PM, Corinna Vinschen wrote: > On Jan 13 09:59, Ismail Donmez wrote: >> Hi, >> >> On Tue, Jan 12, 2016 at 5:05 PM, Corinna Vinschen >> wrote: >> > I tried to workaround this problem by "upgrading" the DLL load >> > mechanism to use the facilities available since Vista. In theory >> > this should work fine for you. I uploaded a new developer snapshot >> > to https://cygwin.com/snapshots/ Please give it a try. >> >> Sadly still getting the same error. > > That doesn't make sense. The new code has a fallback which is identical > to the code in -0.17. No offence, but are you *sure* you're using the > snapshot DLL? Uname on 64 bit should print: > > $ uname -srvm > $ CYGWIN_NT-6.1 2.4.0(0.293/5/3) 2016-01-12 14:54 x86_64 Sorry for that, indeed somehow it overwrite the cygwin1.dll I guess because I ran setup.exe first and it re-installed -0.18 and then I manually overwrited cygwin1.dll but somehow failed. Anyhow it works now, thanks! Regards, ismail -- 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: getaddrinfo fails with EAI_NODATA for some valid hosts with A records
On Jan 13 08:14, Brian Inglis wrote: > Corinna Vinschen cygwin.com> writes: > > On Jan 7 15:39, Brian Inglis wrote: > >> getaddrinfo fails with err 7 EAI_NODATA for some valid hosts with A > >> records. > >> Err 7 EAI_NODATA is mapped from WSANO_DATA err 11004 in Windows. > >> Can anyone reproduce failure with problem host name below? > > > > Yes, I can reproduce it, and it's a total surprise. > > > I have no idea why Windows' getaddrinfo chokes on leapsecond.utcd.org > > at all. > > Especially when after just one getaddrinfo call, the DNS cache is populated > with: > leapsecond.utcd.org > > Record Name . . . . . : leapsecond.utcd.org > Record Type . . . . . : 1 > Time To Live . . . . : 600 > Data Length . . . . . : 4 > Section . . . . . . . : Answer > A (Host) Record . . . : 244.34.36.97 > > so the DNS server is being contacted and responding normally, but it would > appear Windows GAI is failing to use that info. > Has this been reproduced on W10 so we can report this upstream? I can reproduce this on W10 as well. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
RE: cron bug
> -Original Message- > From: Stefan Götz > Sent: Wednesday, January 13, 2016 12:55 AM > > > Hello, > > I have set up cron as below on a fresh Windows 10 with a fresh, > minimal 64-bit Cygwin installation. Cronjobs are not executed and cronevents says /usr/sbin/cron: > PID 608: (CRON) error (can't switch user context). The output of cronbug is attached. > > When I run the service not under my own user but as an administrator, the > result and error is the same. > > > Thanks! Any advice is appreciated. > > > $ cron-config Thanks for sending the cronbug.txt, Stefan. It shows that although you asked to run as yourself the daemon is actually running under the SYSTEM account. That explains the error message, but I wonder why cron-config misbehaves. That hasn't changed in years. Are you logged in with your "Windows id" (instead of as your local user id)? If so there has been a similar case that has never been fully explained. Could you do the following: Edit /bin/cron-config and uncomment the second line (set -x) Run the modified cron-config, reproducing exactly what you do usually (remove the service, ask to run as yourself). The details of what the script does will be echoed. Then paste the whole output in an e-mail, you can send it to me privately. Pierre -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.18
On Jan 12 22:17, random user wrote: > Something I wasn't aware of at the time of our prior discussion is > that the Linux NTFS-3g driver already supports Linux extended ACLs > on NTFS. This is discussed at > > http://www.tuxera.com/community/ntfs-3g-advanced/ownership-and-permissions/ > > I explored taking a flash card back and forth between Cygwin > 2.4.0-0.18 and a Linux system, testing how each interprets what the > other wrote. > > I find they don't seem to interpret each other's per-group and mask > permission bits correctly when creating their Posix interpretation of > an NTFS ACL. > > I also find that somehow setting extended ACLs on Linux for a > directory is causing Cygwin to then see that object as a socket, if > I'm reading the below correctly. 'ls' on Cygwin won't descend into > that as it normally would for a directory, > bash: cd: dir_acl: Not a directory > results when attempting to cd into it, etc. > > I don't know how common such uses are, but I do use both Cygwin and > Linux on the same flash cards and external disks. If they are both > going to support Posix-style extended ACLs written to NTFS, it'd seem > nice if they could do so in compatible ways. Cygwin is trying to create an ACL with least possible entries while at the same time being POSIX compatible. Apart from the NULL SID deny ACE to keep mask info and special bits, it's a pretty normal ACL. It's a bit late now to change how Cygwin constructs and evaluates ACLs. I'll take a look into the dir vs. socket thingy, but no guarantee that I can change that for 2.4.0. > bash 1 34 # ls -al > total 0 > drwx--+ 1 sally sally 0 Jan 12 20:42 . > drwx--+ 1 sally sally 0 Jan 12 20:40 .. > srwxr-+ 1 sally sally 0 Jan 12 20:42 dir_acl > -rwxr-+ 1 sally sally 0 Jan 12 20:42 file_acl > -rw--- 1 sally sally 0 Jan 12 20:41 file_simple Weird. The only way to set the filetype to socket is if the file is a Cygwin symlink (file with system DOS bit set and starting with the string "!". > [...] > bash 1 41 # getfacl dir_acl > # file: dir_acl > # owner: sally > # group: sally > user::rwx > group::--- > group:julia:r-- > mask:r-- > other:--- > default:user::rwx > default:group::--- > default:other:--- > [...] > bash 1 42 # icacls dir_acl > dir_acl CYGWIN\julia_ug:(NP)(DENY)(W,Rc,WO,X,DC) > Everyone:(OI)(IO)(DENY)(S,X) > CYGWIN\sally:(NP)(F) > CYGWIN\julia_ug:(NP)(RX,W,DC) > CYGWIN\sally_ug:(NP)(DENY)(W,Rc,WO,X,DC) > Everyone:(NP)(Rc,S,REA,RA) > CYGWIN\sally:(OI)(CI)(IO)(F) > Everyone:(OI)(CI)(IO)(Rc,S,REA,RA) It will be hard to reproduce such an ACL. It's just as non-standard as a Cygwin ACL, just differently so. What bugs me is the deny ACE for sally_ug which looks pretty weird to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Quotes changed to odd characters in gcc error msgs
Hello,
I am running Cygwin 2.3.0 on Windows 7. I'm new to Cygwin and trying to
learn C programming (basic ANSI C).
I'm having 2 problems.
1) When I get an error message from the gcc compiler, the quotes in the
message are turned to high ascii characters that don't make sense. How do
I fix this? My TERM variable says "cygwin".
2) I'm using PSPad to edit some of my .C files. Since I've started using
PSPad, the directory listing of files using 'ls -l' has the occasional
file concatenated with the next file, like a carriage return is missing
somewhere. I am using colors, and load .dircolors in my .bashrc each time
I start Cygwin. Here is what I added to the bottom of my .bashrc:
function funclm
{
# Use --grou-directories-first
ls -hlF --color $@|more
}
function funcls
{
ls -hF --color $@|more
}
alias envm='env|sort|less'
alias findit='echo See locate'
alias h='history'
alias lf='funclf'
alias lm='funclm'
alias ls='funcls'
alias mv='mv -v'
alias perltext='perldoc -t -T'
alias src='source $HOME/.bashrc'
export EDITOR=nedit
# Stuff for X windows and nedit.
DISPLAY=10.19.251.67:0.0; export DISPLAY
export PAGER=/usr/bin/less
# Misc stuff
export PATH=./:$PATH
eval `dircolors -b $HOME/.dircolors`
Thank you.
Chuck
--
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: cron bug
> Hello, > > I have set up cron as below on a fresh Windows 10 with a fresh, > minimal 64-bit Cygwin installation. Cronjobs are not executed and cronevents says /usr/sbin/cron: > PID 608: (CRON) error (can't switch user context). The output of > cronbug is attached. > > When I run the service not under my own user but as an administrator, > the result and error is the same. First I try not to make any assumptions about what the user knows about cron. So here are some tips. - In general, do not edit the system crontab files, instead edit your user crontab files with 'crontab -e' where '-e' means edit. You will need an environment variable to setup an editor like this: 'export EDITOR=nedit'. You can put the whole path to nedit in there if need be. So, what is the exact command you are using to edit the crontab files? - When the cron job runs it runs in it's own shell, with no environment variables at all, i.e. no PATH or anything. To set environment variables add these entries to the crontab file: PATH=/usr/bin:/sbin:/whatever MAIL=youruser (sends email to this account) Each time cron runs and produces output, an email is sent to the account in the MAIL variable. - Next, the command must include the full path to the command like this: 1 18 29 1 * /home/comp/perl/me/gocron If gocron is a bash script which calls a Perl program, I always pass the working directory to my Perl program inside the 'gocron' bash script. I think I had trouble getting the current directory inside my Perl script with $t=`pwd`;. It would work during testing outside of cron, but when it was run by cron, pwd didn't work. I also test my bash scripts with the 'at' command, which works very much like cron, but with less typing. The at format is: at -f FILETORUN TIMESPEC Example: at -f /path/to/file/gocron now (run now) Example: at -f /path/to/file/gocron + 1 minute (run 1 minute from now) Example: at -f /path/to/file/gocron 2:05pm (runs at 2:05pm based on the server time) This runs my gocron bash script after 1 minute passes. See the man page for 'at' for more info on the TIMESPEC format. Chuck -- 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
Is there an easy way to find the version of Cygwin I have?
Including the bit depth, 32 or 64-bit. Plus critical DLL files. Thanks! Chuck -- 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: Is there an easy way to find the version of Cygwin I have?
On 2016-01-13 16:36, Chuck Roberts wrote: > Including the bit depth, 32 or 64-bit. Plus critical DLL files. uname -a What critical DLL files are you looking for? You can also run cygcheck -c to check the versions of the packages you have installed. signature.asc Description: OpenPGP digital signature
Re: Quotes changed to odd characters in gcc error msgs
On 1/13/2016 10:05 AM, Chuck Roberts wrote: Hello, I am running Cygwin 2.3.0 on Windows 7. I'm new to Cygwin and trying to learn C programming (basic ANSI C). I'm having 2 problems. 1) When I get an error message from the gcc compiler, the quotes in the message are turned to high ascii characters that don't make sense. How do I fix this? My TERM variable says "cygwin". These are probably Unicode curly quotes. They should display properly if you use one of the standard Cygwin terminals (such as mintty or xterm). Ken -- 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
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.19
Hi Cygwin friends and users, I released TEST version 2.4.0-0.19 of Cygwin. Another last test release to fix the issue reported in https://cygwin.com/ml/cygwin/2016-01/msg00131.html I still plan to release officially on Friday. What's new: --- - New, unified implementation of POSIX permission and ACL handling. The new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and they allow to inherit the S_ISGID bit. ACL inheritance now really works as desired, in a limited, but theoretically equivalent fashion even for non-Cygwin processes. To accommodate standard Windows ACLs, the POSIX permissions of the owner and all other users in the ACL are computed using the Windows AuthZ API. This may slow down the computation of POSIX permissions noticably in some circumstances, but is generally more correct. The new code also ignores SYSTEM and Administrators group permissions when computing the MASK/CLASS_OBJ permission mask on old ACLs, and it doesn't deny access to SYSTEM and Administrators group based on the value of MASK/CLASS_OBJ when creating the new ACLs. The new code now handles the S_ISGID bit on directories as on Linux: Setting S_ISGID on a directory causes new files and subdirs created within to inherit its group, rather than the primary group of the user who created the file. This only works for files and directories created by Cygwin processes. - New mount type "usertemp" which allows to mount a POSIX directory to the Windows per-user temporary directory. - cygpath has a new -U option, which creates cygdrive paths using the unambiguous /proc/cygdrive prefix. - New API: rpmatch. What changed: - - Align setfacl(1) usage a bit closer to the usage on Linux. Rename -d option to -x, --substitute to --set. Add --no-mask and --mask options. Allow to use the -b and -k option combined to allow reducing an ACL to only reflect standard POSIX permissions. - Fix (numeric and monetary) decimal point and thousands separator in fa_IR and ps_AF locales to be aligned with Linux. - utmpname/utmpxname are now defined as int functions as on Linux. Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00320.html Bug Fixes - - Not a bug fix as such, but a workaround for new behaviour in Windows 10 version 1511 64 bit. This version introduces a problem which existed in a similar variation (just vice versa) in XP and Server 2003 64 bit as well. An unexpected stack arrangement when starting a 64 bit Cygwin application from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork. Addresses: https://cygwin.com/ml/cygwin/2015-12/msg3.html - Replaced old, buggy strtold implementation with well-tested gdtoa version from David M. Gay. Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00205.html - Fix handling of relative paths in native symlinks if the target is in a drive's root dir or one level below. Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00277.html - Fix a SEGV when calling `kill -l 0'. Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00430.html - Fix a race condition in signal handling. Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00387.html - Fix a potential crash reading invalid passwd and group entries from /etc/passwd and /etc/group. Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00170.html - Cygpath(1) now tries to correct the case of system directories when returned as POSIX paths. Addresses: https://cygwin.com/ml/cygwin/2016-01/msg2.html - *Always* zero out descriptor arrays when returning from select due to timeout, per POSIX. Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00332.html - Return unique inode numbers when calling stat/fstat on pipes and IP sockets. Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00310.html Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: getaddrinfo fails with EAI_NODATA for some valid hosts with A records
> -Original Message- > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of > Brian Inglis > Sent: Wednesday, January 13, 2016 12:14 AM > To: cygwin@cygwin.com > Subject: Re: getaddrinfo fails with EAI_NODATA for some valid hosts with A > records > > Corinna Vinschen cygwin.com> writes: > > On Jan 7 15:39, Brian Inglis wrote: > >> getaddrinfo fails with err 7 EAI_NODATA for some valid hosts with A > >> records. > >> Err 7 EAI_NODATA is mapped from WSANO_DATA err 11004 in Windows. > >> Can anyone reproduce failure with problem host name below? > > > > Yes, I can reproduce it, and it's a total surprise. > > > I have no idea why Windows' getaddrinfo chokes on leapsecond.utcd.org > > at all. > > Especially when after just one getaddrinfo call, the DNS cache is populated > with: > leapsecond.utcd.org > > Record Name . . . . . : leapsecond.utcd.org > Record Type . . . . . : 1 > Time To Live . . . . : 600 > Data Length . . . . . : 4 > Section . . . . . . . : Answer > A (Host) Record . . . : 244.34.36.97 > > so the DNS server is being contacted and responding normally, but it would > appear Windows GAI is failing to use that info. > Has this been reproduced on W10 so we can report this upstream? > Is there any support without an account for upstream W7 reports? > > DNS just translates URLs to IP addresses. It is no surprise that works. However, addresses in the range 240.0.0.0 - 255.255.255.255 are reserved. Windows is probably blocking that as a "favor". Net Range 240.0.0.0 - 255.255.255.255 CIDR240.0.0.0/4 NameSPECIAL-IPV4-FUTURE-USE-IANA-RESERVED Handle NET-240-0-0-0-0 Parent Net TypeIANA Special Use Origin AS OrganizationInternet Assigned Numbers Authority (IANA) Registration Date Last Updated2013-08-30 CommentsAddresses starting with 240 or a higher number have not been allocated and should not be used, apart from 255.255.255.255, which is used for "limited broadcast" on a local network. This block was reserved by the IETF, the organization that develops Internet protocols, in the Standard document and in RFC 1112. The documents can be found at: http://datatracker.ietf.org/doc/rfc1112 RESTful Linkhttp://whois.arin.net/rest/net/NET-240-0-0-0-0 See AlsoRelated organization's POC records. See AlsoRelated delegations. -- 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: Quotes changed to odd characters in gcc error msgs
On Jan 13, 2016, at 8:05 AM, Chuck Roberts wrote: > > My TERM variable says "cygwin”. That means you’re running under the built-in Windows console, not MinTTY, which means you don’t get UTF-8 support by default. You could try “chcp 65001” but the real fix is to use MinTTY. MinTTY has *many* features not available in the Windows Console. Even the vastly upgraded version included with Windows 10 is a pale wannabe compared to MinTTY. man mintty for details. > 2) I'm using PSPad to edit some of my .C files. Careful, there. Unix is traditionally case-sensitive, and some programs coming from that tradition treat .C files differently from .c files. One such tool is gcc, which will interpret your file as C++ even if you invoke it as gcc instead of g++. GNU make also assumes .C is C++. C++ is not 100% forwards compatible with C: https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B On Windows, NTFS is case-insensitive by default, but also case-preserving, so saving a file as *.C will invoke this automatic C++ treatment under Cygwin. > the directory listing of files using 'ls -l' has the occasional > file concatenated with the next file, like a carriage return is missing > somewhere. This may be a Windows Console bug, too. Again, switch to MinTTY. It’s the default for a reason. -- 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: Quotes changed to odd characters in gcc error msgs
[Let's keep the discussion on the mailing list.] On 1/13/2016 11:28 AM, Chuck Roberts wrote: -Original Message- From Ken Brown On 1/13/2016 10:05 AM, Chuck Roberts wrote: Hello, I am running Cygwin 2.3.0 on Windows 7. I'm new to Cygwin and trying to learn C programming (basic ANSI C). I'm having 2 problems. 1) When I get an error message from the gcc compiler, the quotes in the message are turned to high ascii characters that don't make sense. How do I fix this? My TERM variable says "cygwin". These are probably Unicode curly quotes. They should display properly if you use one of the standard Cygwin terminals (such as mintty or xterm). Ken Got it! I did this then added these commands to my .bashrc: export TERM=mintty export LANG=en_US Bad idea. mintty sets TERM to the appropriate value (which happens to be xterm). And you probably want LANG to be en_US.UTF-8; but you don't have to set it yourself. It's done by the script /etc/profile.d/lang.sh, which is run by /etc/profile. Ken -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.18
>> It's a bit late now to change how Cygwin constructs and evaluates ACLs. Sorry, with the holidays and other issues it wasn't possible for me to look at the test drops earlier. Going production with a new Cygwin NTFS ACL layout incompatible with NTFS-3g's already-existing layout would seem a long-term decision regarding Cygwin <-> Linux interoperability. Please consider. On 01/13/2016 07:12 AM, Corinna Vinschen wrote: > On Jan 12 22:17, random user wrote: >> Something I wasn't aware of at the time of our prior discussion is >> that the Linux NTFS-3g driver already supports Linux extended ACLs >> on NTFS. This is discussed at >> >> http://www.tuxera.com/community/ntfs-3g-advanced/ownership-and-permissions/ >> >> I explored taking a flash card back and forth between Cygwin >> 2.4.0-0.18 and a Linux system, testing how each interprets what the >> other wrote. >> >> I find they don't seem to interpret each other's per-group and mask >> permission bits correctly when creating their Posix interpretation of >> an NTFS ACL. >> >> I also find that somehow setting extended ACLs on Linux for a >> directory is causing Cygwin to then see that object as a socket, if >> I'm reading the below correctly. 'ls' on Cygwin won't descend into >> that as it normally would for a directory, >> bash: cd: dir_acl: Not a directory >> results when attempting to cd into it, etc. >> >> I don't know how common such uses are, but I do use both Cygwin and >> Linux on the same flash cards and external disks. If they are both >> going to support Posix-style extended ACLs written to NTFS, it'd seem >> nice if they could do so in compatible ways. > Cygwin is trying to create an ACL with least possible entries while at > the same time being POSIX compatible. Apart from the NULL SID deny ACE > to keep mask info and special bits, it's a pretty normal ACL. > > It's a bit late now to change how Cygwin constructs and evaluates ACLs. > I'll take a look into the dir vs. socket thingy, but no guarantee that > I can change that for 2.4.0. > >> bash 1 34 # ls -al >> total 0 >> drwx--+ 1 sally sally 0 Jan 12 20:42 . >> drwx--+ 1 sally sally 0 Jan 12 20:40 .. >> srwxr-+ 1 sally sally 0 Jan 12 20:42 dir_acl >> -rwxr-+ 1 sally sally 0 Jan 12 20:42 file_acl >> -rw--- 1 sally sally 0 Jan 12 20:41 file_simple > Weird. The only way to set the filetype to socket is if the file is a > Cygwin symlink (file with system DOS bit set and starting with the > string "!". > >> [...] >> bash 1 41 # getfacl dir_acl >> # file: dir_acl >> # owner: sally >> # group: sally >> user::rwx >> group::--- >> group:julia:r-- >> mask:r-- >> other:--- >> default:user::rwx >> default:group::--- >> default:other:--- >> [...] >> bash 1 42 # icacls dir_acl >> dir_acl CYGWIN\julia_ug:(NP)(DENY)(W,Rc,WO,X,DC) >> Everyone:(OI)(IO)(DENY)(S,X) >> CYGWIN\sally:(NP)(F) >> CYGWIN\julia_ug:(NP)(RX,W,DC) >> CYGWIN\sally_ug:(NP)(DENY)(W,Rc,WO,X,DC) >> Everyone:(NP)(Rc,S,REA,RA) >> CYGWIN\sally:(OI)(CI)(IO)(F) >> Everyone:(OI)(CI)(IO)(Rc,S,REA,RA) > It will be hard to reproduce such an ACL. It's just as non-standard as > a Cygwin ACL, just differently so. What bugs me is the deny ACE for > sally_ug which looks pretty weird to me. > > > Corinna > -- 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: getaddrinfo fails with EAI_NODATA for some valid hosts with A records
On 2016-01-13 10:03, Andy Hall wrote: -Original Message- From: cygwin On Behalf Of Brian Inglis Corinna Vinschen writes: On Jan 7 15:39, Brian Inglis wrote: getaddrinfo fails with err 7 EAI_NODATA for some valid hosts with A records. Err 7 EAI_NODATA is mapped from WSANO_DATA err 11004 in Windows. Can anyone reproduce failure with problem host name below? Yes, I can reproduce it, and it's a total surprise. I have no idea why Windows' getaddrinfo chokes on leapsecond.utcd.org at all. Especially when after just one getaddrinfo call, the DNS cache is populated with: leapsecond.utcd.org Record Name . . . . . : leapsecond.utcd.org Record Type . . . . . : 1 Time To Live . . . . : 600 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 244.34.36.97 so the DNS server is being contacted and responding normally, but it would appear Windows GAI is failing to use that info. Has this been reproduced on W10 so we can report this upstream? Is there any support without an account for upstream W7 reports? DNS just translates URLs to IP addresses. It is no surprise that works. However, addresses in the range 240.0.0.0 - 255.255.255.255 are reserved. Windows is probably blocking that as a "favor". Net Range 240.0.0.0 - 255.255.255.255 CIDR240.0.0.0/4 Name SPECIAL-IPV4-FUTURE-USE-IANA-RESERVED HandleNET-240-0-0-0-0 Parent Net TypeIANA Special Use Origin AS Organization Internet Assigned Numbers Authority (IANA) Registration Date Last Updated 2013-08-30 CommentsAddresses starting with 240 or a higher number have not been allocated and should not be used, apart from 255.255.255.255, which is used for "limited broadcast" on a local network. This block was reserved by the IETF, the organization that develops Internet protocols, in the Standard document and in RFC 1112. The documents can be found at: http://datatracker.ietf.org/doc/rfc1112 RESTful Linkhttp://whois.arin.net/rest/net/NET-240-0-0-0-0 See Also Related organization's POC records. See AlsoRelated delegations. See also IANA services and ports reservations which have been ignored since Windows devs got a connection to the world outside their PC (cough Citrix!) Reserved just means it won't be assigned, but as illustrated by my OP and Linux tests, it has been usable since CIDR/VLSM came in RFCs 1517-1519 in 1993, and routable since RFC 1812 in 1995 supported Classless Inter Domain Routing and Variable Length Subnet Masking. The private reserved address ranges are bogon territory for routers; the most that can be said about 240/8 is possible bogosity: that space is available for global internet use without any guarantees what devices, hosts, protocols, and services will interoperate. IANA considered releasing the 248M addresses for assignment a few years ago but decided it was not worth it, as it would only delay exhaustion of IP V4 space for 18 months, and some crufty old gear and stacks (cough Windows!) may not support it (as we saw and you said) for some functions. Regardless of that, the DNS lookup function should operate normally: implementing mechanism not policy; if some higher layer wants to apply a policy on use of those addresses, *THAT*'s what we have filters for. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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
