running a binary relative to a setCwd broken on latest master

[bernardassan]

Zig Version

0.15.0-dev.4320+850655f06

Steps to Reproduce and Observed Behavior

1. mkdir -p run && cd run
2. zig init
3. Remove the line b.installArtifact(exe);
4. Add run_cmd.setCwd(exe.getEmittedBin().dirname()); after const run_cmd = b.addRunArtifact(exe);

✗  zig-master build run --verbose
/home/ultracode/repos/oss/ziglang/build/stage3/bin/zig build-exe -ODebug --dep run -Mroot=/home/ultracode/repos/zig/run/src/main.zig -Mrun=/home/ultracode/repos/zig/run/src/root.zig --cache-dir .zig-cache --global-cache-dir /home/ultracode/.cache/zig --name run --zig-lib-dir /home/ultracode/repos/oss/ziglang/lib/ --listen=-
cd .zig-cache/o/54874185f9c4cfb23fa4660bb88399c3 && run
run
└─ run run failure
error: failed to spawn and capture stdio from run: FileNotFound
Build Summary: 2/4 steps succeeded; 1 failed
run transitive failure
└─ run run failure
error: the following build command failed with exit code 1:

Expected Behavior

/home/ultracode/.local/zig/zig-x86_64-linux-0.14.1/zig build-exe -ODebug --dep run -Mroot=/home/ultracode/repos/zig/run/src/main.zig -Mrun=/home/ultracode/repos/zig/run/src/root.zig --cache-dir /home/ultracode/repos/zig/run/.zig-cache --global-cache-dir /home/ultracode/.cache/zig --name run --zig-lib-dir /home/ultracode/.local/zig/zig-x86_64-linux-0.14.1/lib/ --listen=-
cd /home/ultracode/repos/zig/run/.zig-cache/o/62b771049e0aa3130a39fd6ccf804311 && /home/ultracode/repos/zig/run/.zig-cache/o/62b771049e0aa3130a39fd6ccf804311/run
All your codebase are belong to us.
Run `zig build test` to run the tests.

This issue would be fixed if the executable is prepended with ./ on posix .ie ./run.

[alexrp]

cc @mlugg

[bernardassan]

@mlugg I have verified that the PR #24218 fixes this issue.

One clarification, now --cache-dir= is always a relative directory, right?

[mlugg]

Not necessarily. The current behavior is that it will be if you zig build in the same directory as build.zig without overriding the cache directory; but in general, it's incorrect to ever make assumptions whether these paths are relative or absolute.

[bernardassan]

The main reason I'm asking this is because I realized that with master the run command is

cd .zig-cache/o/e2c39f8c849ace533e126f48b80e5db5 && ./mtest3 --seed=0xefdbdb26 --cache-dir=.zig-cache --listen=-

on the actual project that I reproduced the issue from, but there is no .zig-cache in .zig-cache/o/e2c39f8c849ace533e126f48b80e5db5

While on 0.14.1 --cache-dir was

cd /home/ultracode/repos/zig/lmdb/.zig-cache/o/f5deef5b78e8dea68553003505a01e4c && /home/ultracode/repos/zig/lmdb/.zig-cache/o/f5deef5b78e8dea68553003505a01e4c/mtest5 --seed=0x219a3736 --cache-dir=/home/ultracode/repos/zig/lmdb/.zig-cache --listen=-

I'm not sure if the changes to the --cache-dir affects the caching behavior

[mlugg]

I can't comment on that without knowing how you're passing that --cache-dir option.

[bernardassan]

I'm not passing it explicitly, that's the --verbose output

[mlugg]

Oh, I see, that's a Zig test binary! Apologies for the confusion. That looks like a separate (but definitely related) bug; I'll look at it later today. I'm pretty sure I already know exactly why it's happening lol

[bernardassan]

😄 Thank you.