Re: Cygwin convert environment paths

> That's what cygpath is there for, among other things. You expect people to use cygpath... from within PHP? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info:

Cygwin convert environment paths

I see here: That Cygwin does convert some environment variables, from Windows format to Unix format. For example HOME and TMP. But for me at least, are some important omissions. I use APPDATA and PROGRAMFILES a good amount, and those arent

Re: [ANNOUNCEMENT] Updated: binutils-2.34-2 (x86/x86_64)(Test)

> The following packages have been uploaded to the Cygwin distribution: > > * binutils-2.34 Why is binutils still 24 MB? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info:

Re: Request package updates for Poppler, Subversion and Git

> Will git contrib/subtree be in the next release? It's not in the latest > version 2.21.0-1. https://stackoverflow.com/questions/27109525/install-git-subtree-with-cygwin -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:

Re: Request for additional ming-w64 binaries

> the following packages are missing static libraries, i.e *.a files Cygwin has always been bad about this, and I dont see that changing. And if you post an issue to the repo, it just gets closed: best bet would be to look at

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

> The following packages have been uploaded to the Cygwin distribution: > > * binutils-2.34+1git.de9c1b7cfe > > This release should fix libtool shared library builds on 32bit Cygwin. Below are the current "non Base" dependencies (and transitive dependencies) of current "python3". As can be seen,

Cygwin 7z breaks symlinks

If you try to use p7zip to create an archive with symlink: 7z a -snl c.tar a.txt b.txt The symlink is broken: $ 7z l -slt c.tar [...] Path = b.txt Folder = - Size = 5 Packed Size = 512 Modified = 2020-03-15 10:34:04 Mode = -rwxrwxrwx User = Group =

Re: Re: [ANNOUNCEMENT] Updated: mingw64-{i686,x86_64}-gcc-9.2.0-2

> Please try: > chcp 65001 I had that set already... I dont think the other environments would have succeeded as I previously said if that wasnt already set. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:

Re: [ANNOUNCEMENT] Updated: mingw64-{i686,x86_64}-gcc-9.2.0-2

> The mingw-w64 cross compilers have been updated: > > * mingw64-i686-gcc-9.2.0-2 > * mingw64-x86_64-gcc-9.2.0-2 Regarding "g++.exe", using a file "a.cpp": #include int main() { std::cout << "☺☺" << std::endl; } With these items: - Mingw compiler - Provided by Cygwin -

Re: [ANNOUNCEMENT] Updated: gcc-9.2.0-2 (x86/x86_64)

On Mon, 24 Feb 2020 12:31:32 +, JonY wrote: > gcc-9.2.0-2 has been uploaded for Cygwin. This version is the same as > -1, just repackaged and marked as stable. Can you please update these as well: - mingw64-x86_64-gcc-core - mingw64-x86_64-gcc-g++ They are still sitting at 7.4.0, now two

Re: [ANNOUNCEMENT] Updated: gcc-9.2.0-1 (x86/x86_64) (Testing)

On Thu, 6 Feb 2020 08:16:12 +, JonY wrote: > I normally don't update mingw-w64 compilers unless the cygwin gcc has > stabilized. > > Do you need it ASAP? I can work on it soon if required. I mean isnt that the whole point of Test packages? The way I see it the Test package should always be

Re: [ANNOUNCEMENT] Updated: gcc-9.2.0-1 (x86/x86_64) (Testing)

On Wed, 8 Jan 2020 13:38:17 +, JonY wrote: > gcc-9.2.0-1 has been uploaded for Cygwin. This version is for testing. https://cygwin.com/ml/cygwin/2020-01/msg00077.html Any chance of an update for these? - mingw64-x86_64-gcc-core - mingw64-x86_64-gcc-g++ It appears they are both over a year

Re: Request package updates for Poppler, Subversion and Git

On Sun, 22 Dec 2019 18:50:34 +0100, Achim Gratz wrote: > Keep in mind you will then have to re-do it just after the new year for > the Perl update. Not necessarily. I know people have disagreed with this in the past, but I have looked at this again and it seems that not all distros require Perl

Re: Request package updates for Poppler, Subversion and Git

On Fri, 20 Dec 2019 17:20:26 +0100, Marco Atzeri wrote: > The other two are maintained by Yaakov, that seems at the moment > a bit busy with other activities. No, they arent: https://cygwin.com/packages/summary/git.html -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: [ANNOUNCEMENT] Updated: R-3.6.2-1

On Sun, 15 Dec 2019 18:11:12 +0100, Marco Atzeri wrote: Steven, the Debian core seems equal to my packaging https://packages.debian.org/buster/r-base-core that is not very promising. True, but Fedora is similar to what I am proposing: %package core Requires: libRmath%{?_isa} =

Re: [ANNOUNCEMENT] Updated: R-3.6.2-1

On Sat, 14 Dec 2019 19:42:08 +0100, Marco Atzeri wrote: Versions 3.6.2-1 of R libRmath libRmath-devel for cygwin are now available: Currently, including transitive dependency "R" pulls in 73 packages: 2,513,500 dejavu-fonts 73,920 desktop-file-utils 52,608 gamin

Re: non-persistent storage?

On Fri, 13 Dec 2019 17:57:23 -0500, Erik Soderquist wrote: I've test all of the suggestions I've seen so far with the exception of the cygserver and shared memory, and all of the ones I've tested failed the power failure scenario. /dev/clipboard? -- Problem reports:

Fwd: Errors in cURL dependency chain

Here is a dependency chain: 1. curl 2. libcurl4 3. libopenldap2_4_2 4. libsasl2_3 5. libopenssl100 I have two issues with this. First, "libopenssl100" is obsolete: @ libopenssl100 sdesc: "Obsoleted by libssl1.0" David, can this be resolved? Second, while looking at "libopenssl100" I

Re: Package search broken

On Tue, 19 Nov 2019 07:51:19 +0100, ASSI wrote: That was removed due to requiring excessive ressources on the server. If we can figure out a way to do that with less load it'll likely come back. Easy, just distribute package file lists instead, like MSYS2, Arch, Debian and... essentially every

Package search broken

$ cygcheck -p curl.h Found 0 matches for curl.h $ curl -G -d text=1 -d arch=x86_64 -d grep=curl.h \ https://cygwin.com/cgi-bin2/package-grep.cgi Found 0 matches for curl.h -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:

Cygwin fails to change executable bit in some cases

Setup: mkdir /cygdrive/c/sun cd /cygdrive/c/sun # create "mon.txt" using Windows "New", "Text Document" Running these commands under Windows 8 yields expected results: $ test -x mon.txt && echo x || echo not x x $ chmod -x mon.txt $ test -x mon.txt && echo x || echo not x

Re: Where is igawk and why doesn't @include replicate this feature?

On Wed, 11 Sep 2019 16:54:49, Troy Kenah wrote: I used to embed @include junk.awk statements to reduce repetitive code but this no longer works. These were files were not functions, simply code snippets; this is the type of error I am now seeing: gawk: get_FY2019Q1OIC.awk:28: @include

Re: RE: Command line processing in dcrt0.cc does not match Microsoft parsing rules

On Thu, 5 Sep 2019 23:45:44, "Stephen Provine via cygwin" wrote: package main import ( "log" "os" "os/exec" ) func main() { cmd :=3D exec.Command("C:\\cygwin64\\bin\\bash.exe", "test.sh", "foo", "ba= r\"baz", "bat") cmd.Stdout =3D os.Stdout

Re: change in pattern matching in pager /usr/bin/less

On Sun, 01 Sep 2019 17:50:17, L A Walsh wrote: part of this is that the new cygwin less appears to use Obsolete REs that don't support '+'. That may be a compile flag. I don't know why \s is not working, however, 'awk' used to be the definitive Extended (modern) RE reference and does use \s

Re: Bug report: Killing a native process may not actually kill it

On Wed, 28 Aug 2019 15:57:23, Quanah Gibson-Mount wrote: My original post contained a link to a patch allowing for Cygwin to correctly terminate native Windows processes. I understand it is not the position of the Cygwin project to deal with situation, so I think we can just let it drop. I

Re: [ANNOUNCEMENT] LLVM/Clang 8.0.1-1

On Tue, 27 Aug 2019 22:24:57, Yaakov Selkowitz wrote: The following packages have been uploaded to the Cygwin distribution: * clang-8.0.1-1 I noticed that Cygwin Clang requires GCC. why is that? Debian doesnt: https://packages.debian.org/buster/clang-7 -- Problem reports:

Python and file attributes

The Windows version of Python can access file attributes: >>> import os >>> os.stat('C:\Recovery').st_file_attributes 8214 https://docs.python.org/library/os#os.stat_result.st_file_attributes However the Cygwin version cannot: >>> import os >>>

Re: [ANNOUNCEMENT] curl 7.65.3-1

On Mon, 22 Jul 2019 23:20:42, Yaakov Selkowitz wrote: The following packages have been uploaded to the Cygwin distribution: * curl-7.65.3-1 * libcurl4-7.65.3-1 * libcurl-devel-7.65.3-1 * libcurl-doc-7.65.3-1 It seems the previously reported issue remains: $ curl -V curl 7.65.3

openldap

OpenLdap looks to be currently abandoned: https://cygwin.com/cygwin-pkg-maint This is an issue because it can (and currently is) used by Cygwin cURL build: https://github.com/cygwinports/curl/blob/2e953092/curl.cygport#L55 I think the best solution at this time is to simply remove OpenLdap

Re: cURL dependencies broken

On Sun, 21 Jul 2019 19:20:53, Achim Gratz wrote: Or maybe you should do that and lose the attitude? You are projecting. It was you who flatly refuted my position with no research at all. Just to keep the record straight, you've been originally asking about direct dependencies of curl, not

Re: cURL dependencies broken

On Sun, 21 Jul 2019 08:54:42, Achim Gratz wrote: No it doesn't. The "requires" line is only there for backwards compatibility and is a join of all versioned dependencies, which are listed in "depends2". Here is a culled cygcheck of cURL: $ cygcheck curl C:\cygwin64\bin\curl.exe

cURL dependencies broken

For some reason cURL 7.65.0-1 requires both of these: cygcrypto-1.1.dll cygcrypto-1.0.0.dll and confirmed by "setup.ini": requires: cygwin libcurl4 libmetalink3 libopenssl100 libssl1.1 zlib0 this raises several questions: Why are both required? Why is cURL requiring an old version

exec fails with native programs

If I am using the Cygwin package "python", for the purpose of demonstrating the problem I can write a script like this: #!/bin/sh exec python If I run this it will spawn an extra "sh.exe", but the extra shell will exit once Python has loaded. However if I use a native Python:

Re: Possible issue with gawk 5.0.1-1: Getting new warnings

On Thu, 11 Jul 2019 11:51:09, Vipul P wrote: Here is a sample script to invoke awk: $ cat ./gawk_error.sh #!/bin/sh echo "This:is:a:colon:separated:line:%%%:" | awk '{ gsub("\\%", "%25", $0); gsub("\\:", "%3A", $0); print }' As others said, your invocation is not idiomatic AWK.

Tcl interactive history

With Cygwin "tclsh", if you press the up arrow, instead of returning previous entry from the history, it just moves the cursor up. From that point the REPL is broken, and must be closed with Ctrl+C or similar. This is in contrast, from what I can tell, every other Tcl implementation: -

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

On Tue, 4 Jun 2019 22:04:16, Vince Rice wrote: It's cygport, he doesn't have to know about compiling C. He has to know about running a one-line cygport command. This just seems purposefully ignorant. How exactly is he suppose to modify the C source to address the problem and recompile, if he

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

On Tue, 4 Jun 2019 09:25:48, Brian Inglis wrote: I am encouraging and offering the poster a way to solve their problem, after providing some possible reasons for dropping support from some ECs. Rebuilding a Cygwin package from source using cygport is a relatively easy task. Easy compared to

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

On Mon, 3 Jun 2019 14:35:29, Brian Inglis wrote: You can easily rebuild the package yourself with the cygport utility, to check that works, then change the build config to include the Brainpool ECs, and rebuild the way you want it. Please do not presume someones technical prowess. It might be

Re: [ANNOUNCEMENT] Test: cmake-3.13.1-1

On Thu, 29 Nov 2018 07:58:53, Marco Atzeri wrote: Test version 3.13.3-1 of cmake cmake-doc cmake-gui emacs-cmake are available in the Cygwin distribution. Please test and report here any issue or problem. Also positive feedback in complex projects are appreciated CHANGES Last

Dash 0.5.10

I noticed a new Dash version is available since May 2018: http://gondor.apana.org.au/~herbert/dash/files Does the new version have some issue blocking Cygwin? If not can we publish new version? -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: [ANNOUNCEMENT] Test: Git v2.21.0-1

On Wed, 1 May 2019 22:08:25, Adam Dinwoodie wrote: After far more delay than I'd have liked, version 2.21.0-1 of Git has been uploaded and should be coming soon to a mirror near you. Because a lot of the delays in producing this version have been down to getting a stable and clean build, and

Re: Python extraneous dependencies

On Tue, 26 Mar 2019 14:58:12, Yaakov Selkowitz wrote: Nak. ctypes is part of the Python standard library and therefore the dependency needs to be on the main package(s). BTW, binutils is usually included by default in all but the most minimal base installs, so I'm not quite sure why you object

Re: python-pip-wheel package

On Sat, 20 Apr 2019 14:32:50, Steven Penny wrote: If you inspect the first one you find this file: /usr/share/python-wheels/pip-19.0.3-py2.py3-none-any.whl which appears to be a full "pip" installation. This raises some questions: 1. if "pip" is installed a

python-pip-wheel package

I noticed today that the "python27" and similar require among others these packages: - python-pip-wheel - python-setuptools-wheel If you inspect the first one you find this file: /usr/share/python-wheels/pip-19.0.3-py2.py3-none-any.whl which appears to be a full "pip" installation. This

Re: Cygwin Ruby and $LOAD_PATH

On Tue, 16 Apr 2019 09:35:48, Yaakov Selkowitz wrote: $ org-ruby -d alpha.org Exception `LoadError' at /usr/local/share/ruby/site_ruby/rubygems/core_ext/kernel_require.rb:54 - That doesn't look like it's from Cygwin's rubygems package.

Cygwin Ruby and $LOAD_PATH

Cygwin Ruby $LOAD_PATH is under "/usr": $ ruby -e 'puts $LOAD_PATH' | sort /usr/lib/ruby/2.3.0 /usr/lib/ruby/vendor_ruby/2.3.0 /usr/local/lib/ruby/site_ruby/2.3.0 /usr/local/share/ruby/site_ruby /usr/share/gems/gems/did_you_mean-1.0.2/lib /usr/share/ruby/2.3.0

Re: [ANNOUNCEMENT] nghttp2 1.37.0-1

On Fri, 29 Mar 2019 14:07:30, Yaakov Selkowitz wrote: The following packages have been uploaded to the Cygwin distribution: * nghttp2-1.37.0-1 * libnghttp2_14-1.37.0-1 * libnghttp2-devel-1.37.0-1 * python27-nghttp2-1.37.0-1 * python36-nghttp2-1.37.0-1 * python37-nghttp2-1.37.0-1 Do you plan

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

On Thu, 28 Mar 2019 22:33:48, Thomas Wolff wrote: It's a bit strange that you're telling my that *you* don't care about *my* information. I'm trying to raise some awareness about privacy on this occasion (which is quite a topic nowadays) and if you don't care, you don't need to comment. Yeah,

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

On Thu, 28 Mar 2019 08:34:34, Thomas Wolff wrote: Mintty can be used to run any command-line application directly (like top, your editor, ...), a shell is not needed. That may be true, the by default Mintty is configure to load Bash. So it is disingenuous so simply say that it does not require

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

On Wed, 27 Mar 2019 20:44:44, Brian Inglis wrote: Both dash and bash are in Base, installed by default, and both are login shells, while dash requires only cygwin1.dll to run, and can be used during setup, before other libraries or utilities are installed. Yeah, I did not mean to say login

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

On Wed, 27 Mar 2019 19:09:07, Yaakov Selkowitz wrote: "Only" if /bin/bash is your preferred shell. Granted, that's the default, and what most users would want anyway, but that is not strictly speaking a mintty dependency. As I mentioned in my response, the auto-detected dependency on bash is

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

On Wed, 27 Mar 2019 21:02:47, Thomas Wolff wrote: >>> mintty requires: bash cygwin I remember some discussion that the cygwin dependency, which most packages have, should not (or does not need to be) listed. And in fact, mintty does not depend on bash. Why does cygport think so? Uh, Mintty

Re: Python extraneous dependencies

On Tue, 26 Mar 2019 14:58:12, Yaakov Selkowitz wrote: Nak. ctypes is part of the Python standard library and therefore the dependency needs to be on the main package(s). BTW, binutils is usually included by default in all but the most minimal base installs, so I'm not quite sure why you object

Re: Python extraneous dependencies

On Tue, 26 Mar 2019 10:08:27, Yaakov Selkowitz wrote: >> It seems that function doesnt even work: >> >> $ python3.6 -q >> > > > from ctypes.util import find_library >> > > > print(find_library('z')) >> None > > WFM (returns cygz.dll), do you have the respective -devel packages > installed?

Re: Python extraneous dependencies

On Sun, 24 Feb 2019 17:42:36, Yaakov Selkowitz wrote: On Sat, 2019-02-23 at 16:29 -0800, Steven Penny wrote: I noticed that "python36" requires "binutils". This is needed for ctypes.util.find_library(). FWIW, on Linux, not only binutils is used, but also gcc.

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

On Sat, 16 Mar 2019 15:00:54, Achim Gratz wrote: Thomas Wolff writes: I have uploaded mintty 2.9.9 with the following changes: While you're at it, could you please stop using the release number "0" for your packages? That's supposed to be used for test packages only (if you want to make an

OpenSSL 1.1

Current Cygwin OpenSSL is 1.0.2r. However OpenSSL 1.1 has been available for several years now: https://github.com/openssl/openssl/releases/tag/OpenSSL_1_1_0 and certain libraries require OpenSSL 1.1: https://github.com/curl/curl-for-win -- Problem reports:

Re: Cygwin-3 and the Bleeding Edge

On Mon, 04 Mar 2019 06:05:52, "KARL BOTTS" wrote: But now and then I need to upgrade a specific package outside of my full cygwin update cycle. E.g., right now I would like to upgrade just git. So: Assume for the moment that the latest git package release on the mirrors, has been built

Re: Cygwin 3.0.1-1 Breaks ALL cygwin applications on Windows 7 x64

On Tue, 26 Feb 2019 19:21:15, "Jerry Baker via cygwin" wrote: Well I guess it's a good thing there's only one possible state of Windows 7 x64 which allows us to determine that there's no possibility of a bug simply by running a single instance in one VM. We're going to turn the world of unit

Re: Cygwin 3.0.1-1 Breaks ALL cygwin applications on Windows 7 x64

On Tue, 26 Feb 2019 18:55:56, "Jerry Baker via cygwin" wrote: Not really. I don't work for free, especially for hostile people with over inflated egos and crippling social disorders. https://yourlogicalfallacyis.com/ad-hominem The onus is on whoever is interested in having cygwin work in this

Re: Cygwin 3.0.1-1 Breaks ALL cygwin applications on Windows 7 x64

On Tue, 26 Feb 2019 17:50:10, "Jerry Baker via cygwin" wrote: Glad to. Please let me know what evidence will suffice to prove that. pretty simple 1. get the Windows 7 x64 from here https://softlay.net/operating-system/windows-7-download.html 2. get virtualbox from here https://virtualbox.org

Re: Cygwin 3.0.1-1 Breaks ALL cygwin applications on Windows 7 x64

On Tue, 26 Feb 2019 15:00:03, "Jerry Baker via cygwin" wrote: It's just cygwin1.dll for sure. I can replace that with 2.x version and everything works fine. I don't recognize most of the BLODAs and not running any of them that I know of. Are there any software packages known to interfere with

Re: Python extraneous dependencies

On Sun, 24 Feb 2019 17:42:36, Yaakov Selkowitz wrote: On Sat, 2019-02-23 at 16:29 -0800, Steven Penny wrote: I noticed that "python36" requires "binutils". This is needed for ctypes.util.find_library(). FWIW, on Linux, not only binutils is used, but also gcc.

Python extraneous dependencies

I noticed that "python36" requires "binutils". Further, I noticed this dependency chain: python36 > libuuid-devel > pkg-config > libglib2.0_0 "binutils" is 5,863,216 bytes and "libglib" is 3,044,044 bytes. I am of the opinion we should not be including large dependencies like these unless

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.1

On Tue, 29 Jan 2019 20:59:59, Corinna Vinschen wrote: Hi folks, I uploaded a new Cygwin test release 3.0.0-0.1 This release comes with a couple of new features and some interesting bug fixes. something big broke here. as someone else reported here:

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.1

On Tue, 29 Jan 2019 20:59:59, Corinna Vinschen wrote: - New file ioctls's FS_IOC_GETFLAGS and FS_IOC_SETFLAGS. The actual inode flags are Cygwin-specific. This allows to set or reset DOS attributes, file sparseness, FS level encryption and compression, as well as directory case

Re: [ANNOUNCEMENT] Updated: Perl distributions

On Mon, 21 Jan 2019 22:01:46, Achim Gratz wrote: The following Perl distributions have been updated to their latest version on CPAN, respectively: Sorry if this is off topic, but would you consider updating the Perl package itself? I noticed today that Cygwin Perl package is still using

Re: Bash heredoc on FD 3

On Tue, 8 Jan 2019 22:05:34, Corinna Vinschen wrote: I added some changes to make this work in older systems as well. I uploaded new snapshots to //cygwin.com/snapshots/ Please try. Confirmed fixed. Note I only retested with Windows 7 this time, but I think we’re good. Thank you! --

Re: Bash heredoc on FD 3

On Mon, 7 Jan 2019 20:03:13, Corinna Vinschen wrote: I can't reproduce this with my latest code. It works fine for me every time, independently of POSIXLY_CORRECT. I uploaded new snapshots to https://cygwin.com/snapshots/ with all the latest changes. Please try again. I retested with

Re: Bash heredoc on FD 3

On Sun, 6 Jan 2019 21:18:52, Corinna Vinschen wrote: This should work in the latest developer snapshot uploaded to https://cygwin.com/snapshots/ Please give it a try. Hm interesting: $ uname -a CYGWIN_NT-6.1 Steven-PC 2.12.0s(0.330/5/3) 2019-01-06 19:42 x86_64 Cygwin $ dash

Re: [ANNOUNCEMENT] [Updated] mingw64-{i686,x86_64}-gcc-7.4.0-1

On Mon, 31 Dec 2018 00:20:28, Yaakov Selkowitz wrote: Have you considered that perhaps the issue is with MSYS2 (incomplete libstdc++ debuginfo)? yes, I have; and no, its not: https://cygwin.com/ml/cygwin/2018-08/msg00330.html -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: [ANNOUNCEMENT] [Updated] mingw64-{i686,x86_64}-gcc-7.4.0-1

On Sun, 30 Dec 2018 02:36:15, JonY wrote: The mingw-w64 cross compilers have been updated: * mingw64-i686-gcc-7.4.0-1 * mingw64-x86_64-gcc-7.4.0-1 Note the problem i detailed in august has not been resolved: https://cygwin.com/ml/cygwin/2018-08/msg00275.html -- Problem reports:

"test" producing unexpected results after "chmod"

With Linux, these commands produce expected results: $ cd /tmp $ touch alpha.txt $ test -r alpha.txt; echo "$?" 0 $ chmod -r alpha.txt $ test -r alpha.txt; echo "$?" 1 $ chmod +r alpha.txt $ test -r alpha.txt; echo "$?" 0 However with Cygwin, unexpected results are

Exclude System entries with "ls" or "find"

Compare Cygwin: $ ls -1 -N /cygdrive/c $Recycle.Bin cygwin64 Documents and Settings pagefile.sys PerfLogs Program Files Program Files (x86) ProgramData Recovery System Volume Information Users Windows With Command Prompt: > dir /A:-S C: 2018-12-08

Re: grep 3.0-2 not stripping CRs on Windows

On Mon, 17 Dec 2018 13:22:48, Ondřej Surý wrote: # No amount of options makes the grep find the text in the file $ ./grep-3.0-2.exe 'foo$’ crlf.txt $ ./grep-3.0-2.exe -U 'foo$' crlf.txt $ ./grep-3.0-2.exe -a 'foo$’ crlf.txt Your commands are failing because you are not accounding for the

Bash heredoc on FD 3

Using this file: $ cat hello.sh awk -f /dev/fd/3 3

Re: Cygwin Git with Windows paths

On Mon, 26 Nov 2018 22:54:14, Adam Dinwoodie wrote: Personally, I don't see this as a bug; AIUI using Windows style paths isn't something that is supported in general in Cygwin, even if it's something that works in some circumstances. It is a bug. Even when you use Unix paths, Cygwin is doing

Cygwin Git with Windows paths

Cygwin Git can clone with Unix form paths: $ git clone git://github.com/benhoyt/goawk /tmp/goawk Cloning into '/tmp/goawk'... remote: Enumerating objects: 330, done. However it fails with Windows form: $ git clone git://github.com/benhoyt/goawk 'C:\cygwin64\tmp\goawk' Cloning

Re: [ANNOUNCEMENT] Updated: zstd-1.3.7-1 and development headers / libraries

On Sun, 11 Nov 2018 12:25:15, Achim Gratz wrote: This release updates Zstandard to the latest upstream version. Note The built-in benchmark function can infloop on too short input with some settings, apparently due to the granularity of timing measurements on Windows being too coarse.

Re: Bug report: Core dump with too many args

On Wed, 7 Nov 2018 13:37:53, Ole Tange wrote: I get core dump when running: $ /bin/echo `seq 100` Segmentation fault (core dumped) This also looks bad: $ /bin/wc `seq 100` 2 [main] -bash 15396 C:\cygwin\bin\bash.exe: *** fatal error - cmallo= c would have returned NULL Hangup

Mintty fails to render 3 byte UTF-8 on Windows 7

tested with Windows 7 and Windows 8.1. Test A -- install: usr/share/fonts/noto/NotoSansMyanmar-Regular.ttf from: noto-myanmar-fonts Link font (need relog after): set 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink' reg add "$1" /t REG_MULTI_SZ /v Consolas /d

Re: Cygwin fails to utilize Unicode replacement character

On Mon, 03 Sep 2018 15:15:26, Steven Penny wrote: Expanding on the "Notepad" example, "Notepad" default font is "Lucida Console", which doesnt have U+FFFD either. However pasting into "Notepad" will still show U+FFFD properly because "Tahoma" h

Re: Cygwin fails to utilize Unicode replacement character

On Wed, 5 Sep 2018 22:14:59, Corinna Vinschen wrote: OTOH, in my testing this only occurs for DejaVu Sans Mono. I installed Liberation Mono and Noto Mono as well and the above problem never occurs with them. Weird. I'm about to let this slip as a font bug. as you prob know ive been testing

Re: Cygwin fails to utilize Unicode replacement character

On Wed, 5 Sep 2018 09:55:28, Corinna Vinschen wrote: I added DejaVu Sans Mono per the above and to my surprise I see this: $ cat alfa.txt =EF=BF=BD So it looks like Deja Vu has a 0xfffd char. However, GetGlyphIndicesW claims otherwise: a character that DejaVu Sans Mono actually doesnt

Tab completion adding spurious escape characters

If you create this file: touch -- \''-#%.!$&(),;@[]^`{}=_~+9zZ' Then enter "touch", "Tab", "Tab", you get this: touch \'-#%.\!\$\&\(\)\,\;\@\[\]\^\`\{\}\=_~+9zZ So the shell is saying that these characters need to be escaped: ' ! $ & ( ) , ; @ [ ] ^ ` { } = but they dont, not all

Re: Cygwin fails to utilize Unicode replacement character

On Tue, 4 Sep 2018 23:43:16, Thomas Wolff wrote: Traditionally, many terminals used to display the DEL character as a checkered block, which is more or less the MEDIUM SHADE. This makes the glyph appear somewhat "erroneous" by convention. I see - now that Unicode has some dedicated characters

Re: Cygwin fails to utilize Unicode replacement character

On Tue, 4 Sep 2018 13:59:10, Doug Henderson wrote: My preference is to remove the output fiddling code that Corrina has been working on. It is trying to solve the wrong problem. I think we have gone down a rabbit hole at the wrong end of cat's data flow. this has nothing to do with "cat". it

Re: Cygwin fails to utilize Unicode replacement character

On Tue, 4 Sep 2018 20:41:48, Thomas Wolff wrote: No idea what you consider dangerous. Anyway, we obviously agree that hardly any available console font supports the REPLACEMENT CHARACTER. You had previously suggested code that might work (using CreateFont(0, 0, )). Maybe you can sort out

Re: Cygwin fails to utilize Unicode replacement character

On Tue, 4 Sep 2018 16:18:21, Thomas Wolff wrote: My vote is against the patch because the nodef glyph will often be just blank space which is certainly worse than ▒. If conhost does not provide a reasonable way to enquire 0xFFFD availability it's conhost's fault, not cygwin's so why should

Re: Cygwin fails to utilize Unicode replacement character

On Tue, 4 Sep 2018 11:00:00, Corinna Vinschen wrote: Whereever you get DejaVu Sans Mono from. Cygwin provides it via the "dejavu-fonts" package, or you can get it here: http://dejavu-fonts.github.io My W10 console only allows to specify a handful of fonts, Consolas, Courier New, Lucida, MS

Re: Cygwin fails to utilize Unicode replacement character

On Mon, 3 Sep 2018 23:02:58, Corinna Vinschen wrote: I can't. I only have a limited set of fonts available in the console. http://superuser.com/questions/390933/add-font-cmd-window-choices/956818 What I just did was calling the GetFontUnicodeRanges function for each font, and it turns out

Re: Cygwin fails to utilize Unicode replacement character

On Sun, 2 Sep 2018 10:07:10, Thomas Wolff wrote: Actually, the width problem I suggested in my other response (and even referring to the wrong character) does not apply as mintty enforces proper width in that case. Also, even with fonts that do not provide the glyph, you will usually still see

Re: Cygwin fails to utilize Unicode replacement character

On Sat, 1 Sep 2018 15:50:04, Doug Henderson wrote: This is an issue with rendering the character in the terminal window. In both the CMD/Conhost/bash and Mintty/bash terminals, I have configure the font to be Lucinda Console. This font does not have a glyph for U+FFFD: Replacement Character. (To

Re: Cygwin fails to utilize Unicode replacement character

On Sat, 1 Sep 2018 20:11:15, Thomas Wolff wrote: Which terminals are used and what's the output of `locale` and `cat --version` in both cases? Linux: $ echo "$TERM" xterm-256color $ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8"

Cygwin fails to utilize Unicode replacement character

Using this file: $ printf '\353\n' > alfa.txt $ iconv -f CP1252 alfa.txt ë You get this result with Linux: $ cat alfa.txt � Where "cat" properly outputs Unicode 'REPLACEMENT CHARACTER' (U+FFFD). However with Cygwin you get this: $ cat alfa.txt ▒ Where "cat" outputs

Re: error in "cygpath" behavior

On Fri, 31 Aug 2018 10:57:34, Corinna Vinschen wrote: Long-standing behaviour. ".." in Cygwin and ".." in Windows can totally disagree. The path is always convert to absolute at this point in favor of correct output. There's also the additional restriction (though not in this case) that

error in "cygpath" behavior

It is my understanding that given relative input, "cygpath" shall produce relative output unless given "-a" option. However I noticed a discrepancy. These are all correct: $ cygpath . . $ cygpath .. .. $ cygpath -w . . This is not: $ cygpath -w .. C:\cygwin64\home\

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.11.0-0.4

On Mon, 27 Aug 2018 21:20:36, Marco Atzeri wrote: I uploaded a new Cygwin test release 2.11.0-0.4 It seems is not yet up. May be calm need a kick ? not all mirrors have updated yet - heres a good one: http://mirror.koddos.net/cygwin/x86_64/release/cygwin -- Problem reports:

Re: [ANNOUNCEMENT] [Updated] mingw64-{i686,x86_64}-gcc-7.3.0-1 (Test)

On Sun, 26 Aug 2018 12:51:40, JonY wrote: Can you roll back to the previous x86_64-w64-binutils and find out if it makes a difference? Other than that, I'm quite out of ideas. Using this file: $ cat stoi.cpp #include #include main() { std::cout << std::stoi("3.14159") <<

Re: [ANNOUNCEMENT] [Updated] mingw64-{i686,x86_64}-gcc-7.3.0-1 (Test)

On Sun, 26 Aug 2018 15:07:06, =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= wrote: Am 25.08.2018 um 02:13 schrieb Steven Penny: On Fri, 24 Aug 2018 10:11:42, JonY wrote:    $ wc -c /lib/gcc/x86_64-w64-mingw32/7.3.0/libstdc++.a    22446354 /lib/gcc/x86_64-w64-mingw32/7.3.0/libstdc++.a    $ wc -c

  1   2   3   4   5   6   >