Re: cygport development

[Yaakov Selkowitz <yselkowitz@cygwin.com>]

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