I'm currently trying to figure out how to work with Env.exePath
. However when I try to log it it shows as memfd:roc_file_descriptor (deleted)
. Is this a bug?
My code:
cwd = Env.exePath!
cwdStr = Path.display cwd
dbg cwdStr
Oh interesting, if I run roc foo.roc
it creates a foo
application in the same folder but Env.exePath
is broken.
If I then run that created foo
application though it works as expected. Is there any way to get Env.exePath
working when running as roc foo.roc
?
roc foo.roc
runs the app from in memory. It really shouldn't actually create the foo
application in the local folder at all.
It is meant to work with roc as a scripting language
That said, roc should be overwriting that path such that the executable path is foo.roc
or whatever path is given to roc
I feel like someone recently was working on fixing that. Not sure the state though
Running it as a scripting only executable was kind of what I was expecting so I was surprised the application was created but I thought it just did a compile + run operation in the background.
Overwriting the path in script-mode run seems reasonable and would work for my use-case. Good that there is awareness of that. Do you know if there is a Github issue for it or something like that?
Is this the PR you're thinking of @Brendan Hansknecht https://github.com/roc-lang/roc/pull/7172
If that's the one that is only for args[0]
. I just checked an that is indeed the file I'd expect, although sadly not a full path.
It seems that fix has no impact on Env.exePath
though.
Here is the impl in the platform https://github.com/roc-lang/basic-cli/blob/918c1dcd2a863ea336e9fa0e70fa548f7107b6f0/crates/roc_host/src/lib.rs#L432
Is this the PR you're thinking of Brendan Hansknecht https://github.com/roc-lang/roc/pull/7172
Yes. Thanks for finding it
Scally said:
If that's the one that is only for
args[0]
. I just checked an that is indeed the file I'd expect, although sadly not a full path.
It seems that fix has no impact onEnv.exePath
though.
You should be able to join args[0]
onto the current working directory to get a full path. I do this in a different platform and it works. args[0]
is just the file you pass to roc run
, so if the person running the script passed a relative path, then args[0]
is a relative path.
It looks like the rust implementation of current_exe
for unix is here:
https://github.com/rust-lang/rust/blob/a8e75c53d0036b5d012cbc0ee5de17f8991fe60c/library/std/src/sys/pal/unix/os.rs#L253
They look in the args list as well, but then do extra work, first searching from the CWD
and then the PATH
. Not sure why that would fail :thinking:.
Did you change the current working directory prior to that code running?
Oh, nevermind, I was looking at the wrong OS. This is linux (don't know if that's the OS you're on), and it looks at /proc/self/exe
for current_exe
:
https://github.com/rust-lang/rust/blob/a8e75c53d0036b5d012cbc0ee5de17f8991fe60c/library/std/src/sys/pal/unix/os.rs#L406
I don't know if we can fake /proc/self/exe
in the Roc script runner to point to the Roc script rather than the compiler binary, my guess would be no. Maybe the platform shouldn't rely on Rust current_exe
and instead use argv0
, potentially implementing something like the cwd/PATH
search code I linked above that Rust falls back on for OS-es that don't support /proc/self/exe
.
Jasper Woudenberg said:
You should be able to join
args[0]
onto the current working directory to get a full path. I do this in a different platform and it works.args[0]
is just the file you pass toroc run
, so if the person running the script passed a relative path, thenargs[0]
is a relative path.
That was my plan now but would be nice if I could just use exePath.
What do you mean by changing the current working director prior to that code running?
I'm running roc from a parent directory (i.e. roc src/script.roc
) but inside the script are no changes in working directory.
Yes, I am indeed on linux
Jasper Woudenberg said:
I don't know if we can fake
/proc/self/exe
in the Roc script runner to point to the Roc script rather than the compiler binary, my guess would be no. Maybe the platform shouldn't rely on Rustcurrent_exe
and instead useargv0
, potentially implementing something like thecwd/PATH
search code I linked above that Rust falls back on for OS-es that don't support/proc/self/exe
.
That seems like a good solution if the /proc/self/exe
route indeed fails when running as a script.
:thumbs_up: Yep, I think it'd be a good issue to create on the basic-cli
repo. Happy to do it if you don't want to!
Can do
Issue link for reference https://github.com/roc-lang/basic-cli/issues/265
@Jasper Woudenberg do you intend to look at Issue in basic-cli?
Yeah, though in a couple of days as I've got a busy couple of days ahead!
Alg, just clarifying. No rush or anything
Last updated: Jul 05 2025 at 12:14 UTC