Repository navigation
Env.exePath returns "/memfd:roc_file_descriptor (deleted)" when running as script #265
Description
Minimal Reproducible Example:
app [main] {
pf: platform "https://github.com/roc-lang/basic-cli/releases/download/0.16.0/O00IPk-Krg_diNS2dVWlI0ZQP794Vctxzv0ha96mK0E.tar.br",
}
import pf.Env
import pf.Path
main =
exePath = Env.exePath!
exePathStr = Path.display exePath
dbg exePathStr
Task.ok {}
Run as roc test.roc
Expected Behavior:
Output of /home/user/path/to/script/test.roc
Actual Behavior:
Output of /memfd:roc_file_descriptor (deleted)
Environment:
OS: Archlinux
Roc Version: roc nightly pre-release, built from commit 06996d8
Context
Discussed in https://roc.zulipchat.com/#narrow/channel/231634-beginners/topic/basic-cli.20debugging.20Env.2EexePath
Implementation (
basic-cli/crates/roc_host/src/lib.rs
Line 432 in 918c1dc
std::env::current_exe() (https://github.com/rust-lang/rust/blob/a8e75c53d0036b5d012cbc0ee5de17f8991fe60c/library/std/src/sys/pal/unix/os.rs#L406) which reads /proc/self/exe which seems to be invalid when running through roc <file>.
Somewhat related is roc-lang/roc#7172 which fixed argv[0] to be set correctly.
Proposed solution is to use argv[0] and ideally combine with Env.cwd for a full absolute path (similar to https://github.com/rust-lang/rust/blob/a8e75c53d0036b5d012cbc0ee5de17f8991fe60c/library/std/src/sys/pal/unix/os.rs#L253) if /proc/self/exe can't be utilized.
Credit to @jwoudenberg and @lukewilliamboswell who did most of the work of putting this information together.
Activity
lukewilliamboswell commentedon Jul 22, 2026
Agent review note: I’m an OpenAI Codex Agent tasked to review the open
basic-cliissues in support of the major upgrade to the new Zig-based Roc compiler.Recommendation: Transfer to
roc-lang/rocand close here. On the current compiler, script mode no longer returns/memfd:... (deleted), but it does return the compiler's temporary executable path rather than the source path.basic-clionly callsstd::env::current_exe()and cannot recover the originating.rocfile; the Roc CLI would need to expose that distinction.lukewilliamboswell commentedon Jul 22, 2026
Follow-up Agent investigation: I reproduced the underlying behavior on current
roc-lang/rocmain(08cc24a16c) and opened the upstream regression as:roc runargv[0] from source path to temporary executable path roc#10307The important distinction is:
Env.exe_path!calls the OS equivalent ofcurrent_exe(). Duringroc app.roc, the process really is a compiler-generated temporary executable, so returning that executable path is internally consistent with the API name.argv[0]. Roc PR #7172 deliberately established that behavior so scripts could locate resources relative to their.rocfile.argv[0]. A normalroc buildoutput correctly receives its launched binary path.Updated recommendation: keep this as a tracking issue blocked on roc-lang/roc#10307. Once upstream restores the source path in
argv[0], basic-cli applications can obtain their direct-run script identity from the first argument.Env.exe_path!should remain documented as the path of the executable actually running rather than being overloaded with source-file semantics.