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.
