PathAliasing

The standard Mill (abs, alias) mappings (workspace -> ../mill-workspace, home -> ../mill-home) used by ensureProcessCwdAliases to install the ../mill-workspace / ../mill-home forwarder symlinks.

Install the mill-workspace / mill-home forwarder symlinks for a process whose cwd is cwd. The aliases live outside the cwd, normally in its parent. That keeps tools which walk/archive their own working directory (jar -c ., tar, os.walk) from seeing aliases while still letting subprocess cwd values resolve paths like ../mill-workspace/....

The exception is a subprocess spawned directly at the workspace root. In that case, the path relativizer needs aliases under the configured Mill output directory, so put the forwarders there instead of outside the workspace.

Create or update link to be a symlink pointing at dest. If link exists as a non-symlink, replace it. Best-effort: catches FileSystemException (e.g. read-only fs) and FileAlreadyExistsException (concurrent creation).

Scope body so the os.Path serializer is the default (env-driven) one. Used by long-running in-process tools whose own output should not inherit an outer caller's custom serializer.

Scope body so os-lib's ProcessBuilder inputs (cwd, stdout/stderr redirects) use real on-disk paths. Keep this narrow: ordinary user-facing path strings should go through PathRef.

Run body with an os.ProcessOps.spawnHook installed that ensures every subprocess's cwd has the ../mill-workspace/../mill-home aliases. Chains onto any existing hook so installations from outer scopes (e.g. EvaluatorImpl) still run.

The env vars a Mill subprocess needs to participate in path relativization: the workspace root (so it can locate out/), and the os-lib relativizer base (so its serialized paths round-trip through the same aliases the daemon uses).