$ touch "$(printf 안녕하세요 | iconv -t cp949)"
$ ls
''$'\276''ȳ'$'\347\307''ϼ'$'\274\277\344'
$ trashy --version
trashy 2.0.0
$ RUST_BACKTRACE=1 trashy put *
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/trash-2.1.5/src/freedesktop.rs:406:31
stack backtrace:
0: rust_begin_unwind
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
1: core::panicking::panic_fmt
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
2: core::panicking::panic
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:48:5
3: trash::platform::move_to_trash
4: trash::platform::<impl trash::TrashContext>::delete_all_canonicalized
5: trash::app::command::put::PutArgs::run
6: trash::app::command::Command::run
7: trash::app::Args::run
8: trash::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
This behavior seems fixed in trash v5:
Support non-Unicode paths
There are several spots where paths are assumed to be Unicode. However,
some (all?) operating systems support non-Unicode paths which causes
trash-rs to panic if encountered. I switched some of those code to use
OsStrings instead of Strings. Unfortunately, I had to add a new
dependency, urlencoding, in order to properly handle decoding non-UTF8
byte slices.
This behavior seems fixed in
trash
v5:Related: https://github.com/Byron/trash-rs/issues/105