RE: Bug Report: Regression in Cygwin 2.11.0-1
cyg Simple wrote: > 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. That's not strictly true, as mkdir foo/bar will demonstrate in a command prompt (it is almost true when dealing with the Windows API). However, IMO, one looks like a Unix programmer who doesn't really understand Windows when your programs visibly use forward slashes everywhere. > > 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. Just as an aside, the use of slashes is documented: see Kuhne's compulsory reading on the subject at https://blogs.msdn.microsoft.com/jeremykuhne/2016/04/21/path-normalization/ and also the notes in MSDN (https://docs.microsoft.com/en-gb/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation) which do mention that normalisation of / to \ in the API is not an accident. 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: Cygwin fails to utilize Unicode replacement character
Am 02.09.2018 um 00:49 schrieb 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. 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? 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
Corinna Vinschen wrote: > 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! That snapshot does indeed fix our build. How feasible would it be to generate an alternate setup.ini (setup-snapshots.ini or something) and include the snapshots in the actual mirror with a switch to setup to select the alternate file? When we finally get to it with OCaml's CI, that is probably how I would configure our CI to operate (i.e. synchronise with a mirror, download the latest snapshot and then patch setup.ini), but I imagine there might be other projects which would set jobs running if it were very simple from upstream to do. David
Re: Advice on setting Cygwin build parameters for OpenSC.
Am 02.09.2018 um 03:22 schrieb Darren Whobrey:
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.
That line is flat-out wrong. Delete it. You're already in a
--host=*cygwin* specific section of your configure.ac script, so there's
no further precautions to be taken.
While at it, you may just as well delete the entire "with_cygwin_native"
branch (lines 100..105), because that has been un-applicable for years.
Building for native windows (i.e. MinGW) is has long since stopped to
be done by a -mno-cygwin flag. Instead you would pass the configure
script a --host={something with mingw in it} flag to initiate a proper
cross-build, and that will bring you into the existing --host=*mingw*
case abvoe.
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?
Checking for GCC is almost certainly a red herring here.
should be to not include the offending line, but then that would
break WND builds.
Not really, because whatever you mean by "WND builds", they won't be
ending up in that cygwin 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
RE: [ANNOUNCEMENT] Updated: Cygwin 2.11.0-1
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 Sure enough! That's what I have. I thought that since I installed Cygwin before the announcement that I would've had an earlier build. Thanks, Ken! I'm learning something new about Cygwin every day. Eventually, I may become almost competent. Now if only I could figure out how to compile a C program in Win 10 without a segmentation error... 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: problem with Windows 8.1 on-screen keyboard (tablet) and Alt-Gr-Keys in mintty
[cleaning up my mailbox I found this 3-years old but ananswered issue] Am 01.06.2015 um 16:59 schrieb Richard Czech: On a tablet running Windows 8.1pro I installed Cygwin 2.0.0 /64. Unfortunately I have issues using the on-screen (virtual) keyboard with Alt-Gr keys from within mintty. Example: In Germany to get to the "@" character you have to press [Alt-Gr][q]. This, however, doesn't work in mintty using the on-screen keyboard. Instead of @ it produces the sequence [ESC][CTL-Q]. When I start bash from a Windows CMD terminal the "@" using [Alt-Gr][q] works nicely. It also works when I use a real keyboad connected through USB. The problem only exists when using a mintty window and the on-screen keyboard. Does anybody have any advice? The cause is the buggy on-screen keyboard which does not respect Windows's own rules of how to encode AltGr. Mintty 2.8.0 added a workaround for 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: Cygwin fails to utilize Unicode replacement character
On Sun, 2 Sep 2018 10:07:10, Thomas Wolff wrote: Actually, the width problem I suggested in my other response (and even referring to the wrong character) does not apply as mintty enforces proper width in that case. Also, even with fonts that do not provide the glyph, you will usually still see 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
WARNING: Couldn't compute FAST_CWD pointer
242 [main] bash 11160 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com my console shows this, I hope you can help me -- Regards, Christine Polly Paul -- 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
