BUILD_PATH_PREFIX_MAP and handling of spaces in pathnames

[maroneze]

When running a Cram test with output sanitization, I'm getting un-sanitized outputs when the path contain spaces.

Reproduction

dune init proj p1
>p1/test/t1.t <<EOF
  $ export BUILD_PATH_PREFIX_MAP="FOO=\$(pwd)/bla:\$BUILD_PATH_PREFIX_MAP"
  $ echo \$(pwd)/bla
EOF
(cd p1 && dune runtest)

This usually outputs + $TESTCASE_ROOT/bla.

However, if I have a space somewhere in the project root path, the output is different:

mkdir "a b" && cd "a b"
dune init proj p1
>p1/test/t1.t <<EOF
  $ export BUILD_PATH_PREFIX_MAP="FOO=\$(pwd)/bla:\$BUILD_PATH_PREFIX_MAP"
  $ echo \$(pwd)/bla
EOF
(cd p1 && dune runtest)

The output is something like
+ /tmp/test/a b/p1/_build/.sandbox/825b2ab0686ee37e1c37dbf5f92932f6/default/test/bla

Expected Behavior

I expected output sanitization not to depend on whether the path containing the dune project has spaces.

Actual Behavior

No output sanitization when the path containing the dune project has spaces.

Specifications

• Version of dune (output of dune --version): 3.23.1
• Version of ocaml (output of ocamlc --version): 5.2.0
• Operating system (distribution and version): Fedora 42

Additional information

I accidentally typed dune init proj "a b" once, and it resulted in an "Internal error! Please report". I don't know if it's useful to create a different issue for it, but I don't have a need for it now. My main concern is that our Cram tests fail when the root project path contains spaces.

I've seen a few issues concerning the BUILD_PATH_PREFIX_MAP variable, but they seemed focused on other issues. I'm interested in knowing if this is a known limitation, or if there's already a workaround when defining BUILD_PATH_PREFIX_MAP.