RE: Bug Report: Regression in Cygwin 2.11.0-1
- Date: Sun, 2 Sep 2018 07:31:59 +0000
- From: David Allsopp <David.Allsopp@xxxxxxxxxxxx>
- Subject: 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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple