What causes "Unable to parse {path}" in denisidoro/navi?

Ensure the path you pass contains only valid UTF-8 (sanitize or rename offending directories)

Unable to parse {path}

Error message

Unable to parse {path}

What it means

`fs::create_dir` wraps `create_dir_all` and builds a context message containing the path. Converting the path to a displayable string uses `pathbuf_to_string(...).expect(...)`, which panics with "Unable to parse {path}" when the path cannot be rendered (e.g. non-UTF-8 bytes in the path on Unix).

Source

Thrown at src/common/fs.rs:116

            if CONFIG.forward_slash_path() {
                exe.replace("\\", "/")
            } else {
                exe
            }
        })
        .unwrap_or_else(|_| "navi".to_string())
}

#[cfg(not(target_family = "windows"))]
pub fn exe_string() -> String {
    exe_abs_string().unwrap_or_else(|_| "navi".to_string())
}

pub fn create_dir<P: AsRef<Path>>(path: P) -> Result<()> {
    create_dir_all(path.as_ref()).with_context(|| {
        format!(
            "Failed to create directory `{}`",
            pathbuf_to_string(path).expect("Unable to parse {path}")
        )
    })
}

pub fn remove_dir<P: AsRef<Path>>(path: P) -> Result<()> {
    remove_dir_all(path.as_ref()).with_context(|| {
        format!(
            "Failed to remove directory `{}`",
            pathbuf_to_string(path).expect("Unable to parse {path}")
        )
    })
}

View on GitHub (pinned to f7330b9ad5)

Solutions

Ensure the path you pass contains only valid UTF-8 (sanitize or rename offending directories)
Fix the underlying directory-creation failure (permissions, existing file at path, full disk) so the panic closure never runs
Use `to_string_lossy()` instead of `expect` in library code to render non-UTF-8 paths safely
Inspect the path with `Path::display()` or debug formatting to find the offending bytes

Example fix

// before
pathbuf_to_string(path).expect("Unable to parse {path}")
// after
pathbuf_to_string(path).unwrap_or_else(|_| path.as_ref().display().to_string())

Defensive patterns

Strategy: validation

Validate before calling

fn ensure_utf8_path(p: &std::path::Path) -> Result<(), String> {
    p.to_str().ok_or_else(|| format!("path {:?} is not valid UTF-8", p)).map(|_| ())
}
// call before fs::create_dir
ensure_utf8_path(&my_path)?;

Type guard

fn is_utf8_path(p: &std::path::Path) -> bool {
    p.to_str().is_some()
}

Try / catch

// create_dir panics only when creation fails AND the path is non-UTF-8;
// wrap with catch_unwind if you must:
let result = std::panic::catch_unwind(|| fs::create_dir(&path));
match result {
    Ok(Ok(())) => {},
    _ => eprintln!("create_dir failed (check path encoding and permissions)"),
}

Prevention

Sanitize externally sourced paths to valid UTF-8 before filesystem calls
Prefer Path::display()/to_string_lossy when logging paths
Fix root causes of creation failure (permissions, disk space) so context closures never run
Reject non-UTF-8 filenames at ingestion boundaries

When it happens

Trigger: Calling `fs::create_dir` with a path whose OsStr contains invalid UTF-8 (so `to_str()` returns None) AND whose creation also fails, triggering the context closure that formats the message.

Common situations: Paths derived from file names with arbitrary bytes, bad encodings from external tools, or filesystems that allow non-UTF-8 names; usually combined with a permission/disk error that made `create_dir_all` fail in the first place.

Understand the failure class

Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

AI-assisted analysis of denisidoro/navi@f7330b9ad5 (2026-09-03). Data as JSON: /api/errors/58776436d199c41d. Report an issue: GitHub.