Re: error in "cygpath" behavior

[Thomas Wolff]

Am 31.08.2018 um 22:05 schrieb Eric Blake:

On 08/31/2018 02:48 PM, cyg Simple wrote:



Don't forget the possibility that '..' points to a symlink which Windows
will not understand.

$ mkdir -p /foo/baz
$ ln -s /foo /bar
$ cd /bar/baz
$ cygpath -w ..


Except .. never points to a symlink.  It always points to the physical 
directory that contains the current directory (that is, /foo, not 
/bar).  The shell can maintain a notion of a logical current directory 
(based on whether you use 'set -P' for physical or 'set +P' for 
logical; where bash defaults to +P), and in that mode, 'cd ..' behaves 
logically (acting as though you are now in /bar, rather than actually 
changing you to /foo).  But that still doesn't change the fact that 
'..' in file name resolution never resolves to a symlink, because the 
shell is merely rewriting your ".." to avoid passing it on to the 
syscalls, rather than the syscalls actually knowing about logical mode.
As a side-note, this is also the reason that you may be facing apparent 
inconsistency with path name completion,
like `ls ../[TAB]` suggesting you files and directories that do not 
exist once you run the command.

This is not cygwin-specific.

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
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: Regression in Cygwin 2.11.0-1

[Andreas Hauptmann]

On Sat, 1 Sep 2018 01:24:49 +
Bryan Phelps wrote:

> I'll continue to look around for a more minimal repro,

The normalization of paths with backslashes has changed.

The following doesn't work any longer:

cd /tmp
stat "..\bin\file.exe" # or
stat "..\\bin\\file.exe"

This however still works:

stat "C:\cygwin\bin\file.exe"



--
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: Regression in Cygwin 2.11.0-1

[Marco Atzeri]

Am 01.09.2018 um 03:24 schrieb Bryan Phelps:

Hello,



In the meantime - is there a way we can pin the cygwin package to the 2.10.0-1 
version, to unblock our builds?


Thank you!

Bryan


What is the problem in installing the previous version of the package ?


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
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: Regression in Cygwin 2.11.0-1

[Marco Atzeri]

Am 01.09.2018 um 03:24 schrieb Bryan Phelps:

Hello,


Thank you for all the work on Cygwin! I've been using it to spin up an 
environment to build the OCaml compiler / toolchain, and it was working great.


However, today, all our CI builds mysteriously started failing - at first, I 
suspected it was a problem with AppVeyor, but I also failures with VSTS. We use 
an NPM package (`esy-bash`) to spin up a Cygwin environment, and then use that 
to build the OCaml toolchain.


The error message we started receiving today is:

OCAML_FLEXLINK="../boot/ocamlrun ../flexdll/flexlink.exe" ../byterun/ocamlrun 
../ocamlc -g -nostdlib -I ../utils -I ../parsing -I ../stdlib -I ../compilerlibs 
-strict-sequence -safe-string -strict-formats -w +a-4-9-41-42-44-45-48 -warn-error A 
-custom ocamlcommon.cma -o ocamltest.exe run_win32.o run_stubs.o ocamltest_config.cmo 
testlib.cmo run_command.cmo filetype.cmo filecompare.cmo backends.cmo variables.cmo 
environments.cmo builtin_variables.cmo builtin_modifiers.cmo actions.cmo 
builtin_actions.cmo tests.cmo builtin_tests.cmo tsl_ast.cmo tsl_parser.cmo tsl_lexer.cmo 
tsl_semantics.cmo options.cmo main.cmo
x86_64-w64-mingw32-gcc: error: ../stdlib\libcamlrun.a: No such file or directory



Question:
is libcamlrun.a built correctly and in the same directory than before ?
This mixed "../stdlib\libcamlrun.a" slash looks strange



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
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: Regression in Cygwin 2.11.0-1

[David Allsopp]

Marco Atzeri wrote:
> Am 01.09.2018 um 03:24 schrieb Bryan Phelps:
> > Hello,
> >
> >
> > Thank you for all the work on Cygwin! I've been using it to spin up an
> environment to build the OCaml compiler / toolchain, and it was working great.
> >
> >
> > However, today, all our CI builds mysteriously started failing - at first, I
> suspected it was a problem with AppVeyor, but I also failures with VSTS. We
> use an NPM package (`esy-bash`) to spin up a Cygwin environment, and then
> use that to build the OCaml toolchain.
> >
> >
> > The error message we started receiving today is:
> >
> > OCAML_FLEXLINK="../boot/ocamlrun ../flexdll/flexlink.exe"
> ../byterun/ocamlrun ../ocamlc -g -nostdlib -I ../utils -I ../parsing -I 
> ../stdlib -I
> ../compilerlibs -strict-sequence -safe-string -strict-formats -w 
> +a-4-9-41-42-44-
> 45-48 -warn-error A -custom ocamlcommon.cma -o ocamltest.exe run_win32.o
> run_stubs.o ocamltest_config.cmo testlib.cmo run_command.cmo filetype.cmo
> filecompare.cmo backends.cmo variables.cmo environments.cmo
> builtin_variables.cmo builtin_modifiers.cmo actions.cmo builtin_actions.cmo
> tests.cmo builtin_tests.cmo tsl_ast.cmo tsl_parser.cmo tsl_lexer.cmo
> tsl_semantics.cmo options.cmo main.cmo
> > x86_64-w64-mingw32-gcc: error: ../stdlib\libcamlrun.a: No such file or
> directory
> >
> 
> Question:
> is libcamlrun.a built correctly and in the same directory than before ?

I haven't double-checked, but the build cannot have got this far if the file 
were really missing.

> This mixed "../stdlib\libcamlrun.a" slash looks strange

Yeah, our build system is not terribly hygienic when it comes to mixing forward 
and backslashes in the Windows builds (the Windows shell of course is mostly 
forgiving of the mixture).

It's not immediately clear to me from the announcement whether this change in 
behaviour is a regression or an intentional change? Only asking in terms of how 
quickly we need to make OCaml's build system cleaner.

It's worth noting in this instance that x86_64-w64-mingw32-gcc would be being 
invoked by a non-Cygwin executable here (i.e. which IIRC is slightly different 
path normalisation than when it's invoked from bash).


David

Re: Bug Report: Regression in Cygwin 2.11.0-1

[Thomas Wolff]

Am 01.09.2018 um 10:10 schrieb Marco Atzeri:

Am 01.09.2018 um 03:24 schrieb Bryan Phelps:

Hello,


Thank you for all the work on Cygwin! I've been using it to spin up 
an environment to build the OCaml compiler / toolchain, and it was 
working great.



However, today, all our CI builds mysteriously started failing - at 
first, I suspected it was a problem with AppVeyor, but I also 
failures with VSTS. We use an NPM package (`esy-bash`) to spin up a 
Cygwin environment, and then use that to build the OCaml toolchain.



The error message we started receiving today is:

OCAML_FLEXLINK="../boot/ocamlrun ../flexdll/flexlink.exe" 
../byterun/ocamlrun ../ocamlc -g -nostdlib -I ../utils -I ../parsing 
-I ../stdlib -I ../compilerlibs -strict-sequence -safe-string 
-strict-formats -w +a-4-9-41-42-44-45-48 -warn-error A -custom 
ocamlcommon.cma -o ocamltest.exe run_win32.o run_stubs.o 
ocamltest_config.cmo testlib.cmo run_command.cmo filetype.cmo 
filecompare.cmo backends.cmo variables.cmo environments.cmo 
builtin_variables.cmo builtin_modifiers.cmo actions.cmo 
builtin_actions.cmo tests.cmo builtin_tests.cmo tsl_ast.cmo 
tsl_parser.cmo tsl_lexer.cmo tsl_semantics.cmo options.cmo main.cmo
x86_64-w64-mingw32-gcc: error: ../stdlib\libcamlrun.a: No such file 
or directory




Question:
is libcamlrun.a built correctly and in the same directory than before ?
This mixed "../stdlib\libcamlrun.a" slash looks strange
It does, but remember, we're running on a mixed system. Also the problem 
is not caused by mixed syntax, the following do not work anymore:

    cd /usr; ls '..\bin'
    cd /; ls 'usr\include'
I think it's good that cygwin used to support this and it should be 
reestablished.

Note the following did not even work before, due to mount point issues:
    cd /; ls 'usr\bin'
Not sure whether it's worth fixing that seeming inconsistence as well.

Checking the change log, it might be a side effect of

- Fix a buffer underrun problem in Win32 path normalization.
  Addresses:https://cygwin.com/ml/cygwin/2018-05//msg00017.html


Checking the commit diff
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=35998fc2fa6cbb7d761f6d88346246bd3627552b
this might be a starting point to analyse...

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


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

New Cygwin Version

[Thomas Lake]

I tried my usual mirror but it hadn’t been updated yet. When I tried a 
different mirror it worked.

Sent from Mail for Windows 10


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

[ANNOUNCEMENT] Updated: Perl distributions

[Achim Gratz]

The following Perl distributions have been updated to their latest
version on CPAN, respectively:

x86/x86_64
--
perl-Cpanel-JSON-XS-4.06-1
perl-DateTime-1.50-1
perl-Net-DNS-SEC-1.10-1
perl-YAML-LibYAML-0.74-1

noarch
--
perl-Archive-Zip-1.63-1
perl-CGI-4.40-1
perl-Date-Manip-6.73-1
perl-HTTP-Tiny-0.076-1
perl-IO-Socket-SSL-2.059-1
perl-Module-ScanDeps-1.25-1
perl-Module-Signature-0.83-1
perl-Mojolicious-7.94-1
perl-Params-ValidationCompiler-0.30-1
perl-Path-Tiny-0.108-1
perl-Test-MockModule-0.170.0-1
perl-Test-Simple-1.302140-1
perl-Text-CSV-1.97-1


-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

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

Re: New Cygwin Version

[Marco Atzeri]

Am 01.09.2018 um 11:57 schrieb Thomas Lake:

I tried my usual mirror but it hadn’t been updated yet. When I tried a 
different mirror it worked.



mirros are not handled directly by the cygwin project

https://cygwin.com/mirrors.html

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
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: Regression in Cygwin 2.11.0-1

[Corinna Vinschen]

On Sep  1 09:56, Andreas Hauptmann wrote:
> On Sat, 1 Sep 2018 01:24:49 +
> Bryan Phelps wrote:
> 
> > I'll continue to look around for a more minimal repro,
> 
> The normalization of paths with backslashes has changed.
> 
> The following doesn't work any longer:
> 
> cd /tmp
> stat "..\bin\file.exe" # or
> stat "..\\bin\\file.exe"
> 
> This however still works:
> 
> stat "C:\cygwin\bin\file.exe"

I know where the problem is.  A new piece of code fixing a crash due to
a buffer underflow is too aggressively guarding the path buffer against
this underflow when normalizing ".." in Win32 paths.

I'll fix this and release a 2.11.1 soon, but I still have a question:

Why do I push out test releases if nobody cares?

In terms of this OCAML build system problem:

Please fix your build system.  Do not mix POSIX and Win32 paths, use
POSIX paths only.  Backslashes are *no* drop-in replacement for slashes.
Some of the path handling is seriously crippled as soon as you start
using backslashes, and that's a delipberate decision and won't change,
even after fixing the aforementioned bug.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

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: Bug Report: Regression in Cygwin 2.11.0-1

[David Allsopp]

Corinna Vinschen wrote:
> On Sep  1 09:56, Andreas Hauptmann wrote:
> > On Sat, 1 Sep 2018 01:24:49 +
> > Bryan Phelps wrote:
> >
> > > I'll continue to look around for a more minimal repro,
> >
> > The normalization of paths with backslashes has changed.
> >
> > The following doesn't work any longer:
> >
> > cd /tmp
> > stat "..\bin\file.exe" # or
> > stat "..\\bin\\file.exe"
> >
> > This however still works:
> >
> > stat "C:\cygwin\bin\file.exe"
> 
> I know where the problem is.  A new piece of code fixing a crash due to a 
> buffer
> underflow is too aggressively guarding the path buffer against this underflow
> when normalizing ".." in Win32 paths.
> 
> I'll fix this and release a 2.11.1 soon, but I still have a question:
> 
> Why do I push out test releases if nobody cares?

Like you, we're a (very) small number of maintainers - and, as far as I'm 
aware, the command line setup doesn't exactly make continuous integration 
testing of Cygwin test versions "trivial". I'd love to have had the time within 
the last 22 days to service my care...

> In terms of this OCAML build system problem:
> 
> Please fix your build system.  Do not mix POSIX and Win32 paths, use POSIX
> paths only.  Backslashes are *no* drop-in replacement for slashes.

The "problem" for us is more subtle than this. The program which is generating 
that path is not a Cygwin executable, so it is correctly combining a path it 
has been supplied (the ../stdlib which has been supplied via Cygwin's make) 
with a filename, so it uses a backslash. It's been on my TODO for years to 
enhance to understand that the program it's supplying the path back to is a 
Cygwin executable and so sort it out properly but, well, we're a small number 
of maintainers! That said, WSL is forcing us to address it properly... 

> Some of the path handling is seriously crippled as soon as you start using
> backslashes, and that's a delipberate decision and won't change, even after
> fixing the aforementioned bug.

I don't quite follow this - does that mean that that path definitely work even 
with a new Cygwin? i.e. our existing build system is permanently broken for 
Cygwin 2.11+?


David

--
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: Regression in Cygwin 2.11.0-1

[Houder]

On Sat, 1 Sep 2018 17:54:35, Corinna Vinschen wrote:
> I'll fix this and release a 2.11.1 soon, but I still have a question:
> 
> Why do I push out test releases if nobody cares?

Yes, I know, it is a _hypothetical_question_. You do not really expect
an answer.

However it was my thought exactly. Nobody? I like to think that those
that were responsible for patches, have tested their modifications.

I did.

On the other hand, those that will find problems, the people building
packages, will only do that on "official" releases.

I am almost sure of that :-)

Unless you like creating test releases, releasing only one before you
push an "official" one, would be more efficient, I imagine.

Yes, you would run the chance that you would have to mend an official
release several times ... but is that bad?

Just a thought.

Henri


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

[Thomas Wolff]

Am 01.09.2018 um 18:13 schrieb 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).
Which terminals are used and what's the output of `locale` and `cat 
--version` in both cases?


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


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

RE: [ANNOUNCEMENT] Updated: Cygwin 2.11.0-1

[tlake]

I don't see it on the 20-plus mirrors I tried.

Tom L

-Original Message-
From: tl...@twcny.rr.com  
Sent: Friday, August 31, 2018 4:31 PM
To: cygwin@cygwin.com
Subject: RE: [ANNOUNCEMENT] Updated: Cygwin 2.11.0-1

After running setup (64 bit) I still have version 2.10. I even tried 
uninstalling and running setup again.

Tom L
-Original Message-
From: Corinna Vinschen  
Sent: Friday, August 31, 2018 11:21 AM
To: cygwin@cygwin.com
Subject: [ANNOUNCEMENT] Updated: Cygwin 2.11.0-1

Hi folks,


I uploaded a new Cygwin release 2.11.0-1.





--
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: Cygwin 2.11.0-1

[tlake]

Am 31.08.2018 um 22:31 schrieb tl...@twcny.rr.com:
> After running setup (64 bit) I still have version 2.10. I even tried 
> uninstalling and running setup again.
>
> Tom L


have you stopped all processes including services before the update ?

The problem turned out to be that the mirror I was using hadn't been updated 
yet. When I tried a different mirror, I got 2.11.0.
Now I can't get 2.11.0-1. I tried over 20 mirrors and none of them have the 
update.

Tom L


--
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: Regression in Cygwin 2.11.0-1

[Corinna Vinschen]

On Sep  1 16:41, David Allsopp wrote:
> Corinna Vinschen wrote:
> > Some of the path handling is seriously crippled as soon as you start using
> > backslashes, and that's a delipberate decision and won't change, even after
> > fixing the aforementioned bug.
> 
> I don't quite follow this - does that mean that that path definitely
> work even with a new Cygwin? i.e. our existing build system is
> permanently broken for Cygwin 2.11+?

No.  The problem we're talking about here is a regression and needs
fixing, no doubt about it.

I was just saying that win32 paths *in general* get a less complete
treatment than POSIX paths for hopefully obvious reasons.  Just be
aware that \foo\bar is not the same as /foo/bar and may even point
to another file.

As for the bug in question:  I pushed a patch which should fix this
issue.  I created new developer snapshots and uploaded them to
https://cygwin.com/snapshots/.  Please give them a try.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Bug Report: Regression in Cygwin 2.11.0-1

[Corinna Vinschen]

On Sep  1 20:08, Houder wrote:
> On Sat, 1 Sep 2018 17:54:35, Corinna Vinschen wrote:
> > I'll fix this and release a 2.11.1 soon, but I still have a question:
> > 
> > Why do I push out test releases if nobody cares?
> 
> Yes, I know, it is a _hypothetical_question_. You do not really expect
> an answer.
> 
> However it was my thought exactly. Nobody? I like to think that those
> that were responsible for patches, have tested their modifications.
> 
> I did.
> 
> On the other hand, those that will find problems, the people building
> packages, will only do that on "official" releases.
> 
> I am almost sure of that :-)
> 
> Unless you like creating test releases, releasing only one before you
> push an "official" one, would be more efficient, I imagine.
> 
> Yes, you would run the chance that you would have to mend an official
> release several times ... but is that bad?

The idea of test releases is to avoid problem like the one we're discussing
here in official releases.  I'd like to get an official release out and
then go on vacation :)


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Cygwin fails to utilize Unicode replacement character

[Corinna Vinschen]

On Sep  1 09:13, Steven Penny wrote:
> 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).

I changed it in Cygwin for the console window.  For mintty this would
have to be changed in mintty itself.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Bug Report: Regression in Cygwin 2.11.0-1

[Bryan Phelps]

> As for the bug in question:  I pushed a patch which should fix this 
> issue.  I created new developer snapshots and uploaded them to 
> https://cygwin.com/snapshots/.  Please give them a try. 

Thank you Corinna for the quick fix and investigation!

I set up an environment to test it out: 
https://github.com/bryphe/test-ocaml-build and ran a build against the patched 
dll.
It looks like the patch fixes our scenario - the build is green with the 
patched dll: https://ci.appveyor.com/project/bryphe/test-ocaml-build, so the 
patch fixes our problem.

> On the other hand, those that will find problems, the people building
packages, will only do that on "official" releases.

I'm pretty new to the Cygwin ecosystem - we could certainly create nightly 
builds that test against cygwin releases, if that helps (and adjust our CLI 
script to grab the nightly / latest test release of Cygwin).

I wonder if, for a change like this, we could add a test case that exercises it 
- looking through the source, it looks like cygload.cc has a few test cases 
around pathing - perhaps it would be helpful to add a regression test for the 
minimal repro?

Thanks again for the help and investigation!
Bryan
--
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

[Thomas Wolff]

Am 01.09.2018 um 20:46 schrieb 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?


...

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


   $ pwsh -c '[system.text.encoding]::UTF8.getString(0xEB)'
   �
What makes you claim this would be the "correct output"? Where is this 
defined?



compare again with Cygwin:

   $ printf '\xEB'
   ▒

Actually, in mintty, this is not (anymore) the MEDIUM SHADE. Please compare.
There's also a problem with using MEDIUM SHADE. In an ambiguous-width 
locale (or explicit ambiguous-width terminal mode), that character has 
double-width and is therefore not suitable as a replacement for a single 
illegal UTF-8 byte.
Cygwin console does not support double-width so it does not have this 
problem, but until further clarification I think I'll not change it in 
mintty.

Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
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: Regression in Cygwin 2.11.0-1

[Houder]

On Sat, 1 Sep 2018 21:23:56, Corinna Vinschen wrote:
> > Yes, you would run the chance that you would have to mend an official
> > release several times ... but is that bad?
> 
> The idea of test releases is to avoid problem like the one we're discussing
> here in official releases.  I'd like to get an official release out and
> then go on vacation :)

Now you know it does not work that way :-) ... I would say: "Just go!" Happy
holidays.

Henri


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

[Doug Henderson]

On Sat, 1 Sep 2018 at 10:13, Steven Penny  wrote:
...
> You get this result with Linux:
>
> $ cat alfa.txt
> �
...
> with Cygwin you get this:
>
> $ cat alfa.txt
> ▒
...
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.

So, IMHO, to provide a similar visual, across all fonts and terminals,
these programs need to display a glyph common to all, such as the
Medium Shade.

HTH,
Doug

BTW, in my Debian 9.5 VM, the Replacement Character is displayed. The
Characters app shows that the default font contains the Replacement
Character, and that is what is displayed in the terminal.
-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com

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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.11.0-1

[Ken Brown]

On 9/1/2018 2:52 PM, tl...@twcny.rr.com wrote:

Now I can't get 2.11.0-1. I tried over 20 mirrors and none of them have the 
update.


Are you sure you don't have it already?  Try 'cygcheck -cd cygwin' to 
find out:


$ cygcheck -cd cygwin
Cygwin Package Information
Package  Version
cygwin   2.11.0-1

Ken

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

Re: Bug Report: Regression in Cygwin 2.11.0-1

[Andrey Repin]

Greetings, David Allsopp!

>> In terms of this OCAML build system problem:
>> 
>> Please fix your build system.  Do not mix POSIX and Win32 paths, use POSIX
>> paths only.  Backslashes are *no* drop-in replacement for slashes.

> The "problem" for us is more subtle than this. The program which is
> generating that path is not a Cygwin executable, so it is correctly
> combining a path it has been supplied (the ../stdlib which has been supplied
> via Cygwin's make) with a filename, so it uses a backslash. It's been on my
> TODO for years to enhance to understand that the program it's supplying the
> path back to is a Cygwin executable and so sort it out properly but, well,
> we're a small number of maintainers! That said, WSL is forcing us to address 
> it properly...

You CAN just send back forward slashes. Windows don't care.
If any program would choke, it would be that program's problem after all.


-- 
With best regards,
Andrey Repin
Sunday, September 2, 2018 0:51:18

Sorry for my terrible english...


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

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

Advice on setting Cygwin build parameters for OpenSC.

[Darren Whobrey]

Hi,
I’ve been talking to Doug Engert, one of the maintainers for the OpenSC 
project, and we could do with some advice on how best to set the build 
parameters for building OpenSC via Cygwin.

The good news is that with a small tweak to the current stock configure.ac, 
OpenSC builds nicely and works well on Cygwin – which is great because it 
enables a heap of SmartCard and Yubikey applications to work too, like ssh.

The tweak required to get OpenSC to work with the standard Cygwin utils, like 
ssh-agent, is to comment out a line in the configure.ac script that previously 
was causing it to force a WND build, which resulted in struct packing of 1 – 
and that doesn’t work with the ssh utils distributed with Cygwin. For details 
see the end of thread here: https://github.com/OpenSC/OpenSC/issues/607.

The question is, what is the most sensible way to update the configure.ac and 
still support other Cygwin users that may be using mingw or other toolchains 
rather than gcc? It seems that the default should be to not include the 
offending line, but then that would break WND builds. So maybe the configure.ac 
script should have another case block for WND builds? This aspect is stretching 
my knowledge and understanding of the implications, so would appreciate some 
advice 😊

Regards,
Darren.

Ps: if the Cygwin team could add OpenSC to it’s distributed binary packages 
that would be great too!


--
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: Regression in Cygwin 2.11.0-1

[cyg Simple]

On 9/1/2018 5:52 PM, Andrey Repin wrote:
> Greetings, David Allsopp!
> 
>>> In terms of this OCAML build system problem:
>>>
>>> Please fix your build system.  Do not mix POSIX and Win32 paths, use POSIX
>>> paths only.  Backslashes are *no* drop-in replacement for slashes.
> 
>> The "problem" for us is more subtle than this. The program which is
>> generating that path is not a Cygwin executable, so it is correctly
>> combining a path it has been supplied (the ../stdlib which has been supplied
>> via Cygwin's make) with a filename, so it uses a backslash. It's been on my
>> TODO for years to enhance to understand that the program it's supplying the
>> path back to is a Cygwin executable and so sort it out properly but, well,
>> we're a small number of maintainers! That said, WSL is forcing us to address 
>> it properly...
> 
> You CAN just send back forward slashes. Windows don't care.
> If any program would choke, it would be that program's problem after all.

Certainly not "that program's problem". The problem becomes mine and
yours as we've not followed the design of the program.  While Windows at
the moment doesn't care there is always the possibility that some fix
could break that since the documentation states to use \ in paths and
not /.  So while we "CAN just send back forward slashes" we need to be
prepared for the outcome if something changes in an update to the OS and
breaks the assumptions based on observed behavior rather than the
documented behavior.

-- 
cyg Simple

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