Stream: platform development

Topic: getting args when using `roc run`?


view this post on Zulip Jasper Woudenberg (Oct 17 2024 at 21:45):

I'm trying out writing a little platform. It's designed to be primarily ran by using a roc shebang, which I think is equivalent to using roc run. I noticed though that when I do, the argslist of my process contains just /proc/self/fd/3. Is there a way to the host can get the original args list? I'd like to get get the location of script being run so I can do file lookups relative to it, among other things.

I'm on Linux using the surgical linker. The platform I'm writing is in Zig, but I don't think it's anything to do with my code, when I print args using basic-cli I see the same behavior. This happens both when I run the script using roc run and when I invoke a script directly with #!/usr/bin/env roc at the top.

view this post on Zulip Brendan Hansknecht (Oct 17 2024 at 22:34):

probably requires compiler modification, but it would be great to do so

view this post on Zulip Jasper Woudenberg (Oct 18 2024 at 16:14):

Thanks!

My original statement was incorrect, I do see the args, it's just that argv[0] is /proc/self/fd/3. I think that might be unavoidable given Roc has to exec into the binary it compiles first when doing a roc run. At least, I can't avoid this when doing some experiments with shell scripts exec-ing to each other. But I think we could expose the original script file to the host by putting it in an env variable, maybe ROC_SCRIPT. I'll try it out and make a PR.

view this post on Zulip Brendan Hansknecht (Oct 18 2024 at 16:30):

hmm...yeah

view this post on Zulip Brendan Hansknecht (Oct 18 2024 at 16:30):

Maybe fexecve could work around it. Not sure where it gets the name from.

view this post on Zulip Jasper Woudenberg (Oct 18 2024 at 17:17):

Ohhh, I'm wrong, you can specify argv[0] separate from what program you want to run!

view this post on Zulip Brendan Hansknecht (Oct 18 2024 at 17:17):

Oh, awesome!

view this post on Zulip Brendan Hansknecht (Oct 18 2024 at 17:18):

We should change it to be the name of the roc file passed to roc run.

view this post on Zulip Jasper Woudenberg (Oct 18 2024 at 17:28):

Yes! Taking a look.

view this post on Zulip Jasper Woudenberg (Oct 18 2024 at 18:29):

PR: https://github.com/roc-lang/roc/pull/7172

view this post on Zulip Sam Mohr (Oct 21 2024 at 19:36):

A comment I made on the PR that probably warrants discussion:

From the added tests, it looks like a script in /home/myuser/Documents/myscript.roc would have the relative path included along with the name, but I think we should prefer just the file_name (a.k.a. myscript.roc) since that's what will be wanted to display 99% of the time.

view this post on Zulip Jasper Woudenberg (Oct 21 2024 at 19:43):

Thanks for taking a look at the PR! I responded to your comment:

I think the relative name is important if we want to use argv[0] to look up the script location in the application.

For instance, if I'm in /home/jasper and run: roc ./projects/foobar/main.roc, if argv[0] only tells me I'm running main.roc, then in the implementation of main.roc I can't know where the script is located, for instance to read some data.json file that's supposed to be next to the script file.

Bash works the same way btw! Try put this script somewhere:

bash #!/usr/bin/env bash echo "$0"

And run it from a couple different places to observe the result.

view this post on Zulip Brendan Hansknecht (Oct 21 2024 at 22:25):

Yeah, I think it needs to match what is passed to roc. Akin to what would be passed to bash

view this post on Zulip Brendan Hansknecht (Oct 21 2024 at 22:34):

We could remove the .roc extension from it, but I think it is better taste to leave it in


Last updated: Jul 06 2025 at 12:14 UTC