On Tue, 2020-05-12 at 16:59 +0200, Federico Kircheis wrote: > On 10/14/19 10:55 AM, Federico Kircheis wrote: > > On 13/10/2019 18.41, Achim Gratz wrote: > > > Federico Kircheis writes: > > > > I've sent the patches the 14.07.19, unfortunately I still got no answer. > > > > > > The cygport maintainer is rather busy with non-Cygwin related work these > > > days, I suppose. Anyway, one of the questions I have is why you need > > > these changes. Most build systems do not actually work when they > > > encounter a path with spaces if they use make under the hood, so fixing > > > cygport to grok such path locations isn't getting you much further I'd > > > think. Can you explain? > > > > Yep. > > > > I've built some software in my windows home directory. > > It contains a space. > > I expected it to work. > > > > Instead of failing with a clear error message, the build process deleted > > some unrelated files as it cd failed (or cd in the wrong directory, cant > > remember right now). > > > > I believe it is unacceptable to delete unrelated data. > > > > Even if it stated that there is no intention to support path with > > spaces, those scripts should fail fast and ideally with a clear error > > message. > > > > I found it easier to quote the offending variables, as not only spaces > > might cause issues. > > The merge request in the repository has been closed. > > I'm attaching the updated patch.
This patch is clearly not limited to the protection of data, as it quotes variables that could in no way contain a space or have anything to do with file paths. As mentioned multiple times, using filenames ore directories with spaces is asking for trouble, and I have no interest in trying to support such a case. I'm willing to consider a *limited* patch that makes sure that cygport doesn't do something it shouldn't in that case, but that's about it. -- Yaakov
