`batcat` has been renamed to `bat` in Debian
Hi, the bat utility has been finally moved back to /usr/bin/bat from /usr/bin/batcat, as the package that used to "own" /usr/bin/bat hasn't been part of Debian for a couple of years. See https://bugs.debian.org/1029096 for the relevant Debian bug report.
This means that most likely the batcat workaround won't be needed in Debian 12 and Ubuntu 23.04 (not released yet), and it might make sense to mention this already in the README.
Related to #982
Oh this is great news! Thank you for posting here. I agree that we should already prepare for these changes.
FYI, I updated my Debian unstable and bat wasn't working again. Due to this bugfix:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029504
If I understand this correctly, the naming still conflicts with another executable (/usr/sbin/bat) from bacula-console-qt.
I don't know what the most debianic way to get this to work is, without making a manual symlink that's not managed by the packaging system. I'm not using bacula.
For now, I tried the alternative system:
$ sudo update-alternatives --install /usr/bin/bat bat /usr/bin/batcat 50
But I might be strong-arming it by using the system in the opposite way than it was intended, as it's supposed to help selecting between multiple binaries providing the same functionalities. So this is probably useless and not different to a manual symlink.
I think our best bet to solve this issue would be trying to convince bacula developers to change the /usr/sbin/bat filename upstream, maybe to /usr/sbin/bacula-bat.
So after a version of Debian with the bat command free, the bat project could make use of it on the next release.
Example:
Debian Bookworm: /usr/sbin/bat is part of bacula-console-qt (/usr/bin/bat is free)
Debian Trixie: both /usr/sbin/bat and /usr/bin/bat are free (to avoid confusion for upgrading bacula users to mistakenly run the wrong software)
Debian Forky: /usr/bin/bat is part of the bat package
In the transitional release (Trixie in this example) we could also replace the /usr/bin/bat (and symlink /usr/sbin/bat to it) with some info about this.
Something like:
#!/usr/bin/sh
echo 'This command used to be part of the "bacula-console-qt" package, and it's going to be part of the "bat" package on the next stable version of Debian.'
echo 'If you want to use the previous bat command from bacula-console-qt, please run "bacula-bat" as root.'
echo 'If you want to use the cat-like command from the bat package, please run "batcat".'
echo
echo 'You can also add an alias or a symlink for either of these commands. Example:'
echo
echo 'Alias:'
echo "echo 'alias bat="/usr/bin/batcat"' >> ~/.bashrc"
echo 'Local symlink for your user only:'
echo 'ln -s /usr/bin/batcat ~/.local/bin/bat'
echo
echo 'Symlink for the whole system (needs root permission):'
echo 'ln -s /usr/bin/batcat /usr/bin/bat'
echo 'or for bacula:'
echo 'ln -s /usr/sbin/bacula-bat /usr/sbin/bat'
Although I don't know the details off the top of my head (I seem to recall the word "diversion" being used in the apt output), it might help to look at how moreutils and parallel deal with /usr/bin/parallel.
I believe how it works is moreutils is allowed to have /usr/bin/parallel until GNU Parallel gets installed, at which point something moves it to /usr/bin/parallel.moreutils. For me, the GNU Parallel version is just a lot more useful, so I don't miss the other one.
Not sure it's worth the effort for the bat project (or the Debian package maintainers) to use the Debian "alternatives" system for this, but it's also a facility that exists for situations like this. Its typical use on a Debian/Ubuntu system is to provide symlinks like (already mentioned above)x-terminal-emulator and x-www-browser that point to your best available / preferred terminal, browser, and text editor.
Update: Turns out I commented my own self about this on #982, and the something that moves moreutils' version of parallel to /usr/bin/parallel.moreutils is the following diversion(s) installed by GNU Parallel:
$ dpkg-divert --list | grep parallel
diversion of /usr/share/man/man1/parallel.1.gz to /usr/share/man/man1/parallel.moreutils.1.gz by parallel
diversion of /usr/bin/parallel to /usr/bin/parallel.moreutils by parallel
Hi Kevin,
That is probably achieved with the alternatives system, yes.
The issue here is that it is Debian's policy for alternatives to only be allowed when the two programs offer more or less the same functionality.
In Debian, the bat binary and the batcat binary are completely unrelated (bat is the Bacula Administration Tool)
What would be possible, though, would be having batcat as an alternative for the classic cat, since the two are really similar. bat would have to behave differently when invoked as cat, though.
Il 14 aprile 2025 05:27:27 CEST, Kevin Ernst @.***> ha scritto:
ernstki left a comment (sharkdp/bat#2455)
Although I don't know the details off the top of my head (although I seem to recall the word "diversion" being used in the
aptoutput), it might help to look at howmoreutilsandparalleldeal with/usr/bin/parallel.I believe how it works is moreutils is allowed to have
/usr/bin/paralleluntil GNU Parallel is installed, at which point something moves it to/usr/bin/parallel.moreutils. For me, the GNU Parallel version is just a lot more useful, so I don't miss the other one.Not sure it's worth the effort for the bat project (or the Debian package maintainers) to use the Debian "alternatives" system for this, but it's a thing that exists. It's typical use on a Debian system is to provide symlinks like
x-terminal-emulatorandx-www-browserthat point to your best available / preferred text editor and browser.
In Debian, the
batbinary and thebatcatbinary are completely unrelated (batis the Bacula Administration Tool)
Ah, good point. That makes it tough from a policy perspective then, because the other ones I mentioned do have overlapping functionality. Bacula has been around since people used CVS for version control, so it definitely wins on seniority, and clearly both projects win on coming up with awesome punny names. ;)
It's perhaps not optimal for casual / first-time Debian users, but at a certain experience level, you really don't really bat an eye at having to
cd /usr/bin
sudo ln -s batcat bat
…just one time on the system, after initially installing the bat package.
Perhaps the Debian post-install script could just ask the user (at whatever priority level would trigger a prompt when installed from a terminal) if they wanted to do this?
To be fair, this overlapping of executable names doesn't come without conflicts on other distros:
https://aur.archlinux.org/packages/bacula-client#comment-1018300
I don't know how to check the package itself on other distros, though.
So, with a much better understanding of diversions now, two years later, I can more confidently suggest:
sudo dpkg-divert --rename --divert /usr/bin/bat /usr/bin/batcat
sudo dpkg-divert --rename --divert /usr/sbin/bacula-bat /usr/sbin/bat
The order in which the above commands are invoked doesn't appear to matter, but in English, they mean:
-
for any package (namely bat) that attempts to install
/usr/bin/batcat, rename it to/usr/bin/bat -
for any package (namely, bacula-console-qt) that attempts to install
/usr/sbin/bat, rename it to/usr/sbin/bacula-bat
As mentioned above, there is a precedent for this in Debian, with GNU Parallel diverting moreutils' /usr/bin/parallel to parallel.moreutils, so I believe this is not a misuse of diversions, policy-wise. Perhaps this is a soluble problem, for whomever packages bat.
The assumption being that if one installs the "bat" package, one wants it available as /usr/bin/bat, and is willing to abide bacula-bat for Bacula's version, if also installed.
In any event, when run manually, the two commands above will account for both bats that exist in Debian / Ubuntu repositories as of this writing, with bat as bat, as expected, and without leaving any dangling symlinks if one or the other package is uninstalled.