Editors set x-bit (sometimes)
Does anybody have an explanation for the following strange phenomenon? When I create Ruby files (*.rb) with an, the files end up with the x-bit set with some editors, while this does not happen with some other editors. This is annoying, because when I use git to put the file in a repository, and the repository is later read on Linux, the incorrect x-bit is applied there too. The text editors where this happens, do so consistently, as long as the file is below my Ruby HOME directory. It does not happen, if I store the file outside my $HOME, say in c:\tmp. Since a few editors do not show this behaviour, one might blame the way the editor creates the file. However, these text editors were not written with a Cygwin environment in mind, and Windows doesn't have the concept of an "executable bit", and it happens only if I create files below my Cygwin Home, so I think this happens when Cygwin tries to "infer" the x-bit from some other file properties. I am aware that Cygwin has a policy to infer, whether the x-bit should be set or not set. Nevertheless, this does not apply in my case: - The files don't have a #! line - I don't have a file association on Windows which would mark a .rb file as being run by Ruby - My file system is ntfs BTW, my CYGWIN environment variable is set to just 'nodosfilewarning'. I'm using Windows 7 and the 64-bit-version of Cygwin. - Ronald -- 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.6.1-0.2
Hi folks, I uploaded a new Cygwin test release 2.6.1-0.2. 2.6.1 will be a bugfix release only and the last release in 2016. New fixes compared to -0.1: - cygwin_conv_path/cygwin_create_path now also check for .exe suffix when converting a POSIX path to Windows notation. - Address Windows bug in path conversion on network shares for non-existing paths. Addresses: https://cygwin.com/ml/cygwin-developers/2016-12/msg8.html === What's new: --- - Add _PC_CASE_INSENSITIVE flag to [f]pathconf(3). Bug Fixes - - Fix regression in console charset handling Addresses: https://cygwin.com/ml/cygwin/2016-10/msg0.html - Fix case-sensitivity problem when renaming directories Addresses: https://cygwin.com/ml/cygwin/2016-09/msg00264.html - Fix SetThreadName with gdb 7.10 on x86 Addresses: https://cygwin.com/ml/cygwin/2016-09/msg00143.html - Fix broken newlocale handling with empty local string "". Found by Coverity. - Fix assorted buffer overflows and resource leaks found by Coverity. - Correctly define __hidden macro on Cygwin. Addresses: https://cygwin.com/ml/cygwin/2016-10/msg00294.html - Fix page count in /proc//statm and /proc//status. Addresses: https://cygwin.com/ml/cygwin-patches/2016-q4/msg8.html - Don't allow sending invalid signals from user space - Fix path handling of ".//" sequences. Addresses: https://cygwin.com/ml/cygwin/2016-11/msg00295.html - cygwin_conv_path/cygwin_create_path now also check for .exe suffix when converting a POSIX path to Windows notation. - Address Windows bug in path conversion on network shares for non-existing paths. Addresses: https://cygwin.com/ml/cygwin-developers/2016-12/msg8.html === Thanks, 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: Editors set x-bit (sometimes)
On 12/13/2016 5:39 AM, Ronald Fischer wrote: Does anybody have an explanation for the following strange phenomenon? When I create Ruby files (*.rb) with an, the files end up with the x-bit set with some editors, while this does not happen with some other editors. This is annoying, because when I use git to put the file in a repository, and the repository is later read on Linux, the incorrect x-bit is applied there too. The text editors where this happens, do so consistently, as long as the file is below my Ruby HOME directory. It does not happen, if I store the file outside my $HOME, say in c:\tmp. Since a few editors do not show this behaviour, one might blame the way the editor creates the file. However, these text editors were not written with a Cygwin environment in mind, and Windows doesn't have the concept of an "executable bit", and it happens only if I create files below my Cygwin Home, so I think this happens when Cygwin tries to "infer" the x-bit from some other file properties. Does this help? https://cygwin.com/faq/faq.html#faq.using.same-with-permissions 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: Editors set x-bit (sometimes)
> Does this help? > > https://cygwin.com/faq/faq.html#faq.using.same-with-permissions While interesting, it seems to describe a different phenomenon. Actually, when I create files by Cygwin tools only (touch, nano, ), the access rights are always correct. Indeed, even after removing the extended ACL entries - as was suggested in the FAQ -, the problem still appears. However, I have a new finding: When I create a file from a CMD.EXE command line, by i.e. echo xx > abc.rb the access rights *do* have the x-bits set! This is reproducible, but only when the file which was created, is below my Cygwin tree! I agree that this smells a lot like an extended ACL issue, but as I said, setacl -b provided no help. Ronald -- Ronald Fischer http://www.fusshuhn.de/ -- 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] Updated: setup.exe (Release 2.877)
A new version of Setup, release 2.877, has been uploaded to https://cygwin.com/setup-x86.exe (32 bit version) https://cygwin.com/setup-x86_64.exe (64 bit version) Changes compared to 2.876: - Restore the Alt-V keyboard accelerator for the package view selection control - Enable searching for package names longer than will fit in the search edit box, by allowing the text in the edit box to horizontally scroll - Disable the next button if the 'Root Directory' edit box is empty - Fix a crash which could occur with a corrupt /etc/setup/installed.db - Start package chooser in "Pending" view if this is not a first time installation - The supported setup.ini syntax has been extended to allow more than 3 versions of a package - Use the English words 'Keep', 'Current' and 'Test' as button labels in the package chooser page. - A few source code cleanups Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com. -- 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
Periodic search for FAQ link update for clean_setup.pl?
Looking for suggestions on cleaning up package directories, https://cygwin.com/faq/faq.html#faq.setup.disk-space has a broken link, again, to clean_setup.pl ? Mailing list search finds: https://sourceware.org/ml/cygwin/2009-06/msg00573.html that has an old version attached, 1.0700 (2003-07-02). Is a newer version available or is that the latest, and could the FAQ link be fixed? 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
PHP 7.0.14 crashing with minimal set of extensions
Greetings, All! Here's strace and stackdump from latest crash with Cygwin 2.6.1-2 project.rootdir.org/.offload/crash-php-7.14.tar.xz I've tried full Cygwin rebase to no avail. Particularly, I've attempted to run Composer test suite. -- With best regards, Andrey Repin Tuesday, December 13, 2016 21:02:57 Sorry for my terrible english... -- 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
git diff --color-words doesn't work properly
When a .gitattributes file specifies a diff and the locale is utf8, "git diff --color-words" fails with the message "fatal: Invalid regular expression [a-zA-Z_][a-zA-Z0-9_]*|[-+0-9.e]+[fFlL]?|0[xXbB]?[0-9a-fA-F]+[lLuU]*|[-+*/<>%&^|=!]=|--|\+\+|<<=?|>>=?|&&|\|\||::|->\*?|\.\*|[^[:space:]]|[-][<80>-]+". This does not happen with Git for Windows. To reproduce it, run the following commands in an empty directory: git init echo "* diff=cpp" > .gitattributes git add .gitattributes # This works LC_ALL=C git diff --staged --color-words # This fails LC_ALL=en_US.UTF-8 git diff --staged --color-words # It also fails if the locale is set to any other utf8 locale (e.g. en_GB.UTF-8, ja_JP.UTF-8, etc). The issue appears to be in regcomp.c's wgetnext function, which calls mbrtowc, which fails because the regex isn't valid utf-8. The easy fix is probably to either remove the non-ASCII characters from that regex (it's defined in git's userdiff.c) or change it to a unicode codepoint range (i.e. U+0080-U+10), but I don't know if that would break anything else. The attached cygcheck.out has my email address redacted, but is otherwise unmodified. cygcheck.out Description: Binary data -- 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: Setup not asking for proxy user,password / was Resend: pdfseparate does nothing for me?
On Mon, 12/12/16, Achim Gratz wrote: Subject: Re: Setup not asking for proxy user,password / was Resend: pdfseparate does nothing for me? To: cygwin@cygwin.com Date: Monday, December 12, 2016, 1:40 PM Ian Lambert via cygwin writes: > Maybe a comparison of how wget handles > authentication versus how setup handles it > could help? The problem is on your side and I cannot reproduce it. So that analysis (which I've asked for earlier) either comes from you or you'll have to wait until someone else can reproduce it. In any case, I've verified that setup.exe does ask for the user/password if it gets the required 407 error response from a proxy requiring authentication and then correctly uses that proxy for the remainder of the session. = = = The output from testing with wget and setup verbose is here: https://cygwin.com/ml/cygwin/2016-12/msg00034.html After skimming wget and setup sources, my guess is it has something to do with "basic" versus NTLM authentication. I saw enough to know setup source is not nearly as thoroughly commented as wget, and both are too complicated for me. :D Is there any chance of getting similar outputs from behind your proxy, to look for differences with mine? 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: Editors set x-bit (sometimes)
On 2016-12-13 08:20, Ronald Otto Valentin Fischer wrote: >On 2016-12-13 10:57, Ken Brown wrote: >> Does this help? >> https://cygwin.com/faq/faq.html#faq.using.same-with-permissions > While interesting, it seems to describe a different phenomenon. > Actually, when I create files by Cygwin tools only (touch, nano, > ), the access rights are always correct. Indeed, even after > removing the extended ACL entries - as was suggested in the FAQ -, > the problem still appears. > However, I have a new finding: When I create a file from a CMD.EXE > command line, by i.e. > echo xx > abc.rb > the access rights *do* have the x-bits set! This is reproducible, > but only when the file which was created, is below my Cygwin tree! > I agree that this smells a lot like an extended ACL issue, but as > I said, setacl -b provided no help. Remove DACLs Default ACLs also on directories using: setfacl -bk ~/.[!.]* ~/.[!.]*/**/ ~/.[!.]*/**/* \ /???/**/ /???/**/* /sbin/ /sbin/* - that takes a while to run, and you may get a few anonymous setfacl: Permission denied messages - paths in the messages would have been nice here! Be careful *NOT* to hit Windows directories including your Windows home directory, or any other Windows directories, native symlinks, native hardlinks, junctions, or file types such as Windows .lnk, .URL, etc. where Windows may rely on the DACLs, ACLs, and attributes for proper handling. I don't know that removing them would cause problems, but I don't trust Windows to DTRT if it doesn't see what it expects, or DTRT in future if changes are made and the expected settings are not still in place. -- -- 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
Re: PHP 7.0.14 crashing with minimal set of extensions
On 2016-12-13 11:06, Andrey Repin wrote: > Here's strace and stackdump from latest crash with Cygwin 2.6.1-2 > project.rootdir.org/.offload/crash-php-7.14.tar.xz > I've tried full Cygwin rebase to no avail. > Particularly, I've attempted to run Composer test suite. strace? stackdump? attachments? cygcheck -svr? Remember - mailer *MUST* attach as text to get thru! -- 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
Re: Editors set x-bit (sometimes)
Brian Inglis writes: > Remove DACLs Default ACLs also on directories using: > setfacl -bk ~/.[!.]* ~/.[!.]*/**/ ~/.[!.]*/**/* \ > /???/**/ /???/**/* /sbin/ /sbin/* > - that takes a while to run, and you may get a few anonymous > setfacl: Permission denied > messages - paths in the messages would have been nice here! > > Be careful *NOT* to hit Windows directories including your Windows > home directory, or any other Windows directories, native symlinks, > native hardlinks, junctions, or file types such as Windows .lnk, > .URL, etc. where Windows may rely on the DACLs, ACLs, and attributes > for proper handling. Which is why you shouldn't use the above, but have find produce a list of the files to be changed and when you are sure it doesn't contain any stray things process them either via the -exec + option in find or piping into xargs (the latter is slightly less efficient and you have to do -print0/-0, but I tend to get it right more easily then the -exec stuff. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: Editors set x-bit (sometimes)
I find I can reproduce the OP's observations, and the most recent advice doesn't fix it (although it changes the symptoms): >From mintty/bash: 639> cd /tmp 641> ls -ld . drwxrwxr-x+ 1 ht None 0 Dec 13 19:55 ./ 640> getfacl . # file: . # owner: ht # group: None user::rwx group::rwx other:r-x default:user::rwx default:group::r-x default:other:r-x 642> touch x3 643> ls -l x3 -rw-r--r-- 1 ht None 0 Dec 13 19:59 x3 Switch to CMD (not elevated): C:\Users\ht>cd ..\..\C64\tmp C:\C64\tmp>echo > x2 C:\C64\tmp> Back to mintty/bash: 644> ls -l x2 -rwxr-xr-x 1 ht None 13 Dec 13 20:00 x2* OK, try the advice 645> setfacl -bk . 649> getfacl . # file: . # owner: ht # group: None user::rwx group::rwx other:r-x 646> echo > y3 647> ls -l y3 -rw-r--r-- 1 ht None 1 Dec 13 20:01 y3 Over to CMD: C:\Users\ht>cd ..\..\C64\tmp C:\C64\tmp>echo > y2 C:\C64\tmp> And back to mintty/bash: 648> ls -l y2 -rwxrwx---+ 1 ht None 13 Dec 13 20:02 y2* 650> ls -ld . drwxrwxr-x 1 ht None 0 Dec 13 20:02 ./ 652> setfacl -bk y2 653> ls -l y2 -rwx-- 1 ht None 13 Dec 13 20:02 y2* Windows 10 Professional N Ver 10.0 Build 10586 3229k 2016/08/31 C:\C64\bin\cygwin1.dll Cygwin DLL version info: DLL version: 2.6.0 ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- 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: Setup not asking for proxy user,password / was Resend: pdfseparate does nothing for me?
On 2016-12-13 11:43, Ian Lambert via cygwin wrote: > On Mon, 12/12/16, Achim Gratz wrote: >> Ian Lambert via cygwin writes: >>> Maybe a comparison of how wget handles authentication versus how >>> setup handles it could help? >> The problem is on your side and I cannot reproduce it. So that >> analysis (which I've asked for earlier) either comes from you or >> you'll have to wait until someone else can reproduce it. In any case, >> I've verified that setup.exe does ask for the user/password if it >> gets the required 407 error response from a proxy requiring >> authentication and then correctly uses that proxy for the remainder >> of the session. > The output from testing with wget and setup verbose is here: > https://cygwin.com/ml/cygwin/2016-12/msg00034.html > After skimming wget and setup sources, my guess is it has something > to do with "basic" versus NTLM authentication. I saw enough to know > setup source is not nearly as thoroughly commented as wget, and both > are too complicated for me. :D > Is there any chance of getting similar outputs from behind your > proxy, to look for differences with mine? Maybe your proxy is not properly handling unexpected User Agent or other header strings from wget and setup. Have you tried curl - curl often outputs only the HTTP message, and you can then add options to generate the correct responses or handling. Both curl and wget each support some user specified header addition and modification options. Note that setup seems to require and support only Basic authentication and does not process any negotiation, so if your proxy can or does not fall back to support Basic authentication, only NTLM, you're hooped! Have you tried using apt-cyg or another alternate installer? I could suggest https://github.com/BrianInglis/apt-cyg/raw/wget-non-verbose/apt-cyg ;^> as it has been patched to handle installing dependencies and postinstall scripts but does not (yet?) handle upgrades except by manually removing and (re-)installing packages. You may have to do your setup and package downloads via apt-cyg, wget, or IE to your packages directories and use setup to do installs from there. -- 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
Re: PHP 7.0.14 crashing with minimal set of extensions
Greetings, Brian Inglis! > On 2016-12-13 11:06, Andrey Repin wrote: >> Here's strace and stackdump from latest crash with Cygwin 2.6.1-2 >> project.rootdir.org/.offload/crash-php-7.14.tar.xz >> I've tried full Cygwin rebase to no avail. >> Particularly, I've attempted to run Composer test suite. > strace? stackdump? attachments? cygcheck -svr? > Remember - mailer *MUST* attach as text to get thru! 40MB strace? As attach? I'm not sure you're serious. -- With best regards, Andrey Repin Wednesday, December 14, 2016 00:37:29 Sorry for my terrible english... -- 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: PHP 7.0.14 crashing with minimal set of extensions
On 2016-12-13 14:37, Andrey Repin wrote: > Greetings, Brian Inglis! >> On 2016-12-13 11:06, Andrey Repin wrote: >>> Here's strace and stackdump from latest crash with Cygwin >>> 2.6.1-2 >>> project.rootdir.org/.offload/crash-php-7.14.tar.xz >>> I've tried full Cygwin rebase to no avail. >>> Particularly, I've attempted to run Composer test suite. >> strace? stackdump? attachments? cygcheck -svr? >> Remember - mailer *MUST* attach as text to get thru! > 40MB strace? As attach? I'm not sure you're serious. Ah, you meant: *http://*project.rootdir.org/.offload/crash-php-7.14.tar.xz *40MB* strace for someone to look at? I'm not sure *you're* serious. Complete info is good but reasonable summary is more workable. Could perhaps junk the boilerplate strace env and dll setup chunks and file lookups; or just post stackdump and the last part of the strace with the symptoms leading up to the crash; maybe the last part of the PHP log, with an STC to provoke failure, to get someone's interest piqued to look further? -- 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
Re: [ANNOUNCEMENT] llvm 3.8.1-1
On 12/7/16, Yaakov Selkowitz wrote: > On 2016-12-07 17:57, Roger Pack wrote: >> Awesome. I tried building 3.9.0 today and ran into >> >> llvm-3.9.0.src/lib/Support/Unix/Signals.inc:418:5: error: ‘Dl_info’ >> was not declared in this scope >> Dl_info dlinfo; > > Already fixed upstream: > > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Support/Unix/Signals.inc?r1=282919&r2=283427 > > I plan to look at rebasing sometime after 3.9.1 is out. OK that fixed my initial problem with 3.9.0 the next failure after that (with both 3.9.0 and 3.9.1) is Scanning dependencies of target LLVMPasses [ 64%] Building CXX object lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o /usr/lib/gcc/x86_64-pc-cygwin/5.4.0/../../../../x86_64-pc-cygwin/bin/as: CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o: too many sections (34877) /tmp/ccTGhQkv.s: Assembler messages: /tmp/ccTGhQkv.s: Fatal error: can't write CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o: File too big so I guess I'll look forward to your release, I guess 3.9.1 was just cut. Thanks! -roger- -- 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
new setup.exe doesn't collapse package sets in full view.
I downloaded the new setup program (2.877, 32-bit) and ran it on a cygwin installation that hadn't been updated in over a year (2008R2). I first got the Pending view, OK, then switched to Full and found that the packages were not aggregated into tabs-- they were in one very long alphabetical list. I am wondering whether the more convenient tabbed view is still available and if others are also seeing this issue. I tried a different download source, same issue. I have tried with server that hadn't been updated in >1 year, and server that was updated last week. Same issue. Can the tabbed view be retained as an option, even for pre-existing installations? Thanks. Thanks, Stephen Carrier -- 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: new setup.exe doesn't collapse package sets in full view.
On 12/13/2016 6:02 PM, Stephen Paul Carrier wrote: I downloaded the new setup program (2.877, 32-bit) and ran it on a cygwin installation that hadn't been updated in over a year (2008R2). I first got the Pending view, OK, then switched to Full and found that the packages were not aggregated into tabs-- they were in one very long alphabetical list. I am wondering whether the more convenient tabbed view is still available and if others are also seeing this issue. I think what you want is the "Category" view. 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] Updated [test]: bash-4.4.5-1
A new release of bash, 4.4.5-1, has been uploaded and will soon reach a mirror near you. For now it is marked experimental, and requires the use of experimental readline7-7.0.1-1 (leaving bash 4.3.48-8 as the current version). But if no major complaints are raised during testing, this will be promoted to current in a few days. NEWS: = This is a new upstream release. There are a few things you should be aware of before using this version: 1. When using binary mounts, cygwin programs try to emulate Linux. Bash on Linux does not understand \r\n line endings, but interprets the \r literally, which leads to syntax errors or odd variable assignments. Therefore, you will get the same behavior on Cygwin binary mounts by default. 2. d2u is your friend. You can use it to convert any problematic script into binary line endings. 3. Cygwin text mounts automatically work with either line ending style, because the \r is stripped before bash reads the file. If you absolutely must use files with \r\n line endings, consider mounting the directory where those files live as a text mount. However, text mounts are not as well tested or supported on the cygwin mailing list, so you may encounter other problems with other cygwin tools in those directories. 4. This version of bash has a cygwin-specific set option, named "igncr", to force bash to ignore \r, independently of cygwin's mount style. As of bash-3.2.3-5, it controls regular scripts, command substitution, and sourced files; bash-4.3.43-5 adds the read builtin to the list. I hope to convince the upstream bash maintainer to accept this patch into a future bash release even on Linux, rather than keeping it a cygwin-specific patch, but only time will tell. There are several ways to activate this option: 4a. For a single affected script, add this line just after the she-bang: (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed 4b. For a single script, invoke bash explicitly with the option, as in 'bash -o igncr ./myscript' rather than the simpler './myscript'. 4c. To affect all scripts, export the environment variable BASH_ENV, pointing to a file that sets the shell option as desired. Bash will source this file on startup for every script. 4d. Added in the bash-3.2-2 release: export the environment variable SHELLOPTS with igncr included in it. It is read-only from within bash, but you can set it before invoking bash; once in bash, it auto-tracks the current state of 'set -o igncr'. If exported, then all bash child processes inherit the same option settings; with the exception added in 3.2.9-11 that certain interactive options are not inherited in non-interactive use. 4e. bash-4.1.9-1 dropped support for 'shopt -s igncr'; it did not make sense to support the option through both set and shopt, and SHELLOPTS proved to be more powerful. 5. You can also experiment with the IFS variable for controlling how bash will treat \r during variable expansion. 6. There are varying levels of speed at which bash operates. The fastest is on a binary mount with igncr disabled (the default behavior). Next would be text mounts with igncr disabled and no \r in the underlying file. Next would be binary mounts with igncr enabled. And the slowest that bash will operate is on text mounts with igncr enabled. 7. As an additional cygwin extension, this version of bash includes completion_strip_exe - using 'shopt -s completion_strip_exe' makes completion strip .exe suffixes 8. This version of bash is immune to ShellShock (CVE-2014-6271 and friends) because it exports functions via 'BASH_FUNC_foo%%=' rather than 'foo=' environment variables. However, doing this has exposed weaknesses in some other utilities like 'ksh' or 'at' that fail to scrub their environment to exclude what is not a valid name for them. 9. If you don't like how bash behaves, then propose a patch, rather than proposing idle ideas. This turn of events has already been talked to death on the mailing lists by people with many ideas, but few patches. Thanks to Dan Colascione for providing the EXECIGNORE (now officially upstream) and completion_strip_exe patches. Remember, you must not have any bash or /bin/sh instances running when you upgrade the bash package. This release requires cygwin-2.6.0-1 or later. See also the upstream documentation in /usr/share/doc/bash/. DESCRIPTION: Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional improvements over sh for both programming and interactive use. In addition, most sh scripts can be run by Bash without modification. As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash, similar to some Linux distributions (although /bin/sh may swap to dash at some future time). UPDATE: === To update your installation, click on the "Install Cygwin now" link on the http://cygwi
Re: mingw64-x86_64-wxWidgets3.0 and mingw64-i686-wxWidgets3.0 needs repository rebuild.
Hello Yaakov & co. Are there plans to update these any time soon? I could fear that other mingw packages (at least the c++ ones) suffer the same problem currently. On another note, thanks Yaakov for maintaining so many mingw packes all together. I really appreciate it. I makes windows development in a sane environment so much easier. Thumbs up! Thanks, /pedro On Thu, 2016-12-08 at 18:39 +0100, p...@dontech.dk wrote: > Hello, > > First, thanks for including these libraries. Great! > > The current versions of the wxWidgets3.0 libs are not very useful. > > Both the static and dynamic versions simply do not work possibly > because > they are so old compared to the C++ compiler version for mingw32. > > Current ABI on g++: 1010. > > Current ABI used when libs where compiled: 1002. > > Currently any wxwidget app compiled just crashes at start. > > If i rebuild everything from source using cygport it works again > without > any modification. > > Can someone re-spin these packages so it works again? I think they > literally just need a re-build. > > Other wxWidget packages might have the same problem. > > Thanks, > > /pedro > > -- > 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: PHP 7.0.14 crashing with minimal set of extensions
On 2016-12-13 12:06, Andrey Repin wrote: Here's strace and stackdump from latest crash with Cygwin 2.6.1-2 project.rootdir.org/.offload/crash-php-7.14.tar.xz Are you 100% sure that your code is compatible with PHP 7? The only segfaults I have seen so far is with old code. -- Yaakov -- 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