Rick Hull (Jan 30 2026 at 16:29): Rick Hull (Jan 30 2026 at 16:29):I thought explicit subcommand run was still supported, just the default if not specified. was it removed entirely?
Richard Feldman (Jan 30 2026 at 17:40):yeah, that's intentional! I want to reserve run for potential future use, and also to have it so that roc foo.roc runs it just like how e.g. python foo.py does
Romain Lepert (Jan 30 2026 at 20:18):not sure python is a good comparison here. the python executable ONLY runs scripts, it does not have subcommands. In python land you have a thousand different tools for each purpose (python, pip, venv, pylint, etc.). It is changing now with uv/pixi but still.
roc run foo.roc seems the cleanest to me. But roc foo.roc can error with "Did you mean to roc run foo.roc ?"
If no subcommand matched, check if first arg looks like a path to a roc file.
It is really an mistake you may make the first few times anyway
Rick Hull (Jan 30 2026 at 20:36):somewhat inversely, I think there should be a "mandatory" subcommand, but it can default to the run subcommand, whatever shall it be named henceforth
Jasper Woudenberg (Jan 31 2026 at 12:43):One of the nice things about roc <path> running the file is that it makes for a really nice scripting excperience. You can put a #!/usr/bin/env roc shebang at the top of a file and then simply run the file itself like you would a python or bash script.
Romain Lepert (Feb 01 2026 at 08:46):What prevent it from being ´#!/usr/bin/env roc run’ ?
Luke Boswell (Feb 01 2026 at 08:47):I don't know.. but I wonder if that messes with adding cli args or something like that
Pei Yang Ching (Feb 01 2026 at 12:34):some platforms accept multiple arguments, some platforms accept a single argument, some platforms treat multiple arguments as a single one. In the third case (linux is here) you can split the args "manually" with #!/bin/env -S roc run --moreflags
as an alternative to roc file.roc you can install a separate program named "rocrun" which is just symlinked to the main roc binary, then in the program, check for the executable name argv[0] in C, and decide whether to treat the argument as a file or subcommand. that's what busybox does with ls, cat, etc.
Rick Hull (Feb 01 2026 at 14:52):or just having roc exec be the default subcommand if none provided (exec because run is being reserved for another purpose)
Richard Feldman (Feb 01 2026 at 15:22):yeah, initially it was roc run and then ran into the complexity around /bin/env not always accepting that
Richard Feldman (Feb 01 2026 at 15:24):we certainly could have roc default to roc run, but I think it's hard to make the case that if we already need the more concise way (roc foo.roc) for /bin/env, we should go out of our way to add a second, redundant way to do it that's more verbose (roc run foo.roc), so that now everyone needs to learn both, decide which to use, and then probably always use one and never use the other
Rick Hull (Feb 01 2026 at 15:25):I agree that it's not a necessary feature, and potentially confusing; however, it provides a clear mental model: roc <subcommand> (test, check, build, etc) and run or exec operates the same way. But we support run/exec as the default without being specified for #!/bin/env roc
Richard Feldman (Feb 01 2026 at 15:28):I'd like to continue not having it and see how it goes
Last updated: Feb 20 2026 at 12:27 UTC