Fri May 15 04:55:44 GMT 2020
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.
More information about the Cygwin-apps