Open novafacing opened 10 months ago
Override the behavior of these functions somehow to return the path to the script. std::env::current_exe has a note that it may return the path of a symbolic link instead of a target of a symbolic link, or other platform specific behavior. T
The main issue with this is I don't think there is a way to do it in a cross-platform way. For unix-like systems, we have CommandExt::arg0
but I don't think there is an equivalent for Windows.
For unix-like systems, we have
CommandExt::arg0
but I don't think there is an equivalent for Windows.
There could be, there's just not std function for it atm. However, current_exe
gets the "real" application path and doesn't use the arguments passed to the program.
Potentially related, remark by @epage.
We have CARGO_MANIFEST_DIR
, I wonder if a way to resolve this would be to add CARGO_MANIFEST_PATH
. It wouldn't be arg0
and it wouldn't be accessible if people directly run the binary but it would still make the original script accessible to the developer.
I like the idea, it really seems like if you're directly running the binary with Zscript
you're doing it wrong, and the added simplicity of being able to env!("CARGO_MANIFEST_PATH")
in the script would be pretty ergonomic.
sh: Relative shell script includes with realpath on FreeBSD, 2 are potentially related.
Problem
std::env::args
andstd::env::current_exe
return potentially confusing results when running cargo scripts with the-Zscript
unstable feature. While ostensibly correct, returning the actual built executable path is generally less useful to scripts than returning the path to the cargo script file, and leads to antipatterns like usingcurrent_dir().join(SCRIPT_NAME)
to find the script file. Running the executable from the containing directory and havingcurrent_dir()
not be a prefix ofcurrent_exe()
adds another layer of complexity.Proposed Solution
It seems there are ~3 possible ways to go about this:
std::env::current_exe
has a note that it may return the path of a symbolic link instead of a target of a symbolic link, or other platform specific behavior. Treating the script file as a symbolic link-equivalent whose path is returned instead of the actual executable using this escape hatch is the route I'd personally like best.Notes
Related to #3502 and #12207.