Re: Cygwin convert environment paths

[Steven Penny via Cygwin]

> 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: https://cygwin.com/ml/#unsubscribe-simple

Cygwin convert environment paths

[Steven Penny via Cygwin]

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 converted. To make
it worse, HOMEDRIVE and SYSTEMDRIVE arent converted either, meaning you cant
manually construct the path starting with a variable. This causes some
problems. Take this example:

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

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

[Steven Penny via Cygwin]

> 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: https://cygwin.com/ml/#unsubscribe-simple

Re: Request package updates for Poppler, Subversion and Git

[Steven Penny via Cygwin]

> 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:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Request for additional ming-w64 binaries

[Steven Penny via Cygwin]

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






or build your own. Good luck.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

[Steven Penny via Cygwin]

> 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, "binutils" is now larger than all the other
dependencies combined.

Can we please, please address whatever exploded "binutils" size? Or perhaps once
and for all remove "binutils" as a dependency for "python3"? "binutils" is not
a runtime requirement for Python, only in the case where someone is utilizing
"ctypes", which one could argue is not a large enough percentage of users to
justify this.

25,016,180 binutils
 4,132 libcom_err2
92,524 libcrypt2
55,100 libexpat1
 3,964 libgdbm_compat4
21,896 libgdbm6
   102,828 libgssapi_krb5_2
73,344 libk5crypto3
   236,076 libkrb5_3
14,424 libkrb5support0
40,052 libnsl2
19,432 libpkgconf3
   470,540 libsqlite3_0
68,708 libtirpc3
 7,004 libtirpc-common
16,848 libuuid-devel
25,124 pkgconf
 5,972 pkg-config
   316 python3
 5,750,152 python36
 1,269,060 python-pip-wheel
   467,804 python-setuptools-wheel
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Cygwin 7z breaks symlinks

[Steven Penny via Cygwin]

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 =
Symbolic Link =
Hard Link =

but if you use this version:



Then it works as expected:

$ 7z l -slt c.tar
[...]
Path = b.txt
Folder = -
Size = 5
Packed Size = 0
Modified = 2020-03-15 10:48:07
Mode = lrwxrwxrwx
User =
Group =
Symbolic Link = a.txt
Hard Link =

Note that I purposefully used an old version from the offical site, to match
the current Cygwin version.
--
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: Re: [ANNOUNCEMENT] Updated: mingw64-{i686,x86_64}-gcc-9.2.0-2

[Steven Penny]

> 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: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Steven Penny]

> 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
- cmd.exe

Produces this output:

���☺

Note that changing any one of those items fixes the issue. For example:

- Use Cygwin compiler instead of Mingw compiler
- Use https://github.com/mstorsjo/llvm-mingw instead of Cygwin
- Use Mintty instead of "cmd.exe"

I think something is up. If the LLVM project can produce expected results with
"cmd.exe", Cygwin should be able to as well.
"--Problem reports:   http://cygwin.com/problems.htmlFAQ:   
http://cygwin.com/faq/Documentation: 
http://cygwin.com/docs.htmlUnsubscribe info:  
http://cygwin.com/ml/#unsubscribe-simple;

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

[Steven Penny]

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 major version behind.

If someone writes a new C project for Windows, they might prefer to release
a Cygwin and Mingw version, but given the current situation thats not possible.


--
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] Updated: gcc-9.2.0-1 (x86/x86_64) (Testing)

[Steven Penny]

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 matching the major version, and ideally the minor
version.

For even the test version to be literally 2 majors versions back kills any
reason to even have it. It would be better to just remove the test version
altogether and just have current and "prev" if it cant be kept up to date.
On a personal note the optics just look bad. GCC points people to Cygwin:

https://gcc.gnu.org/install/binaries.html

then when the users get here, they find the mingw64-x86_64-gcc-core 7.3 which
is 2 years old:

https://gcc.gnu.org/releases.html


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

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

[Steven Penny]

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 old, which is quite some time for a
compiler. I have some workarounds here in the meantime:

- http://repo.msys2.org/mingw/x86_64
- https://github.com/mstorsjo/llvm-mingw
- https://musl.cc


--
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: Request package updates for Poppler, Subversion and Git

[Steven Penny]

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 with a Git
install. For example Fedora "git-core" only requires:

Requires:   less
Requires:   openssh-clients
Requires:   zlib >= 1.2

https://apps.fedoraproject.org/packages/git/sources/spec

Some notable scripts would not work, like "git add --interactive", but Cygwin
could have a "git" and "git-core" to deal with that. Personally I have installed
Git without Perl for some years without issue.


--
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: Request package updates for Poppler, Subversion and Git

[Steven Penny]

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:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Steven Penny]

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} = %{version}-%{release}
   Requires: openblas-Rblas
   Requires: perl
   Requires: perl-interpreter
   Requires: redhat-rpm-config
   Requires: sed, gawk, tex(latex), less, make, unzip
   Requires: tex(dvips), vi
   Requires: vim-minimal
   Requires: xdg-utils, cups

   %package core-devel
   Requires: bzip2-devel, libX11-devel, zlib-devel
   Requires: gcc-c++, gcc-gfortran, tex(latex), texinfo-tex
   Requires: libicu-devel
   Requires: pcre2-devel
   Requires: pcre-devel
   Requires: qpdf
   Requires: R-core = %{version}-%{release}
   Requires: tcl-devel, tk-devel, pkgconfig, xz-devel
   Requires: tex(cm-super-ts1.enc)
   Requires: tex(ecrm1000.tfm)
   Requires: tex(inconsolata.sty)
   Requires: tex(pcrr8t.tfm)
   Requires: tex(phvr8t.tfm)
   Requires: tex(ptmb8t.tfm)
   Requires: tex(ptmr8t.tfm)
   Requires: tex(ptmri8t.tfm)
   Requires: tex(ptmro8t.tfm)
   Requires: tre-devel

https://apps.fedoraproject.org/packages/R/sources/spec


--
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] Updated: R-3.6.2-1

[Steven Penny]

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
  502,752 gsettings-desktop-schemas
   54,360 libbrotlicommon1
   18,272 libbrotlidec1
  659,160 libcairo2
4,132 libcom_err2
   20,804 libcrypt0
  233,752 libcurl4
9,648 libdatrie1
  883,388 libdb5.3
   55,100 libexpat1
   11,592 libfam0
  105,768 libfontconfig1
  212,692 libfontconfig-common
  398,000 libfreetype6
  404,012 libgfortran4
3,044,044 libglib2.0_0
   59,080 libgomp1
   76,288 libgraphite2_3
  102,828 libgssapi_krb5_2
  351,240 libharfbuzz0
  114,012 libICE6
8,151,228 libicu65
   50,980 libidn2_0
   23,200 libjbig2
  102,812 libjpeg8
   73,344 libk5crypto3
  236,076 libkrb5_3
   14,424 libkrb5support0
2,108,364 liblapack0
   38,024 liblzo2_2
   52,312 libnghttp2_14
1,073,760 libopenblas
  149,684 libopenldap2_4_2
  108 libopenssl100
  213,668 libpango1.0_0
  221,460 libpixman1_0
   19,432 libpkgconf3
  171,416 libpng16
   50,452 libpsl5
  133,328 libquadmath0
  131,228 libsasl2_3
   83,924 libSM6
  157,744 libssh4
   15,608 libssh-common
  174,636 libthai0
  138,344 libtiff6
   68,708 libtirpc3
7,004 libtirpc-common
  385,472 libunistring2
  773,720 libX11_6
   19,104 libXau6
  109,596 libxcb1
9,260 libxcb-render0
3,060 libxcb-shm0
   48,368 libXdmcp6
   83,568 libXext6
   44,768 libXft2
  700,436 libxml2
   88,912 libXmu6
   26,520 libXrender1
   13,540 libXss1
  479,252 libXt6
   25,124 pkgconf
5,972 pkg-config
   38,224 publicsuffix-list-dafsa
   43,025,128 R
  220 R_autorebase
  303,688 shared-mime-info
1,503,048 tcl
1,407,028 tcl-tk


From my testing only these are needed for a minimal program:


- libgomp1
- libicu65
- liblapack0
- libopenblas
- libtirpc3
- R

Could we release an "R_base" similar to "perl_base"? I have no need for "X".


--
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: non-persistent storage?

[Steven Penny]

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:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Fwd: Errors in cURL dependency chain

[Steven Penny]

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 noticed
another issue:

@ libopenssl100
requires: libssl1.0
depends2:

My understanding is that "depends2" is the proper dependency endpoint, and that
"requires" is only kept for legacy parsers. Yaakov, can you advise?

--
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: Package search broken

[Steven Penny]

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 other distribution out there?


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

Package search broken

[Steven Penny]

$ 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: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Cygwin fails to change executable bit in some cases

[Steven Penny]

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

However running the same commands under Windows 7 yields unexpected results:

   $ test -x mon.txt && echo x || echo not x
   x

   $ chmod -x mon.txt
   $ test -x mon.txt && echo x || echo not x
   x


--
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: Where is igawk and why doesn't @include replicate this feature?

[Steven Penny]

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 "../inc/segments.awk"
gawk: get_FY2019Q1OIC.awk:28:  ^ syntax error
gawk: get_FY2019Q1OIC.awk:36: fromdate=mktime("2019 09 01 00 00 00")
gawk: get_FY2019Q1OIC.awk:36: ^ syntax error
gawk: get_FY2019Q1OIC.awk:36: fromdate=mktime("2019 09 01 00 00 00")
gawk: get_FY2019Q1OIC.awk:36:
 ^ 0 is invalid as number of arguments for mktime


Works fine here:

   $ gawk --version
   GNU Awk 5.0.1, API: 2.0 (GNU MPFR 4.0.2, GNU MP 6.1.2)

   $ cat one.awk
   function f1(n1) {
  return n1 + 10
   }

   $ cat two.awk
   @include "one.awk"
   BEGIN {
  print f1(20)
   }

   $ unset POSIXLY_CORRECT
   $ gawk -f two.awk
   30

Finally, I would make a suggestion. "@include" is not POSIX, so if you find
yourself relying on something like this more and more, it might be better to
switch to a proper programming language. Something like Perl, Lua or Tcl.


--
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: RE: Command line processing in dcrt0.cc does not match Microsoft parsing rules

[Steven Penny]

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
cmd.Stderr =3D os.Stderr
if err :=3D cmd.Run(); err !=3D nil {
log.Fatal(err)
}
}


Why are you doing this? I hate to be that guy, but examples are important.
Arguably the most important lesson I have learned with computer programming is:
use the right tool for the job.

So when I need to do something, I start with a shell script. Then once a shell
script doesnt cut it anymore, I move to AWK, then Python, the Go. Substitute
your language of choice.

What I dont do is call a shell script from Go or anything else. I might call
"git.exe" or "ffmpeg.exe", but even then you could argue against it as those
binaries have libraries too.

I agree that Cygwin should be parsing to and from cmd.exe correctly. But unless
you have a valid use case, its kind of like "Cygwin theory". I have found that
historically those type issues are less likely to be resolved in timely manner,
if at all.


--
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: change in pattern matching in pager /usr/bin/less

[Steven Penny]

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 for whitespace.

My  linux less is at version 458 (POSIX RegEx)
my cygwin less is at version 530 (POSIX RegEX)


I have same version as you:

   $ less --version
   less 530 (POSIX regular expressions)

"+" is defined with PCRE, but also under ERE, which is what is used by "awk" and
"grep -E". Its only BRE that doesnt define "+". Not sure why this isnt working
for you but my less uses ERE. Another syntax under ERE is "{1,}", but that wont
help you if your ERE is missing.

In regard to "\s", thats not defined by BRE or ERE, so you would need PCRE for
that. Workaround is to use "[[:blank:]]", "[[:space]]", or simply use the space
character. I havent seen many man pages using tabs. For example doing "man man"
and searching for "[[:cntrl:]]" returns nothing.


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

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

[Steven Penny]

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 would like to say that I support this, if it can be done in a reasonable way.

Ive been reading this thread carefully, and Ive yet to see anyone comment on the
merits of the patch. Apologies if Ive overlooked it.

To me, the first and only question that matters is "does it solve more problems
than it causes". If the answer is yes, I think the patch should be accepted.
Else I think its unfair to prematurely end the discussion.

Cygwin has a long history of... putting Cygwin first. I dont mean this as a
negative, although I do disagree with the sentiment. Any compiling is with
Cygwin target as first class citizen, then native Windows has always been an
afterthought. I think this is why the MinGW survived as long as it did, and
while the MSYS2 project enjoys the popularity it has today. With MSYS2, the
"Cygwin" mode is still primary, but you can launch "mingw64.exe" and native
Windows becomes the default.

If Cygwin wishes to remain insular in regard to this and other native Windows
issues, thats their choice. It does make development significantly easier I
assume. However I think in doing so it alienates significant portion of the
userbase.


--
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/Clang 8.0.1-1

[Steven Penny]

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:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Python and file attributes

[Steven Penny]

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
   >>> os.stat('C:\Recovery').st_file_attributes
   Traceback (most recent call last):
   File "", line 1, in 
   AttributeError: 'os.stat_result' object has no attribute
   'st_file_attributes'

This is unexpected as other Cygwin tools can access this information:

   $ lsattr
   -hs--n-- ./Recovery


--
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] curl 7.65.3-1

[Steven Penny]

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 (x86_64-pc-cygwin) libcurl/7.65.3

   $ cygcheck curl
   C:\cygwin64\bin\curl.exe
 C:\cygwin64\bin\cygcurl-4.dll
   C:\cygwin64\bin\cygcrypto-1.1.dll
   C:\cygwin64\bin\cygldap-2-4-2.dll
 C:\cygwin64\bin\cygcrypto-1.0.0.dll
 C:\cygwin64\bin\cygssl-1.0.0.dll
   C:\cygwin64\bin\cygssl-1.1.dll


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

openldap

[Steven Penny]

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 from cURL
builds until this is resolved. Failing that, I can volunteer to take up
maintenance of OpenLdap if it really need to be kept along. However I am not
sure this is the case, as my understand is OpenLdap is only used in these type
cases:

   curl ldaps://ldap.foo.com

https://stackoverflow.com/questions/44546116

and wouldnt change anything with regard to standard HTTP/HTTPS/FTP etc
protocols. Personally I have never used OpenLdap so I could care less if its
removed. But again I can respect if we have a significant amount of users that
need it.


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

Re: cURL dependencies broken

[Steven Penny]

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 transitory ones; so no, I didn't look
at those.


I never said children only, I think you assumed that. A grandchild is still a
dependency. Perhaps if I had said "direct dependencies" as you did, then it
would be fair to make that assumption.


What has been obsoleted is actually libopenssl100; and it was
replaced by compatibility shims in libssl-1.0 for libraries and
applications that did not yet make the jump to the new API.


Right, so even in that case why is OpenLdap using "libopenssl100" instead of
"libssl1.0"?


It would all have been fairly obvious if you had looked at the announcement
mails and the actual library names.


Please do not assume what mails I do and do not look at.


Your cygcheck output shows that this obsoletion has worked just the way it was
supposed to.


In the general case yes, this is an elegant solution. However we are not in
the general case, we are talking about a security sensitive package. I think
it would be reasonable to expect that the cascading dependencies should be
updated in tandem in this case. Else you are left with "weakest link" syndrome,
where the end user is getting none of security fixes in regard to cURL with
OpenLdap, or worse they assume they are. It looks like OpenLdap has been able to
use OpenSSL 1.1 for over 2 years now:

- http://openldap.org/lists/openldap-bugs/201704/msg00053.html
- ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release

but maybe it has not been changed because the package is abandoned:

https://cygwin.com/cygwin-pkg-maint

Can we pull OpenLdap out of cURL until this is resolved? Else I can voluteer to
pick up maintenance.


--
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: cURL dependencies broken

[Steven Penny]

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
 C:\cygwin64\bin\cygcurl-4.dll
   C:\cygwin64\bin\cygcrypto-1.1.dll
   C:\cygwin64\bin\cygldap-2-4-2.dll
 C:\cygwin64\bin\cygcrypto-1.0.0.dll
 C:\cygwin64\bin\cygssl-1.0.0.dll
   C:\cygwin64\bin\cygssl-1.1.dll

So LibCurl itself is requiring the new version, but LibLdap is requiring old
version. Further, we can prove this with "setup.ini" as well. Look at culled
listing of LibCurl:

   @ libcurl4
   requires: ca-certificates cygwin libbrotlidec1 libopenldap2_4_2
   depends2: ca-certificates, cygwin, libbrotlidec1, libopenldap2_4_2

No matter which on we look at "libopenldap2_4_2" is required. Now, let go one
more step:

   @ libopenldap2_4_2
   requires: cygwin libopenssl100 libsasl2_3
   depends2: cygwin, libopenssl100, libsasl2_3

No matter which one we look at, the twice obsolete SSL is being used. Achim, in
the future, I think it would be helpful for you to check your facts before
posting.


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

cURL dependencies broken

[Steven Penny]

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 of OpenSSL? Isn’t that a security risk?

Why is the "requires" line being used? I thought the "depends2" was superseding
it.

Even if "requires" is still valid, why is "libopenssl100" being required by
anything? "setup.ini" says that it is obsolete, twice over:

   @ libopenssl100
   sdesc: "Obsoleted by libssl1.0"


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

exec fails with native programs

[Steven Penny]

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:

https://python.org/ftp/python/3.7.4/python-3.7.4-embed-amd64.zip

the same script will spawn an extra "sh.exe", but the extra shell will not exit
until Python has exited.


--
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: Possible issue with gawk 5.0.1-1: Getting new warnings

[Steven Penny]

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. Anywhere that regular
expressions are expected, like the first argument to "gsub", regular expressions
should be used. If you use a string, you need an extra level of escaping, as
the AWK lexer will parse the string twice:


If the right-hand operand is any expression other than the lexical token
**ERE**, the string value of the expression shall be interpreted as an
extended regular expression, including the escape conventions described
above. Note that these same escape conventions shall also be applied in
determining the value of a string literal (the lexical token **STRING**),
and thus shall be applied a second time when a string literal is used in
this context.


http://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html#tag_20_06_13_04


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

Tcl interactive history

[Steven Penny]

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:

- https://activestate.com/products/activetcl
- https://bitbucket.org/tombert/tcltk
- https://github.com/msteveb/jimtcl
- https://irontcl.com
- https://magicsplat.com/tcl-installer

I know that JimTcl is using LineNoise:

https://github.com/antirez/linenoise

I am not sure if the others are using ReadLine or what. Can this be corrected
for the Cygwin version? As for me anyway it makes it unusable.


--
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: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Steven Penny]

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 doesnt know anything about
compiling C?


You offered the user nothing, and berated Brian for offering help. The only
nonsense on offer here is from you. And the only one off-putting in this
conversation is you.


Oh really? Is that why OP agreed with me?:


Anyway, Steven you are right compiling a package like OpenSSL is not
straightforward even with Cygport but still feasable with reasonnable efforts
(I guess because I'm used to have unsual setup where automatic tool does not
work out of the box :) )


https://cygwin.com/ml/cygwin/2019-06/msg00026.html

Read the thread dude and stop trolling.


--
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: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Steven Penny]

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 what, assembly? I am comfortable with 3 programming languages,
and learning 4 others, and compiling C is not "relatively easy". Especially
considering the scope:

   $ cd openssl-master
   $ find -name '*.c' -exec wc -l {} + | tail -1
   419738 total

400,000 lines of C.


I am not presuming, but assuming some amount of technical expertise, based on
a poster asking about openssl configuration and which ECs they want to
support. If they need more help they can ask in a follow up.


reread the post:

https://cygwin.com/ml/cygwin/2019-06/msg00012.html

He shows some domain knowledge of OpenSSL, but where are you getting that he
knows about compiling C? A conservative read would reveal that he might have no
knowledge of compiling C, and you want him to compile 400,000 lines of C because
its "easy".


Please refrain from your own inappropriate assumptions and meta-commentary
based on that, as this is not a social media platform.


No, but it is a public forum. and I will call out nonsense if I see it. As your
type of comments are off putting to new users.


Why would you assume the poster is a novice? Before commenting, please try
yourself to consider multiple perspectives on posts and replies?


As should you.


--
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: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Steven Penny]

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 easy *to you*, but
its certainly not easy in an objective sense, and definitely not to a novice
Cygwin user.

This is coming from someone who has built hundreds of Cygwin and Mingw64
packages. Have some perspective.


--
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: cmake-3.13.1-1

[Steven Penny]

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 upstream  release.


https://cygwin.com/ml/cygwin/2018-11/msg00234.html

Can we please move this out of test?


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

Dash 0.5.10

[Steven Penny]

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:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Steven Penny]

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 that's the sort of thing that
has caused problems in the past, for now this release is available as
a test version only. If you're able, I'd be very grateful if you can
install it and check it works as expected.

If there are no identified problems, I intend to promote this to
stable in a couple of weeks.


This new version incorporates a fix for a long standing path issue that was
introduced Dec 2016:

https://github.com/git/git/commit/05b458c

and I reported Nov 2018:

https://cygwin.com/ml/cygwin/2018-11/msg00136.html

and patched Dec 2018:

https://github.com/git/git/commit/1cadad6

My basic test passes so thats appreciated. Also this new version incorporates a
feature addition "git blame --color-by-age" which was introduced May 2018:

https://github.com/git/git/commit/3d24129

I never requested a new version because... reasons:

https://cygwin.com/ml/cygwin/2018-05/msg00193.html

at any rate, my basic test for "blame" with color passes so thats appreciated.


--
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: Python extraneous dependencies

[Steven Penny]

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 so much to
this requirement.


https://cygwin.com/ml/cygwin/2019-03/msg00589.html

Is it though? With both Debian and Ubuntu, binutils is a suggested package, not
a required one:

- https://packages.debian.org/stretch/python3.5
- https://packages.ubuntu.com/bionic/python3.6


--
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: python-pip-wheel package

[Steven Penny]

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 alongside Python, why is it not put into "/usr/bin" or
   similar?

2. if "python-pip-wheel" is already installed, what is the point of
   "python27-pip" and similar?


I think I answered my own question. You can use this package with "ensurepip":

https://docs.python.org/library/ensurepip


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

python-pip-wheel package

[Steven Penny]

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 raises some questions:

1. if "pip" is installed alongside Python, why is it not put into "/usr/bin" or
  similar?

2. if "python-pip-wheel" is already installed, what is the point of
  "python27-pip" and similar?


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

Re: Cygwin Ruby and $LOAD_PATH

[Steven Penny]

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.


Correct. Not sure how that happened but Ive since deleted the files and
reinstalled. However the error persists:

   $ org-ruby -d alpha.org
   Exception `LoadError' at
   /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55 - cannot load
   such file -- coderay

I found a fix like this:

diff --git a/lib/org-ruby/html_output_buffer.rb
b/lib/org-ruby/html_output_buffer.rb
index 9d6a061..c0d5f2e 100644
--- a/lib/org-ruby/html_output_buffer.rb
+++ b/lib/org-ruby/html_output_buffer.rb
@@ -44,6 +44,7 @@ module Orgmode
rescue LoadError
  # Pygments is not supported so we try instead with CodeRay
  begin
+gem 'coderay'
require 'coderay'
  rescue LoadError
# No code syntax highlighting

However it turns out that was a red herring. The problem isnt $LOAD_PATH, the
problem is my source file:

   $ cat alpha.org
   #+BEGIN_SRC rust
   fn main() {
  println!("alpha beta");
   }
   #+END_SRC

Coderay does not support Rust currently:

https://github.com/rubychan/coderay/issues/208

If I try again with Ruby code it works fine, even without any patches:

$ cat beta.org
#+BEGIN_SRC ruby
puts 'hello world'
#+END_SRC

$ org-ruby -d beta.org
Exception `LoadError' at
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55 - cannot load such
file -- coderay

puts 
'hello world
'



Thanks for the response - sorry for the noise.


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

Cygwin Ruby and $LOAD_PATH

[Steven Penny]

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
   /usr/share/ruby/vendor_ruby
   /usr/share/rubygems

but Gems get installed to "/home":

   $ gem install org-ruby coderay
   $ gem which org-ruby coderay
   /home/Steven/.gem/ruby/2.3.0/gems/org-ruby-0.9.12/lib/org-ruby.rb
   /home/Steven/.gem/ruby/2.3.0/gems/coderay-1.1.2/lib/coderay.rb

This causes the Gems to not be found:

   $ cat alpha.org
   #+BEGIN_SRC rust
   fn main() {
 println!("alpha beta");
   }
   #+END_SRC

   $ org-ruby -d alpha.org
   Exception `LoadError' at
   /usr/local/share/ruby/site_ruby/rubygems/core_ext/kernel_require.rb:54 -
   cannot load such file -- coderay


--
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] nghttp2 1.37.0-1

[Steven Penny]

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 on updating the "mingw64" variants as well

Cheers


--
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] Updated: mintty 2.9.9

[Steven Penny]

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, he does.

What he has said is exactly right: the problems you are describing will only
be consequential to the maintainer, IE *you*.

As he very correctly put, anyone else building is likely doing so
*for themselves*, hence negating any privacy concern. Unless you are summoning
George Orwell:

If you want to keep a secret, you must also hide it from yourself.


--
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] Updated: mintty 2.9.9

[Steven Penny]

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 a shell, unless you want to
change the default to load "top" as you said.


--
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] Updated: mintty 2.9.9

[Steven Penny]

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 shell. I am not sure the proper way to phrase
it, so i will just put it like this:

Dash is good for writing scripts, personally I prefer it over Bash. However it
is garbage as an interactive shell. It does not even support readline, and that
is fine because its role is to be a fast shell for scripts.

That is why I did not include it before. I would add that your mail is not on
topic. The point of my email was not "Bash should be the dep", it was "some
shell should be a dep".


--
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] Updated: mintty 2.9.9

[Steven Penny]

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 from mintheme.


Mintty requires some shell, hopefully that point cannot be argued.

Having said that, Bash is the obvious candidate as its the only login shell
installed by default.

While adding Bash as a dependency could be somewhat misleading, It would argue
it is more misleading to say that it requires no shell, which is the current
state of affairs.

Cheers


--
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] Updated: mintty 2.9.9

[Steven Penny]

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 definitely *does* depend on Bash, what makes you think it doesnt?
As a simple test case, rename Bash and try to run Mintty. You get this:

Failed to run '/bin/bash': No such file or directory
/bin/bash: Exit 126.


--
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: Python extraneous dependencies

[Steven Penny]

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 so much to
this requirement.


Using Python 3.6 I noticed that a:

   print('hello world')

will actually work with only the Base packages and the "python36" package, and
none of the current "python36" dependencies installed. Obviously this comes with
some caveats as you have pointed out. But my counter is this:

- Current "python36" package is 5,746,648 bytes
- "binutils" 2.29 package is 5,863,216 bytes

So by choosing to have "binutils" as a dependency we are literally doubling the
size of Cygwin Python install. To me this is not trivial. I know with Git it
used to "require" Python but not really - it was only some ancillary scripts
that were eventually broken out into their own package so that the Python
requirement could be removed from Cygwin Git.

To contrast however the Perl dependency remained with Cygwin Git as currently
its too ingrained to be removed. What Im saying is that while you are
technically correct that "binutils" is a requirement for current Cygwin Python,
it doesnt have to be that way. We could move the Python elements that require
binutils into their own package, or we could create a "python_base" similar to
"perl_base".

I think if we just say "something somewhere in the bowels of Python needs it, so
it must be a hard dependency", even if that thing is rarely used by anyone, we
are doing a disservice to the Cygwin community. However that may not be the case
and perhaps "ctypes" is used much more than I am aware of.

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: Python extraneous dependencies

[Steven Penny]

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?  Those are also required for find_library.

still failing for me after installing "python36-devel". however even if it
works, it seems we have an issue. if you need "python36-devel" to use
"find_library", then it seems you only need "binutils" if you are installing
"python36-devel", not "python36".

so the "binutils" dep should be moved from "python36" to "python36-devel". this
way it only hurts people installing the development python, not also people
wanting to run "print('hello world')"

if you have another reason why "python36" should require "binutils" i would be
interested to read it - 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: Python extraneous dependencies

[Steven Penny]

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.


Are you sure about that? It seems that function doesnt even work:

$ python3.6 -q

from ctypes.util import find_library
print(find_library('z'))

None

print(find_library('cygz'))

None

print(find_library('z.dll'))

None

print(find_library('cygz.dll'))

None

$ python3.7 -q

from ctypes.util import find_library
print(find_library('z'))

None

print(find_library('cygz'))

None

print(find_library('z.dll'))

None

print(find_library('cygz.dll'))

None

$ python3.8 -q

from ctypes.util import find_library
print(find_library('z'))

None

print(find_library('cygz'))

None

print(find_library('z.dll'))

None

print(find_library('cygz.dll'))

None

Also see this post:

https://cygwin.com/ml/cygwin/2019-02/msg00432.html


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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Steven Penny]

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 effort to convey that in the package file name).
Proper releases should start with "1".

https://cygwin.com/packaging-contributors-guide.html#updating


I agree. Also currently no dependencies are listed. This is incorrect as Mintty
requires at least the Cygwin DLL. Adding "bash" to "depends2" would take care
of it through child dependencies.


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

OpenSSL 1.1

[Steven Penny]

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:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin-3 and the Bleeding Edge

[Steven Penny]

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 against cygwin-3 base.  Am I reasonably safe to assume it will
still work with cygwin-2.11.2?  Does this generalize to all, or at least most,
other packages?


that is not the best example as the current Cygwin Git is version
2.17.0 (Apr 2018) and 4 minor versions have dropped since then:

- 2.18.0
- 2.19.0
- 2.20.0
- 2.21.0


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

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

[Steven Penny]

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 testing on its ear with this information.


correct, multiple states are possible. this is why the scientific method defines
a control:

https://wikipedia.org/wiki/Scientific_control

in this case that would be a clean virtual machine. if you cant or wont do that,
then you must understand that you only have yourself to blame.

I would argue that what is a disservice to the community is jumping into 
a thread in which you were not involved for no apparent purpose other 
than to insult everyone who was already getting a long just fine without 
your genius to guide us.


i provided a valuable data point, which is what happens with a clean windows
environment - results disagree with your original post. i think you missed my
link first time - i have put again below for convenience!

https://yourlogicalfallacyis.com/ad-hominem

cheers


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

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

[Steven Penny]

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 
particular configuration. Clearly not you. Since it works with 2.11, I'm 
not particularly interested in expending a lot of work figuring out what 
got botched in 3.0 or who did it. Wasn't me, so not my problem.


It was my mistake to assume that the cygwin community was interested in 
interoperability. I should have done more research before making that 
unwarranted assumption.


it very much is your problem, as im using Windows 7 x64 just fine with Cygwin.
and its your problem else you wouldnt have come here posting. you can start
threads with clickbait titles as youve done, buts its a disservice to the
community when you dont have a reproducible problem. thats why this page has
existed for 5 years:

https://stackoverflow.com/help/mcve

the "V" is Verifiable. and until your example is Verifiable then you shouldnt be
surprised if the "problem" goes unsolved.


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

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

[Steven Penny]

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

after you test it and realize like i did that it works, *you* can work forward
from there to figure out what updates if any are causing a problem.

i would like to make that last point vividly clear: its on you to do that
testing. ive already given a clear refutation of your original point, so the
ball is now squarely in your court.


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

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

[Steven Penny]

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 3.0 and 
not 2.x?


you know i just finished reading this entire thread and its kind of depressing.
7 replies from 5 people, and not one person explicitly answered the implicit,
most important, and frankly only question worth answering:

   Can anyone else reproduce this problem?

So i am here to answer that question. I was concerned as *I* use Windows 7 x64
as well. I just tested with a pristine virtual machine with Windows 7 x64 and
Cygwin 3.0.1-1 and it works perfectly fine. Note it works fine with Cygwin.bat
or with the shortcut.

So *something* is wrong on your system. Cant say what it might be, and i hate
for you to have to reinstall the whole OS. However as far as im concerned at
this point, *its you*, not a Cygwin issue unless you can prove otherwise.


--
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: Python extraneous dependencies

[Steven Penny]

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.


Further, I noticed this dependency chain:

python36 > libuuid-devel > pkg-config > libglib2.0_0


Until 3.7, the uuid stdlib module loads libuuid via ctypes, hence the
dependency.  In 3.7, there is a compiled binding, and so the -devel
dependency was dropped.  Also, pkgconf will soon be providing and
replacing pkg-config, which will cause the glib2.0 dependency to be
dropped.


thanks. i was interested further in comparison so i took this file:

https://python.org/ftp/python/3.6.8/python-3.6.8-embed-amd64.zip

then use tar for fair comparison:

   tar -a -c -f python-3.6.8-embed-amd64.tar.xz python-3.6.8-embed-amd64

result:

   $ wc -c python-3.6.8-embed-amd64.tar.xz
   5630160 python-3.6.8-embed-amd64.tar.xz

compare this with cygwin version:

   $ wc -c python36-3.6.8-1.tar.xz
   5746648 python36-3.6.8-1.tar.xz

and that doesnt include the other packages i previously discussed. so it almost
makes more sense to not even use the cygwin version?


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

Python extraneous dependencies

[Steven Penny]

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 they are
actually needed. From my admittedly brief testing, they are not needed:

   $ setup-x86_64 -P python36
   $ setup-x86_64 -x binutils,libglib2.0_0,libuuid-devel,pkg-config
   $ python3 -c 'print("hello world")'
   hello world


--
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: Cygwin 3.0.0-0.1

[Steven Penny]

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:

https://cygwin.com/ml/cygwin/2019-01/msg00276.html

i am getting similar result:

$ git log -1
  0 [main] git 4128 fixup_mmaps_after_fork: VirtualQueryEx failed for
MAP_PRIVATE address 0x6E1, Win32 error 5
828 [main] git 4128 C:\cygwin64\bin\git.exe: *** fatal error in forked process
- recreate_mmaps_after_fork_failed
1632 [main] git 4128 cygwin_exception::open_stackdumpfile: Dumping stack trace
to git.exe.stackdump
  0 [main] git 2632 fork: child -1 - forked process 4128 died unexpectedly,
retry 0, exit code 0x100, errno 11
error: cannot fork() for less: Resource temporarily unavailable

workaround is to stop forking:

$ git --no-pager log -1

Personally I am going back Cygwin 2 until this is resolved. Cheers


--
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: Cygwin 3.0.0-0.1

[Steven Penny]

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 sensitivity programatically.

- New tools chattr(1) and lsattr(1) to utilize setting and viewing the
  aforementioned new ioctl's on the command line.


these are very much appreciated. going back to my previous post:

https://cygwin.com/ml/cygwin/2018-12/msg00163.html

i re-ran with the new tool, however i am getting unexpected result:

$ lsattr /cygdrive/c
-hs- /cygdrive/c/$Recycle.Bin
-hs- /cygdrive/c/Config.Msi
 /cygdrive/c/cygwin64
lsattr: Device or resource busy while trying to open /cygdrive/c/pagefile.sys
 /cygdrive/c/PerfLogs
r--- /cygdrive/c/Program Files
r--- /cygdrive/c/Program Files (x86)
-h---n-- /cygdrive/c/ProgramData
-hs--n-- /cygdrive/c/Recovery
-hs- /cygdrive/c/System Volume Information
r--- /cygdrive/c/Users
 /cygdrive/c/Windows

compare with cmd.exe:


dir /A C:\

2018-10-08  11:20 AM  $Recycle.Bin
2019-01-10  05:20 PM  Config.Msi
2019-01-29  06:33 PM  cygwin64
2009-07-13  11:08 PM Documents and Settings [C:\Users]
2018-10-08  07:48 PM  NVIDIA
2018-12-23  09:57 AM17,138,294,784 pagefile.sys
2009-07-13  09:20 PM  PerfLogs
2019-01-01  02:10 PM  Program Files
2018-12-19  01:19 PM  Program Files (x86)
2018-10-31  06:07 PM  ProgramData
2018-10-08  11:14 AM  Recovery
2019-01-29  03:36 PM  System Volume Information
2018-11-18  01:10 AM  Users
2018-11-09  08:18 AM  Windows

or attrib:


attrib C:\pagefile.sys

A  SHC:\pagefile.sys


--
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] Updated: Perl distributions

[Steven Penny]

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
Math::BigInt 1.999806 (2016-12-13).

Some important changes have dropped since then, for example "to_hex", "to_oct"
and "to_bin" with 1.999808 (2017-01-11).


--
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: Bash heredoc on FD 3

[Steven Penny]

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!


--
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: Bash heredoc on FD 3

[Steven Penny]

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 cygwin1-20190107.dll.xz. My results below. Note that "success"
means that with Bash, the script runs without error, regardless of
"POSIXLY_CORRECT" variable as you said. "failure" is to mean that with Bash,
running with "POSIXLY_CORRECT" produces this error:

   awk: error: can't open source file `/dev/fd/3' for reading (Permission
   denied)

Windows 10: success
Windows 8.1: failure
Windows 7: failure

Testing done using virtual machines from here:

https://developer.microsoft.com/microsoft-edge/tools/vms

Even if we must leave things as is, maybe its not that bad. Ideally it should be
working regardless of the variable as you said, but on all 3 Windows version.
But at least we have a workaround if need be. I would like to avoid unsetting
POSIXLY_CORRECT if I can though as it tends to be a net positive for me - as it
forces me to be more strict with code writing.

Also some might have the opinion "so what", lul those are old. Well, yes they
are but Windows 7 still has a higher marketshare than Windows 10:

https://netmarketshare.com/operating-system-market-share?id=platformsDesktopVersions

so until that changes I think we should consider it in the decsion making
process.


--
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: Bash heredoc on FD 3

[Steven Penny]

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 hello.sh
   hello world

   $ bash hello.sh
   awk: error: can't open source file `/dev/fd/3' for reading (Permission
   denied)

   $ unset POSIXLY_CORRECT
   $ bash hello.sh
   hello world


--
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] [Updated] mingw64-{i686,x86_64}-gcc-7.4.0-1

[Steven Penny]

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:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Steven Penny]

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:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

"test" producing unexpected results after "chmod"

[Steven Penny]

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

   $ cd /tmp
   $ touch alpha.txt
   $ test -r alpha.txt; echo "$?"
   0
   $ chmod -r alpha.txt
   $ test -r alpha.txt; echo "$?"
   0

It seems Cygwin is not able to produce non-readable files.


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

Exclude System entries with "ls" or "find"

[Steven Penny]

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  10:14 AM  cygwin64
   2009-07-13  09:20 PM  PerfLogs
   2018-12-15  06:05 PM  Program Files
   2018-12-15  05:21 PM  Program Files (x86)
   2018-10-31  06:07 PM  ProgramData
   2018-11-18  01:10 AM  Users
   2018-11-09  08:18 AM  Windows

as can be seen, Command Prompt has a way to exclude System items. Does Cygwin
have some way to do this, perhaps with "ls" or "find"?


--
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: grep 3.0-2 not stripping CRs on Windows

[Steven Penny]

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 carriage
returns. as was said, this change was intentionally done for the purpose of
making scripts MORE portable:

https://cygwin.com/ml/cygwin/2017-02/msg00155.html

if you want to keep your grep command, you need to remove CR first:

   $ printf 'alpha\r\nbeta\r\n' > CRLF.txt
   $ tr -d '\r' < CRLF.txt | grep 'a$'
   alpha
   beta


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

Bash heredoc on FD 3

[Steven Penny]

Using this file:

   $ cat hello.sh
   awk -f /dev/fd/3 3

Re: Cygwin Git with Windows paths

[Steven Penny]

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 path conversions:

   $ ls /var
   cache  lib  log  run  tmp

   $ strace ls /var | grep -E '(conv_to|normalize)_(posix|win32)_path' | wc
   32 3203337

So either this code should be pulled out of the Cygwin DLL, or people should
stop saying that its not supported.


I see you've raised this on the Git mailing list as well, and if the
upstream Git package starts to handle such paths, I'll take the
relevant patches. However since I don't consider this a bug, I'm not
going to raise it myself.


Its not fixed upstream (yet), but a patch is available that fixes the issue:

http://public-inbox.org/git/20181126173252.1558-1-tbo...@web.de

Note carefully that Windows path handling previously worked with Cygwin Git
until Dec 2016, when a patch was introduced that broke that use case. The patch
in question repairs the path handling so that Unix and Windows paths are both
supported with Cygwin Git again.


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

Cygwin Git with Windows paths

[Steven Penny]

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 into 'C:\cygwin64\tmp\goawk'...
   fatal: Invalid path '/home/Steven/C:\cygwin64\tmp\goawk': No such file or
   directory

and mixed form:

   $ git clone git://github.com/benhoyt/goawk C:/cygwin64/tmp/goawk
   fatal: Invalid path '/home/Steven/C:/cygwin64': No such file or directory

Note that other Cygwin programs work fine with these forms:

   $ ls 'C:\cygwin64'
   bin Cygwin.ico   dev  home  sbin  usr
   Cygwin.bat  Cygwin-Terminal.ico  etc  lib   tmp   var

This causes problems for any non-Cygwin tools that might call Git:

http://github.com/golang/go/issues/23155


--
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] Updated: zstd-1.3.7-1 and development headers / libraries

[Steven Penny]

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.


Zstandard, or zstd as short version, is a fast lossless compression
algorithm, targeting real-time compression scenarios at zlib-level and
better compression ratios.

http://www.zstd.net/

This version is compiled with support for GZip, LZ4 and Xz compression.


Sorry if this is the wrong place to ask - but with the announcement also here:

http://cygwin.com/ml/cygwin/2018-10/msg00167.html

is is planned to make this a "Base" package sometime soon? Currently is it not
a Base package and does not have a reverse dependency chain to a Base package.


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

Re: Bug report: Core dump with too many args

[Steven Penny]

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


Not sure what you are expecting to happen when you provide pathological input to
the shell? For context - Fedora essentially does the same thing:

   $ /bin/echo `seq 100`
   Killed


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

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

[Steven Penny]

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 NotoSansMyanmar-Regular.ttf

test.txt:

   U+1000 MYANMAR LETTER KA
   [က]

Set font for cmd.exe to Consolas and test:

   chcp 65001
   type test.txt

Test B
--

set font for mintty.exe to Consolas and test:

   chcp.com 65001
   cat test.txt

Results
---

Both tests pass with Windows 8.1. With Windows 7, only the cmd.exe test will
pass. I am of the position that if cmd.exe passes on Windows 7, then mintty
should as well.

References
--

- http://developer.microsoft.com/microsoft-edge/tools/vms
- http://docs.microsoft.com/globalization/input/font-technology
- http://fileformat.info/info/unicode/char/1000/index.htm


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

Re: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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" has U+FFFD and "Notepad" can
utilize composite font, while it appears "cmd.exe" and similar cannot.


http://cygwin.com/ml/cygwin/2018-09/msg00060.html

I should correct myself. "cmd.exe" can do this, its called Font Linking:

http://docs.microsoft.com/globalization/input/font-technology

it allows you to pick a "base font", for example "Consolas". Then you can link
another font that has U+FFFD, like "Tahoma". Ideally both fonts would be
monospace, but it seems Windows has no builtin monospace font with U+FFFD.

Then when a missing character is encountered, it will pull from the linked font
if possible.


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

Re: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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 on W7. i found a W10 virtual machine here:

http://developer.microsoft.com/microsoft-edge/tools/vms

but it requires 4GB RAM just for the image. since i only have 4GB total on my
system the image wont load into virtualbox.

i can see about upgrading my system - but i wont bother if you are intent on
wiping your hands of this anyway

let me know - 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: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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 have is:

   U+01C4 LATIN CAPITAL LETTER DZ WITH CARON

Using this file:

   $ cat glyph.c
   #include 
   #include 
   int main()
   {
 CONSOLE_FONT_INFOEX ta;
 ta.cbSize = sizeof ta;
 GetCurrentConsoleFontEx(GetStdHandle(STD_OUTPUT_HANDLE), 0, );
 HDC wh = GetDC(0);
 SelectObject(wh,
   CreateFontW(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ta.FaceName));
 WCHAR xr[4] = {0xFFFD, 0x2592, 0x25A1, 0x01C4};
 WORD zu[4];
 GetGlyphIndicesW(wh, xr, 4, zu, 1);
 printf("%ls:\n", ta.FaceName);
 for (int q = 0; q < 4; q++) {
   printf("  U+%04X: %s\n",
   xr[q], zu[q] == 0x ? "failure" : "success");
 }
   }

I get this result:

   DejaVu Sans Mono:
 U+FFFD: success
 U+2592: success
 U+25A1: success
 U+01C4: failure


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

Tab completion adding spurious escape characters

[Steven Penny]

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 of them:

   $ (set -x; true \' \! \$ \& \( \) \, \; \@ \[ \] \^ \` \{ \} \=)
   + true \' '!' '$' '&' '(' ')' , ';' @ '[' ']' '^' '`' '{' '}' =

Notice carefully that the shell removes escaping for these:

   , @ =

but tab completion is adding it. Is this an issue of Readline or Cygwin?


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

Re: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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 for this, it would make
sense to use them, especially since linux is already using them:

1. U+FFFD: http://unicode.org/charts/nameslist/n_FFF0.html
2. U+25A1: http://unicode.org/charts/nameslist/n_25A0.html


valid code point with no glyph in font -> .notdef glyph -> WHITE SQUARE


this is not true. "WHITE SQUARE" refers to U+25A1, which is an actual character
and different from the ".notdef" glyph. as has been discussed as length in this
thread, the ".notdef glyph" is not an actual character, but a glyph that exists
at position 0 in the font, and while its appearance is not strictly defined,
some recommendations exist:

- empty rectangle
- rectangle with a question mark
- rectangle with an X

Now if you switch to FFFD REPLACEMENT CHARACTER for invalid code point, 
and considering that it does not exist in most actual fonts and that the 
console does not apply font fallback, it will resolve to WHITE SQUARE, thus:

folding the two different use cases into the same appearance,
which is bad.


no again, it will resolve to ".notdef glyph", as I put above. otherwise yes, you
do have a point. in the case of a font without U+FFFD, you have ultimately:

invalid code point: .notdef glyph
missing character: .notdef glyph

several ideas have been proposed:

1. keep U+FFFD
2. go back to U+2592
3. use U+25A1 instead
4. use U+FFFD if possible else fallback to U+2592 or U+25A1

if we choose option 1, people not happy with the ambiguity can simply install
"dejavu-fonts" or similar, which Cygwin provides.


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

Re: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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 has to do with the unfounded design
decision to use U+2592. Granted at this point we are bikeshedding - but an
official standard does exist, namely Unicode, with 2 applicable characters for
this use case:

1. U+FFFD: http://unicode.org/charts/nameslist/n_FFF0.html
2. U+25A1: http://unicode.org/charts/nameslist/n_25A0.html


Should any changes to the way a character is displayed be required, it
needs to be in the terminal program that display the character, not in
cygwin which should pass the character along unmodified.


the "terminal" in this case is either "cygwin" or "xterm" - in both cases code
changes have already been made in reponse to this thread, so i dont think your
comment here holds weight.


Both cygwin and Debian 9.5 show:

$ file alfa.txt
alfa.txt: ISO-8859 text

When Linux reads the file, it assumes the encoding is UTF-8.
When cygwin reads the file, it assume the encoding is CP1252
This command shows the problem

$ iconv -f utf8 alfa.txt
iconv: alfa.txt:1:0: incomplete character or shift sequence

On Linux, this shows a slightly different message, with the same intent.

Try using this string:

$ printf "\xC3\xAB\353\n"
=C3=AB=E2=96=92

to get a better understanding of the problem. It contains two
representation of LATIN SMALL LETTER E WITH DIAERESIS, first encoded
in UTF-8, then using ISO-8859-1.


now it appears *you* are going down the rabbit hole. both Cygwin and Mintty were
in violation on Unicode standard - however this has already been remedied in the
code.


There are two different reasons for the MEDIUM SHADE. Here it
indicates an invalid UTF-8 character, and the font does not have a
glyph for REPLACEMENT CHARACTER. The MEDIUM SHADE is also used in
place of an ordinary character without a glyph in the font.


this is flat wrong. U+2592 MEDIUM SHADE is *only* used in cases of invalid
UTF-8. In case of missing character - the ".notdef" glyph is used - as has been
discussed several times in this thread. This is not an actual character, so i
cannot paste it here - but as an example with "DejaVu Sans Mono" the glyph is
an empty rectangle.


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

Re: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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 with Corinna how to get that work 
inside cygwin. Otherwise, my opinion:

- *working* fallback from FFFD to 2592: good


i am fine with this, but i think corinna feels it is too much code for not
enough benefit - thats her decision.

- fix FFFD: not good, because the .notdef glyph is not an appropriate 
indication of illegal encoding (like broken UTF-8 bytes)


not sure what you even mean by this - FFFD doesnt need fixing - Windows just
need to adopt some fonts with proper unicode support. we are dealing with their
lack of doing that.


the .notdef glyph is not an appropriate indication of illegal encoding (like
broken UTF-8 bytes)


true, but neither is U+2592. as far as i know U+2592 is not defined officially
anywhere as being a representation of anything other than "MEDIUM SHADE".
Corinna originally added it in 2009:

http://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git=commitdiff=161211d

with no justification of why it was chosen that i can tell. similarly, mintty
actually changed from U+FFFD to U+2592 in 2009:

http://github.com/mintty/mintty/commit/90c11d3

with actually a good reason, which was to avoid ambiguity with fonts that didnt
have U+FFFD. but again, no reason why U+2592 was chosen. i personally see both
sides of the argument but i tend to land of the side of any standards if they
exist. Here is the standard for U+FFFD:

http://unicode.org/charts/nameslist/n_FFF0.html


- revert to 2592: OK


if we were to use something other than U+FFFD, I would propose U+25A1, as it is
also defined by Unicode:

   25A1  □  White Square
   •may be used to represent a missing ideograph

http://unicode.org/charts/nameslist/n_25A0.html

and it has better support than U+FFFD:

   yes:
   - Consolas
   - Courier New
   - DejaVu Sans Mono
   - MS Gothic
   - NSimSun

   no:
   - Lucida Console
   - SimSun-ExtB


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

Re: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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 cygwin 
implement a bad compromise. If conhost ever improves, cygwin can adapt.


This is some dangerous commentary. I would like to counter it now with some
actual research. Using BabelMap:

http://babelstone.co.uk/Software/BabelMap.html

You can do "Fonts", "Font Coverage" and you will get this result with code point
FFFD:

   yes: DejaVu Sans Mono

   no:
   - Consolas
   - Courier New
   - Lucida Console
   - MS Gothic
   - NSimSun
   - SimSun-ExtB

This is concerning true, but we can then review the ".notdef glyph" for the
problem fonts. As this glyph is not an actual character, i cant paste it here,
but i will describe them below:


   empty rectangle:
   - Courier New
   - Lucida Console
   - MS Gothic
   - SimSun-ExtB

   rectangle with a question mark inside: Consolas

   none: NSimSun

Note that I did not include "Raster Fonts", as it doesnt even allow multibyte
characters:

   $ printf '\xC2\xA1\n'
   sh: printf: write error: Permission denied


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

Re: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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 Gothic, NSimSun, Raster Fonts, SimSun-ExtB.


You can add DejaVu or others like this:

http://superuser.com/questions/390933/add-font-cmd-window-choices/956818


Yeah, that's it then.  Whatever.  The fact that none of the default
fonts available for the console provide 0xfffd REPLACEMENT CHARACTER
doesn't really contribute to my willingness to add lots of code for
a border case.

We either keep 0xfffd now and the user gets the nodef glyph, or I revert
the patch and let the console print 0x2592 MEDIUM SHADE again.

Decision has to be made today.  I will release 2.11.1 tomorrow.


I prefer to you keep the patch that has been committed already. I was never a
fan of falling back to U+2592, but since we have the code for that now its your
call.

Cheers


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

Re: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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 that none of the fonts support
0xfffd "REPLACEMENT CHARACTER", but all three support 0xfffc
"OBJECT REPLACEMENT CHARACTER".  I expanded the testcase to check
for this with GetGlyphIndicesW and, lo and behold, the result
makes sense.


Here is my code if it helps:

   #include 
   #include 
   int main()
   {
 CONSOLE_FONT_INFOEX ta;
 ta.cbSize = sizeof ta;
 GetCurrentConsoleFontEx(GetStdHandle(STD_OUTPUT_HANDLE), 0, );
 HDC wh = GetDC(0);
 SelectObject(wh,
   CreateFontW(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ta.FaceName));
 WCHAR xr = 0xFFFD;
 WORD zu[1];
 GetGlyphIndicesW(wh, , 1, zu, 1);
 printf("%ls: %s\n", ta.FaceName, *zu == 0x ? "FAILURE" : "SUCCESS");
   }

Result:

   DejaVu Sans Mono: SUCCESS
   Consolas: FAILURE


On the other hand, during testing I saw a 0xfffd character printed for
these fonts.  None of them actually supports 0xfffd, so apparently the
Windows console already uses replacement fonts if possible.

I guess I just stop here and always print 0xfffd.  I seriously doubt
it makes sense to add so much code just to print a single char in a
border case.


this is not possible; most likely you were seeing the ".notdef glyph":

http://docs.microsoft.com/typography/opentype/spec/recom

for Consolas which is simlar in appearance to U+FFFD REPLACEMENT CHARACTER. The
differnce is that if you copy the ".notdef glyph" and paste it into "Notepad" or
similar, it will paste the proper character that couldnt be seen in the console,
while pasting U+FFFD into "Notepad" will just paste itself.

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" has U+FFFD and "Notepad" can utilize composite
font, while it appears "cmd.exe" and similar cannot.


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

Re: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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 it by the Windows font fallback mechanism.

Shall I make it configurable?


your call - here are the possible resolutions - in order of my preference:

1. Change the default to U+FFFD with no option
2. Change the default to U+FFFD with option to change
3. Leave default as is with option to change


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

Re: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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 check your character set,
open Charmap, and check Advanced View. Type "Replacement Character" on
the Search field, and search.) In the absence of that glyph, the
terminal program must choose a glyph to display. In a later reply,
Thomas Wolff, the maintainer of Mintty, indicates that Mintty displays
the glyph for U+2592: Medium Shade (or a similar one). Without
reference to the source, it is difficult to be certain, but Conhost
appears to use a similar glyph.

In Mintty, if you choose a font, such as DejaVu Sans Mono, which
contains a glyph for U+FFFD: Replacement Character, you could expect
to see that glyph, however that is determined by the terminal. As I
write this, both Mintty (2.9.0) and Conhost (Windows 10 Home,
10.0.17134 Build 17134, fully patched) display a glyph with the
appearance of U+2592 Medium Shade.


Hm, this is a tough call. These fonts come with Windows:

- Consolas
- Lucida Console

Neither of them provide U+FFFD, so that means it will fall back to the
".notdef glyph":

http://docs.microsoft.com/typography/opentype/spec/recom

That presents 2 options:

U+FFFD:
 unicode conformant:
   yes
 consolas or lucida console:
   invalid byte or missing char: same glyph

U+2592:
 unicode conformant:
   no
 consolas or lucida console:
   invalid byte or missing char: different glyph
   
I would prefer the first option - as other fonts do define U+FFFD, including

"DejaVu Sans Mono" which Cygwin provides via the "dejavu-fonts" package. However
I can understand if we wanted to side with people using one of the default
fonts.


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

Re: Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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"
   LC_TIME="en_US.UTF-8"
   LC_COLLATE=C
   LC_MONETARY="en_US.UTF-8"
   LC_MESSAGES="en_US.UTF-8"
   LC_PAPER="en_US.UTF-8"
   LC_NAME="en_US.UTF-8"
   LC_ADDRESS="en_US.UTF-8"
   LC_TELEPHONE="en_US.UTF-8"
   LC_MEASUREMENT="en_US.UTF-8"
   LC_IDENTIFICATION="en_US.UTF-8"
   LC_ALL=

   $ cat --version
   cat (GNU coreutils) 8.29

Cygwin:

   $ echo "$TERM"
   cygwin

   $ locale
   LANG=en_US.UTF-8
   LC_CTYPE="en_US.UTF-8"
   LC_NUMERIC="en_US.UTF-8"
   LC_TIME="en_US.UTF-8"
   LC_COLLATE="C"
   LC_MONETARY="en_US.UTF-8"
   LC_MESSAGES="en_US.UTF-8"
   LC_ALL=

   $ cat --version
   cat (GNU coreutils) 8.26

Note that in addition to Linux, Windows PowerShell also gives correct output:

   $ pwsh -c '[system.text.encoding]::UTF8.getString(0xEB)'
   �

compare again with Cygwin:

   $ printf '\xEB'
   ▒


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

Cygwin fails to utilize Unicode replacement character

[Steven Penny]

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 Unicode Character 'MEDIUM SHADE' (U+2592).


--
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: error in "cygpath" behavior

[Steven Penny]

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 relative Windows paths must not be longer than
MAX_PATH (260) chars.

I'm certainly open to patches to the underlying cygwin_conv_path
function to change the Windows path to relative if possible.


I am not understanding - it appears that "dot-dot" (..) is well defined by
POSIX:


The special filename dot-dot shall refer to the parent directory of its
predecessor directory. As a special case, in the root directory, dot-dot may
refer to the root directory itself.


http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13

so it would appears that ".." would be an acceptable return value in any case.


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

error in "cygpath" behavior

[Steven Penny]

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\


--
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.11.0-0.4

[Steven Penny]

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:   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] [Updated] mingw64-{i686,x86_64}-gcc-7.3.0-1 (Test)

[Steven Penny]

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") << std::endl;
   }

and these:

   mingw64-x86_64-gcc-g++ 7.3.0
   mingw64-x86_64-gcc-core 7.3.0

and mingw64-x86_64-binutils 2.29.1:

   $ time x86_64-w64-mingw32-g++ -static stoi.cpp; wc -c a.exe
   real0m2.337s
   11577536 a.exe

now with mingw64-x86_64-binutils 2.28.1:

   $ time x86_64-w64-mingw32-g++ -static stoi.cpp; wc -c a.exe
   real0m2.300s
   11577470 a.exe

now with mingw64-x86_64-binutils 2.25.0:

   $ time x86_64-w64-mingw32-g++ -static stoi.cpp; wc -c a.exe
   real0m2.350s
   11577536 a.exe

Going back to my original theory - it seems something is wrong with
"libstdc++.a", and has been for some time. Here a summation of the Cygwin
versions:

   Name: libstdc++.a
   Name: usr\lib\gcc\x86_64-w64-mingw32\7.3.0\
   Size: 22 446 354

   Name: libstdc++.a
   Name: usr\lib\gcc\x86_64-w64-mingw32\6.4.0\
   Size: 22 066 330

   Name: libstdc++.a
   Name: usr\lib\gcc\x86_64-w64-mingw32\6.3.0\
   Size: 22 034 356

   Name: libstdc++.a
   Name: usr\lib\gcc\x86_64-w64-mingw32\5.4.0\
   Size: 20 719 186

Compare this with Msys2:

   Name: libstdc++.a
   Name: mingw64\lib\gcc\x86_64-w64-mingw32\7.3.0\
   Size: 5 596 296

or with Debian:

   Name: .\usr\lib\gcc\x86_64-w64-mingw32\7.3-posix\
   Name: libstdc++.a
   Size: 5 093 564

Or Ubuntu:

   Name: .\usr\lib\gcc\x86_64-w64-mingw32\7.3-posix\
   Name: libstdc++.a
   Size: 5 085 236

References:

- 
http://mirror.rit.edu/cygwin/x86_64/release/mingw64-x86_64-gcc/mingw64-x86_64-gcc-g%2b%2b
- http://packages.debian.org/buster/g++-mingw-w64-x86-64
- http://packages.ubuntu.com/hu/bionic/g++-mingw-w64-x86-64
- http://repo.msys2.org/mingw/x86_64


--
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] [Updated] mingw64-{i686,x86_64}-gcc-7.3.0-1 (Test)

[Steven Penny]

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 mingw64/lib/gcc/x86_64-w64-mingw32/8.2.0/libstdc++.a
    5597192 mingw64/lib/gcc/x86_64-w64-mingw32/8.2.0/libstdc++.a


And it is of course totally out of the question that this difference 
could be caused by these being different major versions of GCC, right?


next time before you post such a comment on a public forum, you might actually
check that you know what youre talking about beforehand.

   $ wc -c mingw64/lib/gcc/x86_64-w64-mingw32/7.3.0/libstdc++.a
   5596296 mingw64/lib/gcc/x86_64-w64-mingw32/7.3.0/libstdc++.a

cheers


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