exa -l --git fails in a directory with name 'P'$'\b\211''UUU' in git repository

[suyashmahar]

How to reproduce:

mkdir test
cd test
touch 'P'$'\b\211''UUU'
git init
exa -l --git

Stack trace:

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /home/smahar/.cargo/registry/src/github.com-1ecc6299db9ec823/exa-0.9.0/src/fs/feature/git.rs:204:51
stack backtrace:
   0:     0x5555555f0136 - backtrace::backtrace::libunwind::trace::h90669f559fb267f0
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1:     0x5555555f0136 - backtrace::backtrace::trace_unsynchronized::hffde4e353d8f2f9a
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2:     0x5555555f0136 - std::sys_common::backtrace::_print_fmt::heaf44068b7eaaa6a
                               at src/libstd/sys_common/backtrace.rs:77
   3:     0x5555555f0136 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h88671019cf081de2
                               at src/libstd/sys_common/backtrace.rs:59
   4:     0x55555556e7ac - core::fmt::write::h4e6a29ee6319c9fd
                               at src/libcore/fmt/mod.rs:1052
   5:     0x5555555ef9a6 - std::io::Write::write_fmt::hf06b1c86d898d7d6
                               at src/libstd/io/mod.rs:1426
   6:     0x5555555ef68b - std::sys_common::backtrace::_print::h404ff5f2b50cae09
                               at src/libstd/sys_common/backtrace.rs:62
   7:     0x5555555ef68b - std::sys_common::backtrace::print::hcc4377f1f882322e
                               at src/libstd/sys_common/backtrace.rs:49
   8:     0x5555555ef68b - std::panicking::default_hook::{{closure}}::hc172eff6f35b7f39
                               at src/libstd/panicking.rs:204
   9:     0x5555555ef00f - std::panicking::default_hook::h7a68887d113f8029
                               at src/libstd/panicking.rs:224
  10:     0x5555555ef00f - std::panicking::rust_panic_with_hook::hb7ad5693188bdb00
                               at src/libstd/panicking.rs:472
  11:     0x5555555eebea - rust_begin_unwind
                               at src/libstd/panicking.rs:380
  12:     0x55555556d1b0 - core::panicking::panic_fmt::hb1f3e14b86a3520c
                               at src/libcore/panicking.rs:85
  13:     0x55555556cfcc - core::panicking::panic::hcdc9f0ba8d71d265
                               at src/libcore/panicking.rs:52
  14:     0x5555555c9ae7 - exa::output::table::Table::display::h9b27bbcc64c93ced
  15:     0x5555555ade92 - <F as scoped_threadpool::FnBox>::call_box::h78fee085bf265f8f
  16:     0x5555555ea1e5 - std::sys_common::backtrace::__rust_begin_short_backtrace::h50f2ac2db0032be5
  17:     0x5555555e947c - core::ops::function::FnOnce::call_once{{vtable.shim}}::h12c9800e46c8a747
  18:     0x5555555f919e - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::he3e3bc9932f56404
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/liballoc/boxed.rs:1015
  19:     0x5555555f9e18 - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h0d82364c11057a62
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/liballoc/boxed.rs:1015
  20:     0x5555555f9e18 - std::sys_common::thread::start_thread::h6cf2238254b521b3
                               at src/libstd/sys_common/thread.rs:13
  21:     0x5555555f9e18 - std::sys::unix::thread::Thread::new::thread_start::he70a06005b4d03f8
                               at src/libstd/sys/unix/thread.rs:80
  22:     0x7ffff75946db - start_thread
  23:     0x7ffff70a5a3f - __clone
  24:                0x0 - <unknown>
[1]    8557 abort      RUST_BACKTRACE=full exa -l --git

Exa version: exa v0.9.0

[ogham]

Can confirm locally. exa can handle non-UTF8 filenames, but apparently the Git feature can't. Thanks for the report!

[suyashmahar]

@ogham Thank you for writing exa, great tool and glad to see that it is still being developed!

[ogham]

Thanks for saying so!

[mhogerheijde]

Hi, I think I have the same / similar error. Although my cause seems to be a bit different: it props up when there is a dangling symlink:

~/zandbak
➜ mkdir exa-example && cd exa-example

~/zandbak/exa-example
➜ git init
Initialised empty Git repository in /home/matthias/zandbak/exa-example/.git/

exa-example on  HEAD
➜ ln -s foo bar

exa-example on  HEAD [?]
➜ RUST_BACKTRACE=1 exa -l --git
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:1188:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /usr/src/rustc-1.41.0/vendor/backtrace/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /usr/src/rustc-1.41.0/vendor/backtrace/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:84
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1025
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:193
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:210
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:471
  11: rust_begin_unwind
             at src/libstd/panicking.rs:375
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:84
  13: core::result::unwrap_failed
             at src/libcore/result.rs:1188
  14: exa::fs::feature::git::reorient
  15: exa::fs::feature::git::Git::status
  16: exa::output::table::Table::display
  17: <F as scoped_threadpool::FnBox>::call_box
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fish: “RUST_BACKTRACE=1 exa -l --git” terminated by signal SIGABRT (Abort)

➜ RUST_BACKTRACE=1 exa -l
lrwxrwxrwx 3 matthias 12 mei  9:58 bar -> foo

Without git folder, everything works fine:

exa-example on  HEAD [?]
➜ rm -rf .git/

~/zandbak/exa-example
➜ RUST_BACKTRACE=1 exa -l --git
lrwxrwxrwx 3 matthias 12 mei  9:58 bar -> foo

[mhogerheijde]

My apologies, I was still on exa v0.9.0. I just updated to v0.10.1 and everything works fine!

Thanks for writing exa, I love it!

[ariasuni]

So this is fixed for Linux/macOS/other Unix OSes. I’m keeping this open because we will have Windows support, and we’ll need a fix for this platform as well.

[mazunki]

So this is fixed for Linux/macOS/other Unix OSes. I’m keeping this open because we will have Windows support, and we’ll need a fix for this platform as well.

Is converting the string to a "similar" ASCII format good enough? iconv library ascii:ToAsciiChar

Otherwise, perhaps using the std::u8.is_ascii() function to replace each broken character with a placeholder character is good enough?

The best solution would be if Windows actually added UTF-8 support to their terminal(s), but otherwise I think using iconv is the best solution.

[ariasuni]

I don’t have any idea and honestly, I believe we (well, I probably) should merge Windows support, then someone actually using Windows should write and test the thing, because I have literally no idea how Windows handles this.

[ariasuni]

exa is unmaintained (see https://github.com/ogham/exa/issues/1243), and an issue has been open for this in the active fork eza.

See https://github.com/eza-community/eza/issues/445.