I did not get any response to my last questions, so I hope this patch is 
enough.

Any thought about my other arguments?

Federico

On 5/17/20 7:54 PM, Federico Kircheis wrote:
> 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.
>