Tests fail if directory contains special characters

[nikic]

Problem

If the directory where cargo is checked out contains a special character like ~, then many tests fail. See https://gist.github.com/nikic/97fab137a6d02c33cf8df9cf56a17cd7 for a full list of failures (a handful are unrelated, but most are due to the directory name).

Part of the issue seems to be that the [..] wildcard doesn't match ~. This is probably easy to fix.

The other part of the problem is that the special character introduces quoting in rustc options, so something might expect -C incremental=... but get -C 'incremental=...' instead.

Steps

mkdir foo~bar && cd foo~bar
git clone https://github.com/rust-lang/cargo.git && cd cargo
cargo test --release

Possible Solution(s)

No response

Notes

No response

Version

No response

[nikic]

I was wondering why there are more failures now than in my original case -- it turns out I picked an extra unlucky directory name when submitting this issue! [..] does match ~ just fine, but the problem is that many tests use /foo and the way the wildcards are matched is pretty naive, so having /foo part of the path will break those tests because the wildcard [..] is matched to a too small substring.

If I use a different directory dir~name instead, then the list of failures is smaller: https://gist.github.com/nikic/f9742a594959d8db30e3002f2e87b08b The remaining failures all look related to the command-line quoting issue.

[epage]

So to summarize there are two issues

• Special characters, like ~ cause quoting, which our snapshots are not agnostic of
  • I don't see a good way for us to handle this without making the developer workflow worse and wonder if there is reason enough for this to matter or if we should reject addressing this
• Having a parent directory of foo* causes confusing with how the matching works.
  • We are swapping testing libraries in Port from bespoke assertions of snapbox #14039 and I wonder if this is neutral or improves the situation

[nikic]

I don't see a good way for us to handle this without making the developer workflow worse and wonder if there is reason enough for this to matter or if we should reject addressing this

Yeah, this seems tricky to fix -- the best idea I have is to add more output normalization and convert the quoted to the unquoted form, but that comes with its own risks.

My original reason for submitting this issue has been resolved on our side (by rpm-software-management/rpm#3160), so I'm fine with this just being "won't fix".

[epage]

Without someone being blocked on this, I don't see a reason to put in the investment to find a way to resolve this.