Score:3

How do I find the package providing an alias?

bn flag

Using apt-file I am able to find the packages providing certain executables like this for example:

sudo apt-file search {/bin,/sbin,/usr/bin/,/usr/sbin}/wget

Well actually:

sudo apt-file search {/bin,/sbin,/usr/bin/,/usr/sbin}/wget | grep "/wget$"

(Because otherwise it would just return all packages containing executables starting with wget.)

Now I was running:

EXEC_NAME="x86_64-w64-mingw32-g++"
sudo apt-file search {/bin,/sbin,/usr/bin/,/usr/sbin}/${EXEC_NAME} | grep "${EXEC_NAME}$"

And surprisingly it doesn't return anything. Why? Because no package provides a file with that name.

If I run:

EXEC_NAME="x86_64-w64-mingw32-g++"
sudo apt-file search {/bin,/sbin,/usr/bin/,/usr/sbin}/${EXEC_NAME}

I get the following result:

g++-mingw-w64-x86-64-posix: /usr/bin/x86_64-w64-mingw32-g++-posix
g++-mingw-w64-x86-64-win32: /usr/bin/x86_64-w64-mingw32-g++-win32

implying there is no package providing x86_64-w64-mingw32-g++.

But after a while I found that g++-mingw-w64-x86-64-posix doesn't just provide the executable g++-mingw-w64-x86-64-posix, but also an alias or symlink called g++-mingw-w64-x86-64.

In this case it was easy to figure out because the package happened to contain another binary with a very similar name. Now my issue is that I need to automate this in a way that works for any alias/symlink, even for ones that have a completely different name.

How can I do this?

Edit:

The alias is created in the file g++-mingw-w64-x86-64-posix.postinst of the g++-mingw-w64-x86-64-posix package, in case that helps:

update-alternatives --install /usr/bin/x86_64-w64-mingw32-g++ x86_64-w64-mingw32-g++ /usr/bin/x86_64-w64-mingw32-g++-posix 30 \
  --slave /usr/bin/x86_64-w64-mingw32-c++ x86_64-w64-mingw32-c++ /usr/bin/x86_64-w64-mingw32-c++-posix

Edit2: Is there maybe a way to search the file content of all packages' .postinst files? Maybe by downloading all .postinst files into a cache? Maybe that could be done by downloading the file header of each package first to see at which bytes in the archives the .postinst files are located and then use HTTP range requests to download them?

Edit3:

This doesn't change anything, but I found instead of grep and cut, you can just use the -x and the -l flag. This makes the command a bit shorter:

sudo apt-file search -l -x "^/(bin|sbin|usr/bin|usr/sbin)/${EXEC_NAME}$" | head -1
mook765 avatar
cn flag
Take a close look at your grep command `grep "${EXEC_NAME}$"`. The second dollar-sign is the culprit.
N0rbert avatar
zw flag
I suppose that you suffer from modern symlink feature. See my [Q&A](https://askubuntu.com/a/1313596/66509) about similar problem with `dpkg -S`. Really you are talking about *alternative*, which is not really an *alias*.
Forivin avatar
bn flag
@mook765 How would that second dollar sign be the culprit? Removing it would cause even more issues as explained in the question.
sudodus avatar
jp flag
It seems to be enough to know the beginnning of the name. You can try with the following command line: `apt-file search {/bin,/sbin,/usr/bin/,/usr/sbin}/name`; You need no `sudo` for this command.
Forivin avatar
bn flag
No this is not enough. It will return all packages containing a binary starting with that name. Very bad practice, extremely unreliable and should be avoided at all costs in a bash script.
sudodus avatar
jp flag
I thought that you used it in order to find the relevant program package, so basically a manual operation supported by a small command line. It is not clear to me what you want. Please explain.
Forivin avatar
bn flag
I need code that takes the name of an executable/alias/... as the input and returns the package name that would install it.
sudodus avatar
jp flag
If the executable is a symbolic link, you may have to follow the link(s) until you find the real executable file, and then I think `apt-file search /full/path/filename` will work. I can do it manually, but it would take some programming to do it in a shellscript. For example I have `rename`: /usr/bin/rename -> /etc/alternatives/rename -> /usr/bin/file-rename (which is Larry Wall's perl script).
Forivin avatar
bn flag
This wouldn't work because the symlink is created by the postinst script. It's not a file contained in the package.
muru avatar
us flag
I think the alternatives system (`update-alternatives`) is managed almost exclusively via maintainer scripts, so this information is not captured some easily searchable database.
James S. avatar
de flag
An alias is not a symbolic link, and a symbolic link is not an alias. Nomenclature is important in order to prevent confusion.
Score:1
cn flag

The problem with symlinks is they aren't necessarily installed by packages.

You can use readlink -f [/path/file] to (try to) get the path to the real file. If /path/file is a symlink, readlink will return the file that the symlink points to. If there is a chain of symlinks, readlink will follow them until it gets to a break in the chain or the real file.

Then you can use apt-file to search for the packages.

Score:1
it flag

If you download dwww with the command

sudo apt install dwww

you can use dwww-quickfind, one of its sub-packages, in order to, well, quickly find it. The following is from the dwww man-page:

dwww-quickfind(8)

        Used by dwww-find(8) to  quickly  find  which
        package a program belongs to.

Just to test out the interface, from the terminal, ran it for 10 - 15 commands, some GNU, others not, without issue. For example, when I ran

:~$ dwww-quickfind man

and the result was

man-db
VIRTUAL: man-db

It obviously follows symlinks, so I would guess that it tracks aliases as well. Either way, It is worth a shot. Even if it doesn't, just getting dwww is worth the trouble. Type dwww <any-pkg> and you will understand.

It is like the man command on steroids.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.