There have been some instances where I installed a utility/program and the name of the command is different from the name of the program.

Like I installed PostgreSQL recently and after installation I ran the command


but it gave an error bash: postgresql command not found

So I searched upon internet and found that the command to fire postgresql was


So, how do I find out which utility/program to access with what name?

I did apt-cache show postgresql but even there it wasn't mentioned that the program would be accessed with the command psql

Please do not suggest locate command. It doesn't help.

  • Although I think this is a good question, I don't believe there's an answer to it. If I make an utility called x and call my executable y and I do not document it, there's no way of telling what the name of my executable is. This is a bad design choice on the side of the developers. Of course, you can install the package and look what new files you have on disk, but given that some packages install thousands of files, this procedure is not more straight forward than just googling for its name.
    – pfnuesel
    Jul 30, 2017 at 22:37
  • like many other programs, postgresql is something that you really ought to read the documentation for....if you don't know enough about to even know what the command-line client is called, how much do you really expect to be able to do with it?
    – cas
    Jul 31, 2017 at 6:54
  • 1
    @cas nobody knows anything until they start Jul 31, 2017 at 6:59
  • 1
    @GypsyCosmonaut - yeah, that's why reading some documentation is generally a good idea.
    – cas
    Jul 31, 2017 at 7:07

2 Answers 2


One tactic would be to investigate what files the package installed into the various bin directories. For instance, on a dpkg-based distribution, you might do something like:

dpkg -L postgresql-client-9.3 | grep bin

or on a system using RPMs you might do something like:

dnf repoquery -l PACKAGE_NAME | grep bin

and then read the manual pages for the binaries you find. A challenges of this tactic is that in some cases (such as postgresql) the files are spread out over a few packages.

  • Package name in my kali (based on debian) repository is postgresql only so I did dpkg -L postgresql | grep bin but it did not list anything althought the package is located at /usr/bin/psql Jul 30, 2017 at 22:44
  • 1
    @GypsyCosmonaut postgresql probably depends on a version-specific postgresql package which in turn depends on other packages. Try apt-cache depends postgresql to see what that package depends on.
    – Steven D
    Jul 30, 2017 at 22:46
  • apt-cache depends postgresql gives me Depends: postgresql-9.6 so I did dpkg -L postgresql-9.6 | grep bin this time and files from /usr/lib/postgresql/9.6/bin were listed in which there was no mention of psql because that file exists at /usr/bin/psql which was not listed in the result Jul 30, 2017 at 22:52
  • 1
    Unfortunately, for the postgresql package, you would need to keep digging. psql is shipped as part of the client package (likely: postgresql-client-9.6) which is a dependency of postgresql-9.6
    – Steven D
    Jul 30, 2017 at 22:54
  • 1
    this kind of task is part of the reason i wrote dlocate for debian (also because dpkg -L and dpkg -S were and still are slow). e.g. dlocate --lsbin postgresql-client-9.6 will show you all the binaries in that package. dlocate also has --lsman and --lsconf and other options.
    – cas
    Jul 31, 2017 at 6:51

apropos or man -k

This will do a search of installed manual pages related to your keyword. I would enter postgres as the keyword. On my system I get this:

$ apropos postgres
pam_postgresok (8)   - simple check of real UID and corresponding account name
pgsql_table (5)      - Postfix PostgreSQL client configuration

Not the answer you're looking for? Browse other questions tagged .