Exa cease to work with direnv custom use_nix


I’m facing an issue with exa (a replacement for ls written in Rust). It ceases to work when I use this configuration recommended on direnv wiki.

I can use exa in the folder as long as use_nix havn’t been called. Once called, it panics with the following backtrace :

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:1165:5
stack backtrace:
   0:     0x5648c82634e6 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd5cf01a6458823ce
   1:     0x5648c81daeed - core::fmt::write::h239984b34be80164
   2:     0x5648c8262856 - std::io::Write::write_fmt::h71b3597bde52e201
   3:     0x5648c8264887 - std::panicking::default_hook::{{closure}}::h22b55119be64c15e
   4:     0x5648c8264372 - std::panicking::rust_panic_with_hook::hc671c362d83d7750
   5:     0x5648c8263eee - std::panicking::continue_panic_fmt::h65e4009de34f6bc6
   6:     0x5648c82654a6 - rust_begin_unwind
   7:     0x5648c81de929 - core::panicking::panic_fmt::h40dcc4b041f86562
   8:     0x5648c81e35f6 - core::result::unwrap_failed::h94202cff87bbead0
   9:     0x5648c8231b11 - exa::fs::file::PlatformMetadata::check_supported::hee2bdc96186107f4
  10:     0x5648c81fd3a1 - exa::options::view::<impl exa::output::table::Options>::deduce::h471b0f333a1042ea
  11:     0x5648c820abad - exa::options::view::<impl exa::output::View>::deduce::ha44f06806c1d240e
  12:     0x5648c8207a36 - exa::Exa<W>::from_args::h68493b9a6d97480b
  13:     0x5648c820d6ab - exa::main::h04a2ec72b0380e31
  14:     0x5648c820c973 - std::rt::lang_start::{{closure}}::h367695a562a47c7b
zsh: abort (core dumped)  RUST_BACKTRACE=full exa -la

I’m not really sure if this is an issue with exa or just an issue with Mic92’s use_nix script.

Has anybody faced similar issue ?

It looks like that error occurs if TMPDIR points to a path that doesn’t exist. I’ll file an issue on exa itself (though development seems to have stalled), but I think the quick fix is to patch use_nix to ensure the TMPDIR exists.

Edit: Looks like the issue was already filed 6 days ago.

Thanks, I will watch this issue.

For now, I’ve added this to my dir_env script :

if [ -z "$TMPDIR" ] && [ "${TMPDIR+x}" = "x" ];  then
  mkdir -p ${pure_tmp}
  export TMPDIR=${pure_tmp}