Summary

eza --time-style VALUE aborts (panic, exit 134) when VALUE is not valid UTF-8. The custom clap value parser unwraps the UTF-8 conversion of the raw OsStr argument, so a non-UTF-8 value makes to_str() return None and .unwrap() panics. It should return a usage error like every other eza flag.

Steps to reproduce

$ eza --time-style "$(printf '\xff\xfe')" .
thread 'main' panicked at src/options/parser.rs:297:55:
called `Option::unwrap()` on a `None` value
$ echo $?
134

Expected behavior

A non-UTF-8 --time-style value should be rejected with a graceful usage error (exit 2), not a panic.

Root cause

TimeFormatParser::parse_ref (the custom clap::builder::TypedValueParser) unwraps the UTF-8 conversion of the argument:

// src/options/parser.rs:296-300
fn parse_ref(&self, cmd: &clap::Command, _arg: Option<&clap::Arg>, value: &std::ffi::OsStr)
    -> Result<Self::Value, Error>
{
    match TimeFormat::try_from_str(value.to_str().unwrap()) {   // None for non-UTF-8 -> panic
        Err(s) => Err(Error::raw(clap::error::ErrorKind::InvalidValue, s).with_cmd(cmd)),
        Ok(v) => Ok(v),
    }

OsStr::to_str() returns None for a non-UTF-8 argument, so .unwrap() aborts.
The sibling env-var path (src/options/view.rs ~410) correctly uses to_str().unwrap_or(""); only this CLI parser panics. Fix: when to_str() is None, return a clap error (e.g. ErrorKind::InvalidUtf8) instead of unwrapping.

Environment

• eza 0.23.4 (commit 247fb8ed), rustc 1.90, Ubuntu 20.04 x86_64