chmln / handlr Goto Github PK
View Code? Open in Web Editor NEWA better xdg-utils
License: MIT License
A better xdg-utils
License: MIT License
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:
xdg-utils-handlr
from the AURx-scheme-handler/terminal
(I have kitty installed)~ handlr get x-scheme-handler/terminal
kitty.desktop
.txt
fileOpen 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?
Some apps use it (like telegram-desktop) it should work the same way as using the path without schema.
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.
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
?
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.
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.
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:
Compared to xdg-utils
, so this tool replace xdg-open and xdg-mime? if not, which ones exactly?handlr
more userfriendly, and not require (as much) prior knowledge?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!
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 ?
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
?
There's seems to be no way to add default app for everything inside a mime category like video/
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?
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. 😉
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
.
The default values for selector
and terminal_emulator
are switched around in:
Lines 15 to 24 in 53278c0
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
I made a bash script containing 'handlr set' commands.
Is there a more convenient way? Maybe directly inside the handlr.toml file?
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).
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
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'
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
For example: tg://resolve?domain=WayDroid
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!
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?
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
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
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?
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/
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
.
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
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.
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:
Lines 191 to 196 in b5468c1
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.
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.
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.
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?
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)
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
.
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/*'
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.
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
When opening avi video with
fuzzy-handlr() {
local output
output=$(fzf --height 40% --reverse </dev/tty) && handlr open ${(q-)output}
}
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'
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.
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.
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.
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...
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.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.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()
.)
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
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?
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:
Let me know if the above sounds right, and I'll attempt a PR?
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.
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.
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?
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?
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!
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:
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.
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? :)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.