Jon Turney via Cygwin-apps writes: >> Exchange the while loop using an iffy read construct to a for loop using a >> temporary file. > > I think this change from zero-delimited to whitespace means this will > now fail to handle any filenames containing whitespace correctly?
Yes, sorry. I thought whitespace in filenames wasn't working anyway, but at least here it was done correctly. > This commentary doesn't clearly identify what is wrong with the usage > of read here. The read itself was OK, piping the data from find into the read wasn't. I've replaced this with a process substitution and thus reinstated the whitespace protection without getting into subshell trouble. >> avoid filename collisions by using an >> SHA256 hash of the full file name. > > I think there is already a perfectly good, filesystem safe, > computationally cheap unique identifier for each filename, which is > it's ordinal number in the list of filenames we are examining. I've implemented a counter now. However I don't see the hashing of a filename as onerous when Git does that much more often and on much larger data. > 'wait -f' seems to be new in bash 5.0. I assume this fails horribly > on earlier bash versions. I'm ok with requiring that, but maybe we > should check the bash version? It should indeed be possible to drop the -f as long as job control is not enabled if I understand the manual correctly after re-reading it several times. I've done that and it looks like things still work. > On the plus side, the testsuite passes! :) Oh goody! Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
