SZEDER Gábor <szeder.dev@xxxxxxxxx> writes: >>> +test_expect_failure 'complete files - quoted characters on cmdline' ' >>> + test_when_finished "rm -r \"New(Dir\"" && >> >> This does not use -rf unlike the previous one? > > Noted. > > The lack of '-f' is leftover from early versions of these tests, when I > had a hard time getting the quoting-escaping right. Without the '-f' > 'rm' errored out when I messed up, and the error message helpfully > contained the path it wasn't able to delete. Sounds like we do not want 'f' from both tests, then? I think it is OK either way. >>> +if test_have_prereq !MINGW && >>> + mkdir $'New\034Special\035Dir' 2>/dev/null && >>> + touch $'New\034Special\035Dir/New\036Special\037File' 2>/dev/null >> >> The $'...' quote is bash-ism, but this is about testing bash >> completion, so as long as we make sure non-bash shells won't touch >> this part of the test, it is OK. >> >> Do we want to test a more common case of a filename that is two >> words with SP in between, i.e. >> >> $ >'hello world' && git add hel<TAB> >> >> or is it known to work just fine without quoting/escaping (because >> the funny we care about is output from ls-files and SP is not special >> in its one-item-at-a-time-on-a-line output) and not worth checking? > > This particular case already works, even without this patch series. I was more wondering about preventing regressions---"it worked without this patch series, but now it is broken" is what I was worried about. > The problems start when you want to complete the filename after a space, > e.g. 'hello\ w<TAB', as discussed in detail in patch 5. Actually, this > was the first thing I tried to write a test for, but it didn't work out: > inside the 'test_completion' helper function the space acts as > separator, and the completion script then sees 'hello\' and 'w' as two > separate words. Hmph. That is somewhat unfortunate.
