Re: cygport development

[Federico Kircheis <federico.kircheis@gmail.com>]

Thank you for the feedback.

> 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. 

Could you please point me to which variables are unrelated to files.

AFAIK i quoted files and arguments, which can all contain whitespace.

For example I did quote ${unpack_file_path}, but not ${unpack_cmd}.

> 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. 

The first commit makes sure that no information is lost while processing 
file with spaces or other characters that cause globbing. This prevents 
writing or modifying the wrong files, which is what happened to me.

The second commit add exit in case `cd` fails, which prevents other 
errors afterwards.

Those modification do not add support for path with whitespace, as I was 
still unable to compile the software, they did however prevent cygport 
to delete unrelated data (or create data in the wrong location).


> 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.

Also because if the underlying tool like `make` does not support spaces, 
it has no benefit.

The most minimal patch I can imagine is exiting if `cd` fails (just the 
second commit).
Would you accept that?
But please also consider my other arguments.

> Yaakov

PS:

A "nice" side-effect to quoting most variables that could contain white 
space is that static-analyzers like shellcheck will emit less 
diagnostic, making it easier to discover potential errors.