main: fail gracefully when --config-file is missing or malformed

[VXNCXNX]

No issue is filed for this one, I found it while looking at something else.

What's broken

--config-file panics instead of failing cleanly:

$ lsd --config-file /nope/x.yaml
thread 'main' (1773578) panicked at src/main.rs:122:33:
Provided file path is invalid
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ echo $?
101

For a missing file nothing at all is printed before the panic, because from_file's error branch only calls print_error! when the io error is not NotFound. So the user gets a raw Rust panic and a backtrace prompt with no diagnostic.

A malformed file prints the diagnostic and then panics anyway:

$ printf 'display: bogus\n' > /tmp/c.yaml && lsd --config-file /tmp/c.yaml
lsd: Configuration file /tmp/c.yaml format error, display: unknown variant `bogus`, ...
thread 'main' panicked at src/main.rs:122:33: ...

The same malformed file at $XDG_CONFIG_HOME/lsd/config.yaml does not panic. It prints the error and falls back to defaults, so --config-file is the odd one out.

The cause

src/main.rs:122, Config::from_file(path).expect("Provided file path is invalid"). from_file returns Option and handles its own diagnostics, returning None by design. The .expect() turns that designed None into a panic. It came in with #1173.

The fix

Print an lsd: diagnostic and exit MajorIssue, matching the existing "cannot access file" exit status.

I put the message in main.rs rather than in from_file's error branch on purpose. from_file is shared with the XDG path, where a missing file is normal and must stay silent. One unconditional message at the explicit --config-file call site covers both failure causes in three lines and changes nothing else.

An explicitly passed path that is wrong should not fall back to defaults: someone who typos a path deserves to be told.

After:

$ lsd --config-file /nope/x.yaml
lsd: Can not use config file /nope/x.yaml.
$ echo $?
2

The malformed case now prints the specific parse error first, then the verdict.

Verification

cargo fmt --all -- --check clean, cargo build --release clean, unit tests 391 passed.

Two integration tests added, asserting non-zero exit, an lsd: prefixed stderr, and no panicked at. Reverting the source with the tests kept makes exactly those two fail.

Note for CI, neither caused by this change and both confirmed on a clean tree: test_date_custom_format_supports_nanos_with_length fails under a locale that formats decimals with a comma, and cargo clippy --tests -- -D warnings reports 7 errors in src/color.rs, src/display.rs and src/meta/name.rs from lints newer than the pinned toolchain.

---

TODO

• Use cargo fmt (cargo fmt --all -- --check clean)
• Add necessary tests (two integration tests in tests/integration.rs)
• Update README (if applicable) (not applicable: the README does not document the panic, and the new behaviour is the ordinary error path)
• Update config sample file in doc/samples (if applicable) (not applicable: no config key is added or changed)
• Update icon sample file in doc/samples (if applicable) (not applicable: no icon change)
• Update color sample file in doc/samples (if applicable) (not applicable: no color change)
• Update man page at lsd/doc/lsd.md (if applicable) (not applicable: the man page documents --config-file but not its failure behaviour)

Disclosure: written with AI assistance (Claude Code). I reproduced the issue, ran the change and the verification myself.