cargo -Zscript doesn't work for memfd created files anymore

[crumblingstatue]

When the script file is created through memfd_create, cargo panics when trying to run the script.

Repro:

use std::os::fd::FromRawFd;
use std::io::Write;
use std::os::unix::process::CommandExt;

unsafe extern "C" {
    fn memfd_create(name: *const std::ffi::c_char, flags: std::ffi::c_uint) -> std::ffi::c_int;
}

fn main() {
    let fd = unsafe { memfd_create(c"otkeep-script".as_ptr(), 0) };
    if fd == -1 {
        panic!("memfd_create failed when trying to create script file");
    }
    let mut f = unsafe { std::fs::File::from_raw_fd(fd) };
    f.write_all(SCRIPT.as_bytes()).unwrap();
    f.flush().unwrap();
    dbg!(std::process::Command::new(format!("/proc/self/fd/{fd}")).exec());
}

const SCRIPT: &str = r#"#!/usr/bin/env -S cargo +nightly -Zscript

fn main() {
    println!("Hello World");
}
"#;

Cargo output (as of 1.92.0-nightly (81c3f77a4 2025-10-10)):

thread 'main' (26272) panicked at src/tools/cargo/src/cargo/core/workspace.rs:454:18:
template is correct: No such file or directory (os error 2)

My use case is that I'm running cargo scripts through my script runner called OtKeep, which stores scripts in a database and uses memfd_create to create temporary files when executing the scripts.

This used to work, but doesn't anymore. The regression seems to be caused by #16073.

[epage]

In #16073, we went from hashing the file path to hashing a canonicalized file path. That call was added as part of #15400 in response to #14125 (comment).

[epage]

Some quick thoughts:

• We say we don't support this, turning it into a proper error
• We unwrap_or(workspace_manifest_path) to support this case
• We revert Added symlink resolution for workspace-path-hash #15400

[crumblingstatue]

I'm not sure if you're implying that this is broken since April (when #15400 was merged), because that is not the case.
I can confirm this works with nightly-2025-10-11 (#!/usr/bin/env -S cargo +nightly-2025-10-11 -Zscript).
I can try doing a bisect tomorrow, but I'm heading to bed now.

[epage]

I'm not sure if you're implying that this is broken since April (when #15400 was merged), because that is not the case.

I am not. We had two parallel code paths. The second one added in #15400. #16073 merged those code paths. I was talking about what changes were caused by this merging of code paths that broke this.

[crumblingstatue]

• We say we don't support this, turning it into a proper error

My personal opinion is that unlike regular cargo projects, which must follow a set filesystem structure, cargo-script should be as flexible as possible, and not make many assumptions on how it's being executed.
It should be possible to run cargo script from a memfd created file if you can run regular shell scripts from memfd created files (which you can).

• We unwrap_or(workspace_manifest_path) to support this case

I would prefer this, if it doesn't break running the script itself. Although I'm personally not sure what workspaces have to do with cargo script, as you should be able to run a cargo script independent from any workspace, but I'm not familiar with the internal implementation details. Maybe it's just referring to a "virtual" workspace that's being created for the script.

[epage]

I would prefer this, if it doesn't break running the script itself. Although I'm personally not sure what workspaces have to do with cargo script, as you should be able to run a cargo script independent from any workspace, but I'm not familiar with the internal implementation details. Maybe it's just referring to a "virtual" workspace that's being created for the script.

From Cargo's perspective, every package is a part of a workspace though sometimes that workspace is implicit.

We use the workspace path to create a unique build-dir for a script which will house

• intermediate build artifacts
• Cargo.lock (special to cargo script)
• target/ (final artifacts; special to cargo script)

As a side note, depending on your situation, you may want to override the build-dir for these in-memory scripts to avoid thrashing Cargo.lock or the caches.

[crumblingstatue]

Ah, I understand now that defining CARGO_TARGET_DIR manually will skip the branch that's causing the panic.
So something like this is one potential workaround

#!/usr/bin/env -S CARGO_TARGET_DIR=/tmp/cargo-script-target cargo +nightly -Zscript

Although it would be nice if cargo could create a "fallback" target directory like this if it otherwise can't detect the workspace path.

If for whatever reason it's decided that not supporting this and erroring is the best option, then the error message should suggest that you can explicitly set the target dir with CARGO_TARGET_DIR to workaround this issue.

EDIT: This has problems, see below.

[crumblingstatue]

Actually, there is a big issue with the workaround I posted above.

If you want to invoke cargo inside your script (like your script involves building your project), cargo will (by default, unless you manually remove it¹) inherit the manually defined CARGO_TARGET_DIR, so if you try to build your project inside the script for example, then it will try to use the path defined in CARGO_TARGET_DIR instead of the actual target/ dir of your project.

So it doesn't actually seem like the optimal workaround that I initially thought it would be.

Footnotes

1. You can do so with Command::env_remove for example. ↩