chmln/handlr

A better xdg-utils

handlr's Issues

Wildcards with get?

Readme says wildcards are supported, but it doesn't seem to work with get.

$ handlr list
┌───────────────────────────────────┬────────────────────────────────┐
│ application/octet-stream          │ mousepad.desktop               │
│ application/pdf                   │ org.pwmt.zathura.desktop       │
│ application/x-gettext-translation │ mousepad.desktop               │
│ application/x-wine-extension-ini  │ mousepad.desktop               │
│ application/xml                   │ mousepad.desktop               │
│ image/gif                         │ viewnior.desktop, gimp.desktop │
│ image/jpeg                        │ viewnior.desktop, gimp.desktop │
│ image/png                         │ viewnior.desktop, gimp.desktop │
│ text/plain                        │ mousepad.desktop               │
│ video/mp4                         │ mpv.desktop                    │
│ video/ogg                         │ vlc.desktop                    │
│ video/x-flv                       │ vlc.desktop                    │
│ video/x-ms-wmv                    │ vlc.desktop                    │
│ video/x-ogm+ogg                   │ vlc.desktop                    │
│ video/x-theora+ogg                │ vlc.desktop                    │
└───────────────────────────────────┴────────────────────────────────┘

So I expect when I run handlr get 'video/*' it will filter the list to just the video entries. But it doesn't:

$ handlr get 'video/*'
no handlers found for 'video/*'

Possibility of a library API?

It's be really great to have a library that could be used for any application that wants to generically "open" files, or register itself as a default file handler. Since this would include a lot of the logic in handlr, would you have any interest in creating this API?

Consider switching to xdg-mime

The mime-db crate uses a hard-coded list of globs/MIME type mappings; the mime-sniffer crate uses its own list of magic matchers. This means that every time a new MIME type is added, both crates need to be updated, and thus any dependent crate or application needs to be updated as well.

Most modern Linux/Unix-like OSes provide on the shared-mime-info database for applications trying to match file data and file names to a MIME type; I've written the xdg-mime crate that implements the API to load and query that database. Since the database is externally updated, every user of xdg-mime will automatically be updated without requiring to be rebuilt.

Disclaimer: the xdg-mime crate API is still in somewhat in flux, but I'm happy to add new API to fit the requirements of applications like handlr. 😉

panic when mimeapps.list doesn't end with newline?

Thanks for this excellent piece of software.

Version: 0.6.4

When my mimeapps.list doesn't end with a newline I get this panic:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseApps(Error { variant: ParsingError { positives: [value_char], negatives: [] }, location: Pos(308), line_col: Pos((11, 22)), path: None, line: "text/*=emacs.desktop;", continued_line: None })', src/apps/user.rs:12:65
stack backtrace:
   0:     0x55eac2c5c82e - <unknown>
   1:     0x55eac2bfd04c - <unknown>
   2:     0x55eac2c5bf64 - <unknown>
   3:     0x55eac2c5bd9d - <unknown>
   4:     0x55eac2c7a108 - <unknown>
   5:     0x55eac2c7a086 - <unknown>
   6:     0x55eac2c7a042 - <unknown>
   7:     0x55eac2b82210 - <unknown>
   8:     0x55eac2b824f2 - <unknown>
   9:     0x55eac2b90b96 - <unknown>
  10:     0x55eac2c3155b - <unknown>
  11:     0x55eac2c52658 - <unknown>
  12:     0x55eac2b87aab - <unknown>
  13:     0x55eac2c0fe53 - <unknown>
  14:     0x55eac2c0b693 - <unknown>
  15:     0x55eac2c0ddc3 - <unknown>
  16:     0x7fc3d22e2b25 - __libc_start_main
  17:     0x55eac2b8cbbe - <unknown>
  18:                0x0 - <unknown>

When I add a newline, there is no issue.

I think handlr should throw an error here or ignore it.

Should write to mimeapps.list atomically to prevent intermediate states or corruption

I think it makes sense to atomically write to mimeapps.list, by writing to a temporary file, then renaming it on top of mimeapps.list.

• This prevents other apps running concurrently from seeing empty or partial mimeapps.list contents if it reads while handlr is writing to the file.
• Additionally, you can fsync the temporary file before renaming it on top of mimeapps.list. If you don't do this, the risk is that a power outage will result in the temporary file being renamed to mimeapps.list, but the contents of the temporary file not being written to disk. Performing a fsync reduces the chances of this happening, but has a performance penalty on ext3 (which isn't commonly used anymore I hope), and may not necessarily work on flash memory (because apparently some disks lie about having persisted blocks to nonvolatile storage).

https://danluu.com/file-consistency/ describes the pitfalls of filesystems and fsync. It describes using log files for atomicity, and advises against rename-based atomic saves. However, rename-based saving is our only option, since apps don't know how to read log files but only mimeapps.list. And GLib uses rename and fsync, so it should be fine...

• GLib writing to mimeapps.list calls g_file_set_contents_full().
  • Passes G_FILE_SET_CONTENTS_CONSISTENT (create temporary file, fsync the temp file, then rename). Does not pass G_FILE_SET_CONTENTS_DURABLE (fsync the directory after renaming). I agree with these choices.
  • Passes G_FILE_SET_CONTENTS_ONLY_EXISTING (don't write to a temp file if the file if it doesn't exist yet). I disagree with this choice, because it only improves performance in the rare situation where mimeapps.list doesn't exist at all, but introduces an edge case where a corrupted file can be written to disk or read by another app, and the exact reason why is hard to diagnose.
• g_file_set_contents_full() docs
• GFileSetContentsFlags flags docs

You can implement atomic saving yourself, or shell out to a crate like atomicwrites or tempfile's persist method (not sure why there are two of them, link, link). Note that tempfile's persist method mentions the risk of the tempfile being deleted or replaced with a different file under the same name. I haven't researched the best approach to take, the crate options out there, or where to create a temp file, or the optimal syscall for renaming. (capnproto's kj filesystem library creates a temporary file in the same directory and uses renameat().)

Tests fail and the ci does not run cargo check

Running the tests during package update I noticed they fail like this. I also noticed that you don't run cargo check during your CI. Why is that?

running 5 tests
test common::desktop_entry::tests::complex_exec ... ok
test apps::user::tests::wildcard_mimes ... ok
test common::mime_types::tests::from_ext ... FAILED
test common::mime_types::tests::user_input ... FAILED
test common::mime_types::tests::from_path ... FAILED

failures:

---- common::mime_types::tests::from_ext stdout ----
Error: Ambiguous(".mp3")
thread 'common::mime_types::tests::from_ext' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`: the test returned a termination value with a non-zero status code (1) which indicates a failure', /build/rustc-1.51.0-src/library/test/src/lib.rs:194:5
stack backtrace:
   0:     0x55555565230c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc72b2a79902e20a2
   1:     0x55555567ac7f - core::fmt::write::h363ea858f8d20109
   2:     0x55555563ec06 - std::io::Write::write_fmt::hb816cf7056dd43f9
   3:     0x555555639ad5 - std::panicking::default_hook::{{closure}}::hf776c4b8a29e2c23
   4:     0x5555556396e3 - std::panicking::default_hook::hd9a17e7e9b9c0d25
   5:     0x55555563a105 - std::panicking::rust_panic_with_hook::hf65e38fdef13d248
   6:     0x555555652b27 - std::panicking::begin_panic_handler::{{closure}}::h469be7df0b5aefa3
   7:     0x55555565246c - std::sys_common::backtrace::__rust_end_short_backtrace::hc9b4220705693734
   8:     0x555555639cb2 - rust_begin_unwind
   9:     0x55555567aa21 - core::panicking::panic_fmt::h0c4f421549c9e9f1
  10:     0x5555555a61bc - test::assert_test_result::h4083b2423d23db49
  11:     0x5555555a2f2d - core::ops::function::FnOnce::call_once::hf167e30cd78856b0
  12:     0x5555555fa5f3 - test::__rust_begin_short_backtrace::he4531e9de3270570
  13:     0x5555555f92a0 - test::run_test::run_test_inner::{{closure}}::h287fb0194f6b5030
  14:     0x5555555f1636 - std::sys_common::backtrace::__rust_begin_short_backtrace::hf6f5301e66e2e3b8
  15:     0x5555556038cd - core::ops::function::FnOnce::call_once{{vtable.shim}}::ha84e9c86101a5ab7
  16:     0x555555641e98 - std::sys::unix::thread::Thread::new::thread_start::h13c6b74cf3ad27b3
  17:     0x7ffff7f99e9e - start_thread
  18:     0x7ffff7d8349f - __GI___clone
  19:                0x0 - <unknown>

---- common::mime_types::tests::user_input stdout ----
Error: Ambiguous(".pdf")
thread 'common::mime_types::tests::user_input' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`: the test returned a termination value with a non-zero status code (1) which indicates a failure', /build/rustc-1.51.0-src/library/test/src/lib.rs:194:5
stack backtrace:
   0:     0x55555565230c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc72b2a79902e20a2
   1:     0x55555567ac7f - core::fmt::write::h363ea858f8d20109
   2:     0x55555563ec06 - std::io::Write::write_fmt::hb816cf7056dd43f9
   3:     0x555555639ad5 - std::panicking::default_hook::{{closure}}::hf776c4b8a29e2c23
   4:     0x5555556396e3 - std::panicking::default_hook::hd9a17e7e9b9c0d25
   5:     0x55555563a105 - std::panicking::rust_panic_with_hook::hf65e38fdef13d248
   6:     0x555555652b27 - std::panicking::begin_panic_handler::{{closure}}::h469be7df0b5aefa3
   7:     0x55555565246c - std::sys_common::backtrace::__rust_end_short_backtrace::hc9b4220705693734
   8:     0x555555639cb2 - rust_begin_unwind
   9:     0x55555567aa21 - core::panicking::panic_fmt::h0c4f421549c9e9f1
  10:     0x5555555a61bc - test::assert_test_result::h4083b2423d23db49
  11:     0x5555555a2ebd - core::ops::function::FnOnce::call_once::h30c031ecba034140
  12:     0x5555555fa5f3 - test::__rust_begin_short_backtrace::he4531e9de3270570
  13:     0x5555555f92a0 - test::run_test::run_test_inner::{{closure}}::h287fb0194f6b5030
  14:     0x5555555f1636 - std::sys_common::backtrace::__rust_begin_short_backtrace::hf6f5301e66e2e3b8
  15:     0x5555556038cd - core::ops::function::FnOnce::call_once{{vtable.shim}}::ha84e9c86101a5ab7
  16:     0x555555641e98 - std::sys::unix::thread::Thread::new::thread_start::h13c6b74cf3ad27b3
  17:     0x7ffff7f99e9e - start_thread
  18:     0x7ffff7d8349f - __GI___clone
  19:                0x0 - <unknown>

---- common::mime_types::tests::from_path stdout ----
thread 'common::mime_types::tests::from_path' panicked at 'assertion failed: `(left == right)`
  left: `"application/x-zerosize"`,
 right: `"text/plain"`', src/common/mime_types.rs:108:9
stack backtrace:
   0:     0x55555565230c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc72b2a79902e20a2
   1:     0x55555567ac7f - core::fmt::write::h363ea858f8d20109
   2:     0x55555563ec06 - std::io::Write::write_fmt::hb816cf7056dd43f9
   3:     0x555555639ad5 - std::panicking::default_hook::{{closure}}::hf776c4b8a29e2c23
   4:     0x5555556396e3 - std::panicking::default_hook::hd9a17e7e9b9c0d25
   5:     0x55555563a105 - std::panicking::rust_panic_with_hook::hf65e38fdef13d248
   6:     0x555555652b27 - std::panicking::begin_panic_handler::{{closure}}::h469be7df0b5aefa3
   7:     0x55555565246c - std::sys_common::backtrace::__rust_end_short_backtrace::hc9b4220705693734
   8:     0x555555639cb2 - rust_begin_unwind
   9:     0x55555567aa21 - core::panicking::panic_fmt::h0c4f421549c9e9f1
  10:     0x55555559303b - handlr::common::mime_types::tests::from_path::hbe545f74907d82a9
  11:     0x5555555a2f55 - core::ops::function::FnOnce::call_once::hf1a4d36b1021ffd8
  12:     0x5555555fa5f3 - test::__rust_begin_short_backtrace::he4531e9de3270570
  13:     0x5555555f92a0 - test::run_test::run_test_inner::{{closure}}::h287fb0194f6b5030
  14:     0x5555555f1636 - std::sys_common::backtrace::__rust_begin_short_backtrace::hf6f5301e66e2e3b8
  15:     0x5555556038cd - core::ops::function::FnOnce::call_once{{vtable.shim}}::ha84e9c86101a5ab7
  16:     0x555555641e98 - std::sys::unix::thread::Thread::new::thread_start::h13c6b74cf3ad27b3
  17:     0x7ffff7f99e9e - start_thread
  18:     0x7ffff7d8349f - __GI___clone
  19:                0x0 - <unknown>


failures:
    common::mime_types::tests::from_ext
    common::mime_types::tests::from_path
    common::mime_types::tests::user_input

test result: FAILED. 2 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass '--bin handlr'

Some html files are being opened by a terminal text editor instead of their handlr default

I'm not sure what's wrong, but some html (I think only text/html) are being opened by a text editor instead of their handlr default:

~ $ handlr get text/html
firefox.desktop
~ $ ls /usr/share/applications/firefox.desktop
/usr/share/applications/firefox.desktop
~ $ handlr open TOTO.html

→ Opens with kakoune.desktop.

~ $ cat ~/.local/bin/xdg-open
#!/bin/sh
handlr open "$@"
~ $ which xdg-open
/home/kabouik/.local/bin/xdg-open
~ $ xdg-open TOTO.html

→ Same (as expected).

~/.local/share/applications/kakoune.desktop:

[Desktop Entry]

Name=Kakoune
GenericName=Text Editor
Comment=Modal text editor

Icon=kak
Type=Application
Categories=terminal;TextEditor;
Keywords=text;editor;syntax;terminal;

Exec=tilix -e kak %U
StartupNotify=false
Terminal=true
MimeType=text/plain;text/x-chdr;text/x-csrc;text/x-c++hdr;text/x-c++src;text/x-java;text/x-dsrc;text/x-pascal;text/x-

~ $ handlr list
┌─────────────────────────────────────────────┬────────────────────────────────┐
│ #x-scheme-handler/mailspring                │ mailspring.desktop             │
│ application/excel                           │ libreoffice-calc.desktop       │
│ application/msexcel                         │ libreoffice-calc.desktop       │
│ application/pdf                             │ mupdf.desktop                  │
│ application/rtf                             │ libreoffice-writer.desktop     │
│ application/vnd.ms-excel                    │ libreoffice-calc.desktop       │
│ application/vnd.oasis.opendocument.text     │ libreoffice-writer.desktop     │
│ application/vnd.openxmlformats-officedocum+ │ libreoffice-calc.desktop       │
│ application/vnd.openxmlformats-officedocum+ │ libreoffice-writer.desktop     │
│ application/x-extension-htm                 │ userapp-Firefox-XGT2G0.desktop │
│ application/x-extension-shtml               │ userapp-Firefox-XGT2G0.desktop │
│ application/x-extension-xht                 │ userapp-Firefox-XGT2G0.desktop │
│ application/x-extension-xhtml               │ userapp-Firefox-XGT2G0.desktop │
│ application/x-ms-excel                      │ libreoffice-calc.desktop       │
│ application/xhtml+xml                       │ firefox.desktop                │
│ audio/mp3                                   │ cmus.desktop, sayonara.desktop │
│ audio/mpeg                                  │ cmus.desktop, sayonara.desktop │
│ image/bmp                                   │ viewnior.desktop               │
│ image/gif                                   │ viewnior.desktop               │
│ image/jpeg                                  │ viewnior.desktop               │
│ image/jpg                                   │ viewnior.desktop               │
│ image/png                                   │ viewnior.desktop               │
│ inode/directory                             │ org.gnome.Nautilus.desktop     │
│ text/html                                   │ firefox.desktop                │
│ text/plain                                  │ kakoune.desktop                │
│ video/3gp                                   │ mpv.desktop                    │
│ video/3gpp                                  │ mpv.desktop                    │
│ video/3gpp2                                 │ mpv.desktop                    │
│ video/divx                                  │ mpv.desktop                    │
│ video/dv                                    │ mpv.desktop                    │
│ video/fli                                   │ mpv.desktop                    │
│ video/flv                                   │ mpv.desktop                    │
│ video/mp2t                                  │ mpv.desktop                    │
│ video/mp4                                   │ mpv.desktop                    │
│ video/mp4v-es                               │ mpv.desktop                    │
│ video/mpeg                                  │ mpv.desktop                    │
│ video/mpeg-system                           │ mpv.desktop                    │
│ video/msvideo                               │ mpv.desktop                    │
│ video/ogg                                   │ mpv.desktop                    │
│ video/quicktime                             │ mpv.desktop                    │
│ video/vnd.mpegurl                           │ mpv.desktop                    │
│ video/vnd.rn-realvideo                      │ mpv.desktop                    │
│ video/webm                                  │ mpv.desktop                    │
│ video/x-avi                                 │ mpv.desktop                    │
│ video/x-flc                                 │ mpv.desktop                    │
│ video/x-fli                                 │ mpv.desktop                    │
│ video/x-flv                                 │ mpv.desktop                    │
│ video/x-m4v                                 │ mpv.desktop                    │
│ video/x-matroska                            │ mpv.desktop                    │
│ video/x-mpeg                                │ mpv.desktop                    │
│ video/x-mpeg-system                         │ mpv.desktop                    │
│ video/x-mpeg2                               │ mpv.desktop                    │
│ video/x-ms-asf                              │ mpv.desktop                    │
│ video/x-ms-wm                               │ mpv.desktop                    │
│ video/x-ms-wmv                              │ mpv.desktop                    │
│ video/x-ms-wmx                              │ mpv.desktop                    │
│ video/x-msvideo                             │ mpv.desktop                    │
│ video/x-nsv                                 │ mpv.desktop                    │
│ video/x-ogm+ogg                             │ mpv.desktop                    │
│ video/x-theora                              │ mpv.desktop                    │
│ video/x-theora+ogg                          │ mpv.desktop                    │
│ x-scheme-handler/chrome                     │ userapp-Firefox-XGT2G0.desktop │
│ x-scheme-handler/ftp                        │ userapp-Firefox-XGT2G0.desktop │
│ x-scheme-handler/http                       │ userapp-Firefox-XGT2G0.desktop │
│ x-scheme-handler/https                      │ userapp-Firefox-XGT2G0.desktop │
└─────────────────────────────────────────────┴────────────────────────────────┘

Is it just a local issue on my machine or is it because the default for text/plain takes precedence for text/html?

command to run a .desktop file

I think a subcommand for handlr to open a .desktop file would be great, as it would be able to replace another program (gtk-launch or alternatives) and most of the code required is already present in handlr.

can this be used both for GUI and terminal apps?

is this even a good idea? I notice that you can only set .desktop file handlers, not arbitrary commands.
desktop files seem to be oblivious to whether handlr will be invoked from a terminal or not, so does it make sense to mix these use cases?

Does not fall back to mimetypes if directory name is of the format ___.___

I'd tried opening a path using handlr, it didn't work - the path was /home/dan/.local/share/wesnoth/1.14/. Other paths, such as /home/dan, opened fine, as the inode/directory mimetype is set to use Thunar.

Here's what I did to narrow down the issue - I hope that helps:

It seems handlr thinks that the path provided is actually the path to a file, and so checks for existing extensions in its list. No matching one is exists, so it errors out, but doesn't check for if it has a mimetype handler.

It would also be worth checking for mimetype handlers before extensions - otherwise, with a directory of /tmp/thing.pdf/, it tries opening it with the handler for .pdf files, even though it's a directory/

Panic when mimeapps.list is not writable

It seems that handlr expects mimeapps.list to be writable even handlr doesn't need to write to it.

$ handlr --version
handlr 0.6.4
$ chmod -w ~/.config/mimeapps.list
$ export RUST_BACKTRACE=full
$ handlr --version
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Os { code: 13, kind: PermissionDenied, message: "Permission denied" })', src/apps/user.rs:12:65
stack backtrace:
   0:     0x5643ea23f4a5 - <unknown>
   1:     0x5643ea1d3c8c - <unknown>
   2:     0x5643ea23e9e4 - <unknown>
   3:     0x5643ea23e7cf - <unknown>
   4:     0x5643ea25e468 - <unknown>
   5:     0x5643ea25e3e6 - <unknown>
   6:     0x5643ea25e3a2 - <unknown>
   7:     0x5643ea15f100 - <unknown>
   8:     0x5643ea15f432 - <unknown>
   9:     0x5643ea16ed9e - <unknown>
  10:     0x5643ea172c1c - <unknown>
  11:     0x5643ea234a43 - <unknown>
  12:     0x5643ea15d18b - <unknown>
  13:     0x5643ea1e9c83 - <unknown>
  14:     0x5643ea1e28e3 - <unknown>
  15:     0x5643ea1e5662 - <unknown>
  16:     0x7efe507f0b25 - __libc_start_main
  17:     0x5643ea16975e - <unknown>
  18:                0x0 - <unknown>

I think handlr should try to write to mimeapps.list only if called with set, unset and add.

Cannot set handler for mime application/x-ipynb+json

I'm trying to set the handler for jupyter notebook files, whose mime type should be application/x-ipynb+json, but this happens:

$ handlr set application/x-ipynb+json jupyter-notebook.desktop 
error: Invalid value for '<mime>': invalid mime application/x-ipynb+json

I tried with application/ipynb+json, but I had the same results

Unable to set x-scheme-handler

Please consider following example:

❯ handlr get x-scheme-handler/mailto
org.kde.kmail2.desktop
❯ handlr set x-scheme-handler/mailto /home/finkel/Desktop/mailto.desktop
error: Invalid value for '<handler>': no handler defined for this mime/extension

Here we expect that if we can query scheme handler — we should be able to set it too.
But it unexpectedly prints error (with some strange description).

MagicError: File 5.39 supports only version 16 magic files.

In lots of applications I get the following error message when trying to open a file:

MagicError: File 5.39 supports only version 16 magic files. '/-tmp/.mime_detective_magic.mgc' is version 14

I am using latest Arch [with the xdg-utils replacer]. What am I doing wrong?
If there is anything I can help or provide with additional help, I'd be happy to

Bad stdin for text editors like neovim and nano.

Before dismissing this, with xdg-utils Arch package, the following terminal *.desktop entriy works as expected.

at ~/.local/share/applications/nvim.desktop

[Desktop Entry]
Type=Application
Name=Neovim editor
cat mimeapps.list | grep nvim
application/octet-stream=nvim.desktop;
text/plain=nvim.desktop;
text/markdown=nvim.desktop;
application/x-shellscript=nvim.desktop;
Exec=nvim %F
Terminal=true
NoDisplay=true
Type=Application
Icon=nvim
Categories=Utility;TextEditor

the following

% handlr open simple.txt fails to launch nvim. (nvim is running in the background)

The nvim.desktop entry is matched correctly and used.

cat mimeapps.list | grep nvim
application/octet-stream=nvim.desktop;
text/plain=nvim.desktop;
text/markdown=nvim.desktop;
application/x-shellscript=nvim.desktop;

I am able to launch nvim in separate terminal window

if I change exec

Exec=alacritty -e nvim %F

Then it works and spawns new window with nvim opening the file.

Opening url encoded file paths

So...
Handlr seems to pass uri file paths directly to the program (differently from xdg-open) which some programs are not ready to handle.
That make the file not to be found.

example:
file://home/user/file.png
isn't parsed to
/home/user/file.png

XDG-utils-handlr doesn't cover all xdg-tools commands

Hi! I've found that I've had some issues with updating some software when it uses some xdg-tools commands in its install script; here's an example when I was updating reaper-bin from the AUR:

REAPER installer -- install to /home/dan/.cache/yay/reaper-bin/pkg/reaper-bin/opt

Copying files... done
Writing uninstall script to /home/dan/.cache/yay/reaper-bin/pkg/reaper-bin/opt/REAPER/uninstall-reaper.sh
Installing desktop integration for user.../home/dan/.cache/yay/reaper-bin/src/reaper_linux_x86_64/install-reaper.sh: line 520: xdg-icon-resource: command not found
/home/dan/.cache/yay/reaper-bin/src/reaper_linux_x86_64/install-reaper.sh: line 521: xdg-icon-resource: command not found
/home/dan/.cache/yay/reaper-bin/src/reaper_linux_x86_64/install-reaper.sh: line 525: xdg-icon-resource: command not found
/home/dan/.cache/yay/reaper-bin/src/reaper_linux_x86_64/install-reaper.sh: line 525: xdg-icon-resource: command not found
/home/dan/.cache/yay/reaper-bin/src/reaper_linux_x86_64/install-reaper.sh: line 525: xdg-icon-resource: command not found
/home/dan/.cache/yay/reaper-bin/src/reaper_linux_x86_64/install-reaper.sh: line 525: xdg-icon-resource: command not found
/home/dan/.cache/yay/reaper-bin/src/reaper_linux_x86_64/install-reaper.sh: line 525: xdg-icon-resource: command not found
/home/dan/.cache/yay/reaper-bin/src/reaper_linux_x86_64/install-reaper.sh: line 525: xdg-icon-resource: command not found
/home/dan/.cache/yay/reaper-bin/src/reaper_linux_x86_64/install-reaper.sh: line 528: xdg-desktop-menu: command not found
/home/dan/.cache/yay/reaper-bin/src/reaper_linux_x86_64/install-reaper.sh: line 594: xdg-mime: command not found

Is it possible to handle those commands with handlr's xdg-utils?

handlr does not forks the process so launched apps dies with parent terminal

I think this is wrong, xdg-open does fork it's launched apps so the parent terminal emulator can be closed without killing child process.

---

example: "I open a terminal emulator and do $ handlr open video.mkv, the mpv associated with the matroska launches and when term killed, the mpv is killed also. However when $ xdg-open video.mkv the mpv is not killed when terminal emulator dies`

It would be also awesome if this behavior could be overridden with an argument.

--nofork would behave as the current handlr behavior

Incorrect handling of standard output and error output with nvim

First of all, thank you very much for your development, handlr is incredibly simple and practical to use.

Now, I wanted to report a bug I'm having after testing your patch for issue #34.

Now when I use the command

handlr open anyfile.txt

Handlr tries to open the file 'properly' with nvim (apparently in the current terminal), but immediately exits and the terminal is left with the commands done.

I noticed however that if I redirect the standard output and the error output using

handlr open anyfile.txt > handlrlog.txt 2>&1

It works perfectly, and opens nvim with the file BUT in a new terminal (which I actually like that it does).

As if it were useful, the output that remains in handlrlog.txt is:

[115 09: 16: 19.743786] [PARSE ERROR] CSI code 0x74 has 3> 2 parameters
[115 09: 16: 22.358337] [PARSE ERROR] CSI code 0x74 has 3> 2 parameters

If I can help with any other information, I will be attentive. Thank you very much in advance!

mimeo-style custom association file

Mimeo, another resource opener, supports having an association file, separate from mimeapps.list, that gives you fine-grained control over which programs open which URLs or file types. For example, you can use regular expressions to open YouTube links in vlc or FreeTube or open files with programs by directly using file extensions rather than mimetypes.

Would it be possible to implement something similar? I know Rust and I would be more than happy to pitch in.

Add the MIT license file to the repository and a tagged release

Currently the only indication of what license handlr is under is in the cargo.toml's line stating it's MIT-licensed. This is mostly a bookkeeping thing, but adding a license text file (as COPYING, LICENSE.txt, or other accepted names) helps a few things:

• Makes it easy to see the license at a glance. This helps folks who are selective about the licenses of the software they use.
• GitHub can detect the license file and indicate in the sidebar that it's MIT-licensed (and point users to the license file).
• Folks packaging handlr can provide a copy of the license and copyright notice (because of the second paragraph in the MIT license), allowing them to provide packaged copies of handlr and keep with the spirit of the license.

In particular, I'm running into the last case. In order to package handlr for Void Linux, I need a tagged release of handlr containing the license text so I can package the license with the executable. I don't know that you'd want to tag a release just for the license, but getting a license file into a release would allow me to move forward on packaging handlr for folks to use.

Malformed entry in desktop file

I recently stumbled upon handlr and I love it, thank you so much for it, it really healed a lot of headaches I was always having with xdg-open. However, I have a custom .desktop file that I would like to use as a default application and handlr says the desktop entry is malformed. I'm sure this is me doing something wrong in the .desktop file, but it used to work with other openers and handlr is not saying exactly what is wrong with it:

$ handlr set .mp3 cmus.desktop
error: Invalid value for '<handler>': malformed desktop entry at /home/kabouik/.local/share/applications/cmus.desktop

$ micro /home/kabouik/.local/share/applications/cmus.desktop 

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Display=true
Exec=bash -c "(! pgrep cmus && tilix -e cmus && tilix -a session-add-down -e cava); sleep 0.1 && cmus-remote -q %f"
Terminal=false
Name=cmus-remote
Comment=Music player cmus-remote control
NoDisplay=true
Icon=cmus

This is supposed to open a new Tilix window and run cmus in it, plus open an additional Tilix pane below it to run cava, if a cmus session is already opened, it will just add the file to play queue using cmus-remote. There is obviously something handlr doesn't like about it but I don't know how to troubleshoot. Any help would be greatly appreciated!

Sorting mimeapps.list breaks GNOME/GLib's handling of MIME aliases

This application currently sorts each section of mimeapps.list alphabetically when rewriting it. This occurs because it's stored internally as a randomly-ordered HashMap and exposing this randomness externally is undesirable. Unfortunately this interacts in complex ways with MIME aliases.

What are MIME aliases? Each MIME type .xml can declare other MIME types as aliases for the XML file's "canonical name". For example, in the shared-mime-info database, audio/flac is the canonical name for FLAC files, with alias audio/x-flac. (You can see this by looking in /usr/share/mime/audio/flac.xml and spotting the line <alias type="audio/x-flac"/>.) And audio/x-wav is the canonical name for WAV files, with alias audio/wav.

MIME aliases cause problems

The problem is that GNOME/GTK/GLib apps depend on the order of mimeapps.list when resolving the apps bound to a MIME type with aliases. I've done some research on a (GNOME GitLab bug report](https://gitlab.gnome.org/GNOME/glib/-/issues/1298#note_1125791). If multiple aliases of the same MIME type appear in mimeapps.list, GLib will use whichever list of applications appears first, rather than the canonical MIME type. This confused me at first, when I was editing [Default Applications] audio/flac and it didn't take effect because audio/x-flac appeared earlier. Luckily, GNOME usually (but not always) only writes the canonical MIME type to mimeapps.list, or writes the canonical MIME type before aliases.

Unfortunately handlr (like KDE) sorts each section of mimeapps.list alphabetically. If this sorts an alias before a canonical type, then GLib will use an alias for resolving default apps, but the canonical type for setting default apps, preventing the user from setting the default app for that file type!

For example, both KDE (kmimetypefinder5 -f foo.wav) and GNOME (gio info must-exist.wav) think .wav files are audio/x-wav (the canonical name). But when handlr rewrites mimeapps.list, it sorts each section of ~/.config/mimeapps.list alphabetically:

handlr/src/apps/user.rs

Lines 191 to 196 in b5468c1

	for (k, v) in self.added_associations.iter().sorted() {
	writer.write_all(k.essence_str().as_ref())?;
	writer.write_all(b"=")?;
	writer.write_all(v.iter().join(";").as_ref())?;
	writer.write_all(b";\n")?;
	}

So now audio/wav (a nonstandard alias) comes before audio/x-wav, and GTK/GNOME/GLib will use the "ghost" audio/wav association when opening WAV files, preventing .wav files from being reconfigured in either KDE or GNOME! (Reconfiguring in either KDE or GNOME edits the canonical MIME type, which only takes effect in KDE and not GNOME.)

---

The alternative is to prioritize the canonical MIME mapping over aliases. This is what KDE does.

After researching this issue extensively, I've concluded that both approaches are flawed. Searching the shared-mime-info repo's commit history, I found that the shared-mime-info db is actively swapping main/alias declarations. I think that this can cause KDE to leave behind stale associations for aliases when it writes new associations to the new canonical names.

Preserving mimeapps.list order?

If you want to minimize the amount that this program changes mimeapps.list, one approach is to preserve the order of mimeapps.list and only append items to the end. This requires modifying the code to preserve the order of items in the hashmap, which will not be easy.

Fixing mimeapps.list?

After researching the MIME alias issue I described earlier, I had the idea to write a MIME fixer app in Rust (since GNOME didn't seem to be fixing the issue) coupled with a MIME editing GUI. Then I found handlr (a MIME editing CLI) and thought it would make sense to integrate this functionality into handlr instead.

Are you interested in extending handlr to fix mimeapps.list files to behave properly on GLib/GNOME and erase stale entries? (Perhaps fixing mimeapps.list should only occur when a settings flag is enabled, and if not, handlr will leave mimeapps.list in their original order, and unedited except for entries you explicitly modify.)

My idea for a MIME fixer is to store all associations in the program by their canonical name. If fixing is enabled, when loading mimeapps.list from disk, the program merges the associations of canonical names and aliases (preferring the canonical name to aliases, but falling back to the first alias in the file if no canonical name is present). And when the user tries to set the file association of a MIME alias, if fixing is enabled, handlr will set the association of the canonical name instead.

Initially, I wanted to always write MIME associations to all MIME type aliases as well as the canonical name. However this is a flawed idea because in the shared-mime-info database, some MIME type aliases have switched between different canonical MIME types, and if the canonical MIME types are mapped to different apps, this can lead to inconsistencies between the canonical and aliased MIME types.

I think it's a better idea to erase all MIME aliases present and never write MIME aliases at all, only write to the canonical name. This way, as long as MIME types never change canonical names, they will never go stale. And if MIME types do change canonical names, running the MIME-fixing program again will rename the mimeapps.list entry to the new name.

handlr clears "Removed Associations" section of mimeapps.list

mimeapps.list has a [Removed Associations] section for apps which are removed from the selection order. For example, you can use it to prevent Wine Internet Explorer from trying to handle PDF files (though you're probably better off removing ~/.local/share/applications/wine-extension-*.desktop by hand). This section of the file can be added using GNOME's "Applications" settings page, and opting apps out of specific file extensions.

Unfortunately handlr clears this section when editing mimeapps.list, since it doesn't read it when loading the file, and rewrites the entire mimeapps.list instead of updating the old contents in-place.

Is it possible to preserve the "Removed Associations" section of the file?

"handlr list" doesn't fully describe decision making process. make it clearer what assumed prior knowledge is?

Hello,

my handlr list output is below

handlr list
┌─────────────────────────┬────────────────────────────────────┐
│ message/rfc822          │ userapp-Thunderbird-JHQ4UY.desktop │
│ x-scheme-handler/mailto │ userapp-Thunderbird-JHQ4UY.desktop │
│ x-scheme-handler/webcal │ chromium.desktop                   │
└─────────────────────────┴────────────────────────────────────┘

This seems incomplete. I know for example that a file with extention .txt will be opened by gvim (though I don't know why)
When I strace handr list i see it opens lots of .desktop files in .local/share/applications and /usr/share/applications/
From what I understand, there's also custom associations that can be set in handlr as well as a separate mimetype data base.
The readme mentions "Automatically removes invalid/wrong .desktop entries from mimeapps.list", I have these 3 files (see below) and it's not clear how they're used or in which priority order:

~/.config/mimeapps.list
~/.local/share/mimeapps.list
~/.local/share/applications/mimeapps.list

I know that part of the problem is that I'm uneducated on the matter, and i could probably go read the various (?) XDG/opendesktop specs that are relevant, but it seems rather confusing, so maybe there is an opportunity to steer new users in the right direction:

• it's not even clear what is assumed prior knowledge before using this tool? perhaps the readme should link to the respective resources/specifications that I should study first?
• the readme mentions Compared to xdg-utils, so this tool replace xdg-open and xdg-mime? if not, which ones exactly?
• is there any quick wins that can be made to make handlr more userfriendly, and not require (as much) prior knowledge?
  for example handr list could give a more complete listing of all resources that it uses in its decision process. or how about something like handlr explain that says, for a given file, how it arrives at a decision?

thanks!

handlr does not respect desktop file IDs from subdirectories

According to the Desktop Entry Specification, desktop file IDs do not map one-to-one with filenames; desktop file IDs for entries in subdirectories of the appropriate data directory include those parent directories with directory separators replaced by dashes; e.g., .local/share/applications/myapp/plugins/foo.desktop maps to myapp-plugins-foo.desktop.

This is handled properly in GNOME and elsewhere but handlr requires me to specify myapp/plugins/foo.desktop.

handlr incorrectly handling `Terminal` property with launch command

The Terminal property in a .desktop file specifies, whether an application will start it's own GUI or needs to be run from inside a terminal emulator, so a desktop file with Terminal=true should have its command run inside a terminal emulator, for example alacritty -e $COMMAND. handlr misinterprets this, hiding a command's output if it's set to false and never launching a terminal emulator.

The result of this is that output will be needlessly hidden for most applications, and some applications, such as htop.desktop will fail to correctly launch, as their TUI will be hidden when launched from a UI that doesn't show handlr's output.

EDIT: There seems to be no clear specification on what terminal emulator to use. GNOME's stack just tries some known ones. Maybe handlr can find a more elegant solution.

open multiple files by spawning mulitple programs

Hi,
the default behavior, is to either open all files in the program if it's tolerated (micro for instance) then if other files needs other handlers, open them after the first has closed... I don't like that, and I don't like using the tab feature of micro either.
Could it be possible to specify something like that:

handlr set 'text/*' "footclient micro {each}"
and be default if several handlers are needed, open them all simultaneously... perhaps in different tmux session ?

Use handlr for D-Bus's FileManager1

According to https://wiki.archlinux.org/index.php/default_applications , firefox and other applications does not use xdg-open, but dbus.
For those apps, I mostly care about opening in a file manager. For example, for Firefox: opening a download in ranger rather than in nautilus.
Well.. I decided to try using handlr even here.

Following https://wiki.archlinux.org/index.php/File_manager_functionality#D-Bus , I created the following file: ~/.local/share/dbus-1/services/filemanager.FileManager1.service with inside:

[D-BUS Service]
Name=org.freedesktop.FileManager1
Exec=/usr/bin/handlr open

This works as expected if xterm is installed, but not otherwise. For example, opening firefox from terminal to log errors I get:

% firefox
sh: line 1: exec: xterm: not found

handlr should be set.. I have in ~/.config/mimeapps.list:

[Default Applications]
x-scheme-handler/terminal=Alacritty.desktop;
inode/directory=ranger.desktop;

and in ~/.local/share/applications/ranger.desktop:

[Desktop Entry]
Name=ranger
Type=Application
Terminal=true
Exec=ranger %f
Categories=System;FileManager
MimeType=inode/directory;

Using handlr open $HOME works as expected.
What should I try?

Fails to open nvim desktop file, possibly because it starts in terminal

Hi, I just discovered this nice tool, because I am not happy with the performance of xdg-open. But I have an issue with it launching nvim, I get the error:

Vim: Error reading input, exiting...

Vim: Finished.

My configuration is just:

│ application/pdf                         │ org.gnome.Evince.desktop           │
│ application/postscript                  │ org.gnome.eog.desktop              │
│ application/vnd.ms-publisher            │ libreoffice-draw.desktop           │
│ image/jpeg                              │ org.gnome.eog.desktop              │
│ image/jpg                               │ org.gnome.eog.desktop              │
│ image/png                               │ org.gnome.eog.desktop              │
│ inode/directory                         │ spacefm.desktop                    │
│ text/plain                              │ nvim.desktop                       │
│ text/x-c                                │ nvim.desktop                       │

I suppose that this is related to the fact that it gets launched in a terminal.
I have installed the package via the arch linux aur.
Thanks

What's the proper way of setting up handler to open telegram links?

For example: tg://resolve?domain=WayDroid

Compile errors due to breaking changes in Clap 3.0 betas

When compiling handlr in release mode it fails on some errors related to Clap.

error[E0433]: failed to resolve: could not find `Clap` in `clap`
 --> src/cli.rs:3:16
  |
3 | #[derive(clap::Clap)]
  |                ^^^^ could not find `Clap` in `clap`

error: cannot find attribute `clap` in this scope
 --> src/cli.rs:4:3
  |
4 | #[clap(global_setting = clap::AppSettings::DeriveDisplayOrder)]
  |   ^^^^
  |
  = note: `clap` is in scope, but it is a crate, not an attribute

error: cannot find attribute `clap` in this scope
 --> src/cli.rs:5:3
  |
5 | #[clap(global_setting = clap::AppSettings::DisableHelpSubcommand)]
  |   ^^^^
  |
  = note: `clap` is in scope, but it is a crate, not an attribute

... and several more

According to this Clap issue and their changelog there have been some breaking changes.

edit:
The actual culprit seems to be clap_derive, an indirect dependency. I can compile handlr successfully when I lock it at beta.2 but not when it's at beta.4 or beta.5 (beta.3 was skipped)

Categories

There's seems to be no way to add default app for everything inside a mime category like video/

Is there a way to keep terminal busy with `handlr open` until the application is quit?

For a script, I would need handlr open to keep the terminal busy while the default application process is still running, so that another command is run when the process is terminated. xdg-open does this, but it seems handlr open immediately detaches the terminal from the application. I have tried using handlr open "$@" & in my ~/.local/bin/xdg-open replacement for vanilla /usr/bin/xdg-open, but that did not help.

Panic when using '<' or '>' characters in a commented line in mimeapps.list

When there is a '<' or '>' character in a commented line in mimeapps.list, I get the following panic message.

Panic message:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseApps(Error { variant: ParsingError { positives: [name_char], negatives: [] }, location: Pos(981), line_col: Pos((32, 2)), path: None, line: "#>␊", continued_line: None })', src/apps/user.rs:12:65

Version: 0.6.4

handlr open "https://google.com" causes flatpak firefox to try to open "file://$(pwd)/%u"

Hiya. Got Firefox installed as a flatpak, and when trying to use this nifty-looking utility to open a URL, it does correctly open Firefox, but it tries to load the page "file://$(pwd)/%u" and fails. Other applications open URLs in firefox just fine.

What do you need from me to diagnose and fix this?

EDIT: Here's the exec line of the desktop file:

/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=firefox --file-forwarding org.mozilla.firefox @@u %u @@

Is your utility not correctly handling the %u specifier?

An example of setting the default terminal within filemanagers?

I'm a bit confused about setting the default terminal emulator using x-scheme-handler/terminal as it's not working with neovim and thunar, here are the steps I followed:

• install xdg-utils-handlr from the AUR
• set x-scheme-handler/terminal (I have kitty installed)

~ handlr get x-scheme-handler/terminal
kitty.desktop

• now open your file manager of choice (I use thunar which uses GIO's GAppInfo as listed here) and right click on a .txt file
  
• select Open With "Neovim" (neovim does have Terminal=true in its .desktop file so that checks out)
  

No cigar :(

Furthermore the same steps can be followed with the change of thunar -> pcmanfm
And setting inside pcmanfm Edit > Preferences > Advanced > Terminal emulator to kitty works just fine.
This is obviously overriding something hence is a crutch of a solution

Am I missing something here?

Combine handlr with devour

I have a custom xdg-open in /home/user/local/bin/ that runs handlr open "$@" and it takes precedence over the vanilla /usr/bin/xdg-open in my $PATH. I would like to combine it with devour, a WM-agnostic swallowing feature for terminal, but I am not sure how to integrate it.

devour handlr open "$@" seems to initiate the swallowing feature, but somehow fails and the terminal is still shown. Or actually it swallows the terminal for a fraction of a second when launching handlr, but then handlr succeeds when lauching the default application, and therefore the terminal is shown again.

Is there any way, or is editing the .desktop files of the applications the only solution?

Handlr fails to open some file types

Hiya, sorry to bother you again, but I'd love to see this utility flourish. It seems that handlr doesn't know about some associations, and I'm not sure why.

I tested it out like so:

Aura Another Star OST $ handlr open 27\ -\ Necru\ Feratu.mp3
Error: NotFound
Aura Another Star OST $ handlr list
┌───────────────────────────────────────┬──────────────────────────────────────┐
│ application/vnd.bg-rcs-northernkentu+ │ handler-application-vnd.bg_rcs_nort+ │
│ application/x-ruby                    │ org.geany.Geany.desktop              │
│ application/x-shellscript             │ org.geany.Geany.desktop              │
│ application/xml                       │ org.geany.Geany.desktop              │
│ image/png                             │ mirage.desktop                       │
│ text/plain                            │ org.geany.Geany.desktop              │
│ text/x-crystal                        │ org.geany.Geany.desktop              │
│ text/x-lua                            │ org.geany.Geany.desktop              │
└───────────────────────────────────────┴──────────────────────────────────────┘

Is it normal for list's output to be so abbreviated?

I'm inclined to say it only knows about custom associations, but then I'm confused as to why it succeeds in opening https URIs. Another thing is that the application installed for opening .mp3 files is Celluloid, installed via Flatpak. I have LibreOffice as a Flatpak and it can't open .odt files. But again, that makes me wonder why it succeeds in opening https URIs. My archiver is installed as a system package, but it can't open tarballs either.

What do you need from me to help you diagnose this? :)

set handlers really by extensions, not merely by mime-type hiding behind extensions

Hi
I just nocticed ffmpeg isn't setting mimetype properly, or not always at least. It happened with a .nut video I compiled, that reads well with mpv etc, but it's mime-type is absent..
SCP Dollhouse.nut: application/octet-stream; charset=binary
Handlr isn't liking that very much.
So if it could do what it says it can do (setting handlers by extension, regardless of mime-type) it would be neat.

GREEEEEEEEEEEEEEEEEEEEEEEAT program otherwise, lightning-fast too, I love you guys.

Suport x-scheme-handler/file out of the box

Some apps use it (like telegram-desktop) it should work the same way as using the path without schema.

Force opening in terminal if already in one

I think it would be handy to have a command line option to fork to terminal even if already in one.
It would be useful for file manager.
Could be used with open and launch like: handlr open -t $HOME/Downloads

no handlers found for 'application/x-zerosize'

When opening avi video with
fuzzy-handlr() {
local output
output=$(fzf --height 40% --reverse </dev/tty) && handlr open ${(q-)output}

zle reset-prompt

}

zle -N fuzzy-handlr
bindkey '^o' fuzzy-handlr

It says:
no handlers found for 'application/x-zerosize'
but it open when i do:
handlr open 'path-to-file'

What is the best way to share file associations between machines?

I made a bash script containing 'handlr set' commands.
Is there a more convenient way? Maybe directly inside the handlr.toml file?

Unable to open m3u with default application

I am using latest Manjaro i3wm and downloaded handlr binary from releases section of this repo.

In terminal if I run
handlr launch .m3u pl.m3u
it is opening mpv and playing the playlist as expected.

But if I run
handlr open pl.m3u
it is opening emacs (my default editor) and showing the song list.

file pl.m3u gives ASCII text, whereas mimetype pl.m3u gives audio/x-mpegurl.

handlr get .m3u gives mpv.desktop.

Wrong mime-type guessed for some files

I noticed that handlr incorrectly guesses some of the Qt Designer UI files' mime type, it should be application/x-designer, but handlr thinks it is application/x-gtk-builder.

$ handlr open SettingsWidgetFdoSecrets.ui
no handlers found for 'application/x-gtk-builder'

Directly using xdg-mime from xdg-utils returns the correct result:

$ xdg-mime query filetype SettingsWidgetFdoSecrets.ui
application/x-designer

From the code I see that the file name based guess is always preferred over a content-based guess.

However, according to the xdg_mime doc, the correct behavior is to first do a name-based guess, if the result has multiple matches, do a content-based guess and use the latter as the final result.

I tried a simple PoC and xdg_mime indeed returns the correct result in content guess.

use xdg_mime::SharedMimeInfo;
use std::path::PathBuf;

fn main() {
    let path = PathBuf::from("SettingsWidgetFdoSecrets.ui");
    let db = SharedMimeInfo::new();
    let name_guesses = db.get_mime_types_from_file_name(&path.file_name().unwrap().to_string_lossy());
    println!("name guesses: {:?}", name_guesses);
    let content_guess = db.guess_mime_type().path(&path).guess();
    println!("content guess: {:?}, uncertain {}", content_guess.mime_type(), content_guess.uncertain());
}

prints

name guesses: ["application/x-designer", "application/x-gtk-builder"]
content guess: "application/x-designer", uncertain false

The file used in the above examples:
SettingsWidgetFdoSecrets.ui.zip

Default config values are mixed up

The default values for selector and terminal_emulator are switched around in:

handlr/src/config.rs

Lines 15 to 24 in 53278c0

	impl Default for Config {
	fn default() -> Self {
	// This seems repetitive but serde does not uses Default
	Config {
	enable_selector: false,
	selector: std::env::var("TERMINAL").unwrap_or("xterm -e".into()),
	terminal_emulator: "rofi -dmenu -p 'Open With: '".into(),
	}
	}
	}

Create mimeapps.list if not already present

I was excited to see that cargo didn't complain about the architecture of my arm device when trying cargo install handlr, but unfortunately it doesn't work on it. The binary available on Github doesn't work either. Would it be relevant to add somewhere in the README or in the release names that handlr requires x86_64?

enable selector as cli overriding option - feature request

I think one of the strong use cases for this program is selecting an option for opening files.

we naturally set a default application for the file types. for some file types, there will be more than one program.
It provides more flexibility to call selector option (which can be overriding the option set in configuration file, i.e: enable_selector=false).

I request you to provide this option, to selectively call (with this overriding option) this application from other programs.

'open' assumes same mimetype for all args

When opening multiple paths with handlr open p0 ... pn, the handler found for
p0 will be used for all subsequent paths p1 ... pn.

This obviously breaks in cases where the paths are of multiple different types.

I would suggest that the correct behaviour should be:

1. group paths by mimetype and associated handler
2. for each unique handler, determine if it supports multiple file (e.g. nvim):
   • if yes: open all associated paths with a single instance of the handler
   • if no: open an instance of the handler for each path

Let me know if the above sounds right, and I'll attempt a PR?