rovr fails to access "bat" under Debian 13

[SevenChalices]

Issue description

Hey there, the following issue is rather a distro-specific-compatibility-thing than a bug:
anyway, on one hand rovr v0.10 somehow finds bat on my system during the setup on first run (along with fd, etc.) but after that I get false error messages when I click on some displayable i.e. text files.

For some reason it still gets the file's contents on the right window. I believe that the reason for the error messages on click is that Debian's official repository provides bat in the following way (description of bat from apt/terminal):

bat is a drop-in cat(1) replacement featuring:
.

• syntax highlighting for a large number of languages;
  [...]
  .
  In this package the executable and its manpage have been renamed from ‘bat’ to
  ‘batcat’ because of a file name clash with another Debian package.

Guess rovr is looking for bat, maybe by querying apt/dpkg which says it is installed, but the executable's name is batcat instead of it's actual name, namely bat. Btw. I have set an alias for cat (I mask resp. "override" it simply with alias) as well as one alias which is literally bat - so checking it's presence on the host with a quick which/whereis/type built-in command may mislead your app or script as well (type -P some_app is a bit safer imo...at least for users like me who alias their half OS (a little exaggeration).

Hope I am not the only one with a 22 kB /etc/bash_aliases file (haha)...

How do you reproduce it?

1. Run rovr on Debian 13+ (12 should be fine too if batcat is available there) in some terminal emulator; this issue happens while using mouse-clicks, so take that into account. In my case I've used Yakuake/Konsole for running it.
2. Do the first-run-setup, note what programs are detected (you should enable them iirc)
3. Close and re-open rovr
4. Navigate around with your mouse and click on some non-binary (thus text-)files

Now you should see the error messages as shown in the short screen video:

20260905081714094_titi.mov

What is the expected result of the steps?

A slightly smarter function in rovr that is looking for / considering any distro-specific "deviations", especially when it comes to (certainly not always uniform) file paths and -names as they could be the reason for any (actually false) error messages.

Once more quoting Debian Stable's repository by
:~$ apt show bat # works without sudo. Both commands will show the following description, :~$ apt-cache show bat # scroll few lines down or "grep Description" if you are in text mode

bat is a drop-in cat(1) replacement featuring:
.

• syntax highlighting for a large number of languages;
  [...]
  .
  In this package the executable and its manpage have been renamed from ‘bat’ to
  ‘batcat’ because of a file name clash with another Debian package.

What actually happened after doing the steps?

Haven't noticed anything bad beside the named issue, everything else runs fine...

I was asking myself why files' contents are still displayed, maybe because of an anticipated fall back to pre-installed cat I guess? Then this issue is almost solved :)

Affected Operating System(s)

• Windows
• macOS
• Linux

How can this be fixed?

As already said, I think when considering such deviations that are naturally present when you have such great number of different distros & repositories; that means that package names differ as well. I guess a short research for that handful of apps should fix the problem within minutes.

For Debian the solution is clear. For Debian's derivates like Ubuntu / Linux Mint etc. you should check their description (bonus if it comes with a file list about the package).

_Maybe add some distro-dependent advice ("warning") for users (particularly who has any ultra-exotic derivate(s) with much more potential deviations of all kinds, not only their policy about package/app naming) of Debian-based distros and add the same for all users who got bat installed by: Building from source, downloading it in an compressed archive or some unofficial .deb package f.e. with their browser from Github or whatever source, bypassing their OS's official repository so to say. They should be more vigilant about how they handle such stuff and know what the risks are.

Although I'm not sure whether I'd not be classified as one of those guys myself ;) but such chaos like I have on my PC may be an unforgivable, but still valuable teacher in many aspects 😆

Hope this report helps you to get rid of this little annoyance hidden in the Linux distro ocean - thanks of course to all developers for your great work!
Have a nice weekend!

[NSPC911]

okay so the fallback is working nice, im not sure why bat was detected, but still unavailable.

can you run

python -c 'import shutil;print(shutil.which("bat"));print(shutil.which("batcat"))'

what do you see here?

[SevenChalices]

I doubt that it will be of much help, nevertheless, as I said before, the use aliases and that might make things more difficult, so I just repeated the step this way:

Anyway, the policy of naming packages which results in various names from distro to distro still is something I'd keep in mind, at least.

[NSPC911]

i'll update the setup helper to consider this scenario, backwards compatibility is dumb :/