Add note about different command name in Debian/Ubuntu

Question

Add note about different command name in Debian/Ubuntu

septatrix opened this issue 5 years ago · 26 comments

Sadly the packaged version of bat in Debian and Ubuntu (not 19.10) installs the binary as batcat which was very confusing upgrading from 19.10. Maybe we could add a short info under the installation section for Debian/Ubuntu to notify of this difference (and maybe write a mail to the debian packaging team - I do not know if it is their fault and we can change something about this)

Answer 1 · 2020-05-12T01:46:31.000Z

There isn't much we can do about the Debian-maintained package. It had to be changed (see #656) from bat because another package was already using the executable name.

Documenting the fact that apt-get install bat on Debian and Ubuntu installs it as batcat could probably help out. Or maybe if it's possible, the Debian package can add a post-install message about it being installed as batcat? I'm not too familiar with their policies, though.

Answer 2 · 2020-05-12T07:17:32.000Z

I do not know how I feel about post-install messages as I am generally not a big fan of them and they may easily be overlooked. I think the most user friends thing would be to document it in the README and if possible in the page which shows up when typing apt show bat. This way it could quickly be found without going online or using something like dpkg -L bat and most users should stumble upon it.

Answer 3 · 2020-05-12T08:51:00.000Z

I think the most user friends thing would be to document it in the README and if possible in the page which shows up when typing apt show bat.

I made a PR (#986) for documenting it in the README, but it's up to the Debian package maintainers to add a note about the executable name to the package description in apt show bat.

Answer 4 · 2020-05-12T09:00:43.000Z

See also: #905 (comment)

Apart from the README in this repo, this is already documented in pretty much every place that I could think of.

and maybe write a mail to the debian packaging team

@paride as expected (#656 (comment)), the rename of bat to batcat is now starting to cause confusion among users (this ticket, #905, #969). Is there any chance we can start a "petition" or something to get this changed in Ubuntu and/or Debian? (Sorry for bringing this up again)

Answer 5 · 2020-05-12T09:48:58.000Z

The rename is documented in the README.Debian file, which is the designated to document discrepancies between the original package and the Debian version. It's installed in /usr/share/doc/bat/README.Debian. While it's the proper location for this kind of issues, I agree it is not immediately visible.

@eth-p blocking the install process it's something that we generally try to avoid. There is a mechanism for doing so but it's normally used when a new version of the package implements changes the user has to be warned about. I don't think it's appropriate in this case.

We can do a better job in the package description shown by apt show bat (and other package managers). Now the description is auto-generated, but I can override it manually and add a note about the rename. Edit: I forgot I'm doing this already :) Which means that the rename is documented in every sensible place.

@sharkdp I don't think a petition is viable. The Debian policy is clear on this point, and the package already providing a binary named bat is bacula, the backup suite (https://www.bacula.org/), which is a maintained and popular package, packaged in Debian since 2004. I think I can rule out the possibility of overriding it.

Ubuntu inherits the package from Debian as-is, so changes in Debian will land in new Ubuntu releases.

Answer 6 · 2020-05-12T09:55:07.000Z

Yes I just checked the output of apt show bat and indeed it is documented there. Maybe I just tried dpkg -L bat first and noticed it there.
While it is annoying that this change had to happen I can see why Debian enforces this policy and assume most users should notice it in the apt output...

From my point of view we point out the change wherever it is plausible and will close this issue. If someone sees more room for improvement feel free to reopen this.

Answer 7 · 2020-05-12T09:58:02.000Z

The "tail" if the description is a bit confusing:

 This package contains the following binaries built from the Rust crate
 "bat":
  - bat

this part is fully auto-generated by the Debian tooling for packaging Rust crates. I'll check if there's a way for overriding or hiding it, as it's not really useful in this case.

Answer 8 · 2020-05-12T09:59:57.000Z

Oh right, once you investigated that I will close this. Thank you

Answer 9 · 2020-05-12T14:32:46.000Z

Thank you for your replies.

@sharkdp I don't think a petition is viable. The Debian policy is clear on this point, and the package already providing a binary named bat is bacula, the backup suite (https://www.bacula.org/), which is a maintained and popular package, packaged in Debian since 2004. I think I can rule out the possibility of overriding it.

Oh, I definitely wasn't proposing to change anything in the bacula package. I just still believe that the more user-friendly version might be to mark these two packages as conflicting. But I now remember that there was another point about shell scripts which should behave the same way on every Ubuntu installation.

The rename is documented in the README.Debian file

Note that the file currently has a typo: it says batbat instead of batcat.

Another thing: I seem to remember that the package for fd also distributes a fd binary in a non-standard location in addition to the /usr/bin/fdfind binary: /usr/lib/cargo/bin/fd (https://packages.ubuntu.com/de/focal/amd64/fd-find/filelist). This way, users can also extend their PATH instead of creating an alias, which is a cleaner solution overall, I think. Would this be an option for the bat package as well?

Answer 10 · 2020-05-12T15:10:37.000Z

Thank you for your replies.

@sharkdp I don't think a petition is viable. The Debian policy is clear on this point, and the package already providing a binary named bat is bacula, the backup suite (https://www.bacula.org/), which is a maintained and popular package, packaged in Debian since 2004. I think I can rule out the possibility of overriding it.

Oh, I definitely wasn't proposing to change anything in the bacula package. I just still believe that the more user-friendly version might be to mark these two packages as conflicting. But I now remember that there was another point about shell scripts which should behave the same way on every Ubuntu installation.

Yes, and it would prevent users from installing both packages, and it's reasonable to think one could want to use both. Truth is: there is not clean solution other than one of the tools involved renaming the binary.

The rename is documented in the README.Debian file

Note that the file currently has a typo: it says batbat instead of batcat.

Thanks!

Another thing: I seem to remember that the package for fd also distributes a fd binary in a non-standard location in addition to the /usr/bin/fdfind binary: /usr/lib/cargo/bin/fd (https://packages.ubuntu.com/de/focal/amd64/fd-find/filelist). This way, users can also extend their PATH instead of creating an alias, which is a cleaner solution overall, I think. Would this be an option for the bat package as well?

It is possible, but I'm not sure I really like that solution. And the manpage has to be handled in a consistent way. I think symlinking batcat to ~/bin/bat or ~/.local/bin/bat (in PATH by default), or setting up a shell alias is a better and more straightforward solution.

Answer 11 · 2020-05-12T15:39:51.000Z

Mmh, maybe we can ask the user at install time if automatic setup of shell aliases is wanted, making sure that the alises are only valid for interactive shells. I have to think about it. How does it sound to you?

Answer 12 · 2020-05-12T16:01:09.000Z

It is possible, but I'm not sure I really like that solution. And the manpage has to be handled in a consistent way. I think symlinking batcat to ~/bin/bat or ~/.local/bin/bat (in PATH by default), or setting up a shell alias is a better and more straightforward solution.

👍 I have updated the README: 54a85d9 4be66f8

Mmh, maybe we can ask the user at install time if automatic setup of shell aliases is wanted, making sure that the alises are only valid for interactive shells. I have to think about it. How does it sound to you?

Is there any precedent for that? Do other packages do this (or similar things) as well and how common is that? The obvious downside is the interruption in the automatic installation process. On the other hand, bat is rather likely to be installed alone (instead of, say, as a dependency of another package), so this might not be too bad.

Where would that alias be placed? Is there something like a .bashrc.d folder in Ubuntu? Or would if have to be appended to a user config file? How would that even work with apt running under sudo?

In general, I like the symlink solution much better than the alias. This way, bat can be called from scripts. It's also a bit cleaner in the sense that users can add additional bat aliases on top without requiring the right order of aliases.

Answer 13 · 2020-05-12T16:13:19.000Z

It is possible, but I'm not sure I really like that solution. And the manpage has to be handled in a consistent way. I think symlinking batcat to ~/bin/bat or ~/.local/bin/bat (in PATH by default), or setting up a shell alias is a better and more straightforward solution.

+1 I have updated the README: 54a85d9 4be66f8

I'm not sure .local/bin exists by default, you may want to add mkdir -p ... to the instructions if you want them to be a bit more foolproof.

Mmh, maybe we can ask the user at install time if automatic setup of shell aliases is wanted, making sure that the alises are only valid for interactive shells. I have to think about it. How does it sound to you?

Is there any precedent for that? Do other packages do this (or similar things) as well and how common is that? The obvious downside is the interruption in the automatic installation process. On the other hand, bat is rather likely to be installed alone (instead of, say, as a dependency of another package), so this might not be too bad.

I'm not aware of any precedent. I'll certainly ask the debian-devel mailing list, as I agree it's kind of an odd solution.

Where would that alias be placed? Is there something like a .bashrc.d folder in Ubuntu? Or would if have to be appended to a user config file? How would that even work with apt running under sudo?

I was thinking of /etc/profile.d/ and /etc/fish/conf.d/, so system-wide, without touching the user config, and working with sudo.

Answer 14 · 2020-05-12T16:36:11.000Z

I'm not sure .local/bin exists by default, you may want to add mkdir -p ... to the instructions if you want them to be a bit more foolproof.

done 👍

I'm not aware of any precedent. I'll certainly ask the debian-devel mailing list, as I agree it's kind of an odd solution.

Thank you

I was thinking of /etc/profile.d/ and /etc/fish/conf.d/, so system-wide, without touching the user config, and working with sudo.

Sounds good.

Answer 15 · 2020-05-14T10:41:13.000Z

After thinking about it a bit more I don't think adding system-wide aliases is a good idea anymore. Are we going to need to check that aliases do not clash then? And it will only with with specific shells. In general, it's a ugly workaround for something we have to live with: in Debian/Ubuntu the binary has another name. That's it.

I couldn't find a way to easily remove the auto-generated "This package contains the following binaries" boilerplate from the package descriptio, but I filed:

https://salsa.debian.org/rust-team/debcargo/-/issues/36

Let's see what the people that developed the Debian tooling think.

Pity that newer versions of bat can't be easily packaged yet. This is in good part due to dependencies on crates with version 0.x, so every little bump in the version marks the crate backwards incompatible (because semver), and this is a huge mess to handle given that other packages may have dependencies on different versions.

Answer 16 · 2020-05-14T10:45:24.000Z

As I think most points are resolved now I will close this

Answer 17 · 2020-05-15T02:57:39.000Z

As I think most points are resolved now I will close this

There's still one typo need to be fixed

Note that the file currently has a typo: it says batbat instead of batcat.

Answer 18 · 2020-05-15T07:40:06.000Z

The typo was fixed in Debian back in January:

https://salsa.debian.org/rust-team/debcargo-conf/-/commit/0fde65a873b03cf24e15c0dd0e861c18b6736852

Ubuntu Groovy has the updated package.

Answer 19 · 2020-05-15T10:43:04.000Z

Pity that newer versions of bat can't be easily packaged yet. This is in good part due to dependencies on crates with version 0.x, so every little bump in the version marks the crate backwards incompatible (because semver), and this is a huge mess to handle given that other packages may have dependencies on different versions.

Let us know if there is anything we can do here to help.

Answer 20 · 2020-05-16T03:55:41.000Z

The typo was fixed in Debian back in January:

salsa.debian.org/rust-team/debcargo-conf/-/commit/0fde65a873b03cf24e15c0dd0e861c18b6736852

Ubuntu Groovy has the updated package.

Yeah, I was using focal and 'batbat' is still there. Not checked other repositories.

Answer 21 · 2021-09-21T12:36:24.000Z

I get that the Debian maintainers probably can't do this (although it was done with GNU Parallel and moreutils' parallel, so there's a precedent), but if you just want bat to be bat on your Debian/Ubuntu system, you can:

sudo dpkg-divert --package batcat --add --rename --divert /usr/bin/bat /usr/bin/batcat

Answer 22 · 2022-05-28T18:02:51.000Z

Add symlink from batcat to bat (Ubuntu 22.04 LTS):
sudo ln -s /usr/bin/batcat /usr/local/bin/bat

Answer 23 · 2024-08-22T10:59:54.000Z

What about Debian Alternatives?

The Debian alternatives system creates a way for several programs that fulfill the same or similar functions to be listed as alternative implementations that are installed simultaneously but with one particular implementation designated as the default. For example many systems have several text editors installed at the same time. The vi program is a classic example of an editor that has many implementations such as nvi, elvis, vim, etc. but which one should be designated as the default?

Could bat be treated as an alternative for cat?

Would this help with anything discussed in this topic?

Answer 24 · 2024-08-22T12:08:09.000Z

Could bat be treated as an alternative for cat?

No, not at that level. A shell alias is fine but aliasing at the system level will likely break many scripts as bat is too different in its default behavior from cat. The update-alternatives system is more suites towards command which are either drop-in compatible (GCC/Clang, OpenJDK/OracleJDK etc) or are only used interactively (vi/vim/nvim etc)

Answer 25 · 2024-08-24T04:40:26.000Z

Could bat be treated as an alternative for cat?

No, not at that level. A shell alias is fine but aliasing at the system level will likely break many scripts as bat is too different in its default behavior from cat. The update-alternatives system is more suites towards command which are either drop-in compatible (GCC/Clang, OpenJDK/OracleJDK etc) or are only used interactively (vi/vim/nvim etc)

I see. I thought bat acted as a perfect cat replacement when running non-interactively (like bat file.txt > file2.txt)

Answer 26 · 2024-08-24T04:44:14.000Z

Wait.

File concatenation

Even with a pager set, you can still use bat to concatenate files 😉. Whenever bat detects a non-interactive terminal (i.e. when you pipe into another process or into a file), bat will act as a drop-in replacement for cat and fall back to printing the plain file contents, regardless of the --pager option's value.

Doesn't this mean that bat wouldn't break any script?