How do I make a list of installed applications that are CLI only?

[theKbStockpiler]

I would like to be aware of the CLI only applications that I have installed. There is no menu for them so how do I conveniently know what I have installed?


Thanks in advance!

[Cabhan]

Installed binaries are generally located in /bin, /usr/bin, and /usr/local/bin. So that part is easy.

The harder part is determining if a given binary is CLI-only. I don't know of any 100% way of doing this, but I think something that may work is to look at the shared libraries of the application to see if it links against libX11.so. If it does, it's a GUI application.

There are ways around this (statically-linked instead of dynamically-linked, as a simple example), but this should work for most things.

[theKbStockpiler]

I was wondering If I could check the commands that have been added to bash because thes CLI application should be there as well. Is there a way to do that?

[Cabhan]

I don't entirely understand what you mean by "commands that have been added to bash". The commands that you can execute in the shell are simply programs located in directories in your $PATH variable, which generally include the ones I mentioned above. For instance, you can execute "firefox" from a shell, even though it is obviously not a CLI application.

[theKbStockpiler]

First I forgot that bash just checks its path for excutables and opens them by name if it finds them in its path. Before I wrongly pondered that there must be a html file with a simple list of appliations that some how magically registered with BASH.

My recent thought is that when we use the command name , BASH runs a script to load it as well so in a way BASH somehow, somewhere holds or fetches a lot of info about it that is not realized or appreciated and this would solve my issue.

[Cabhan]

Not quite. Let's imagine that I run the command "firefox" in Bash. All that Bash does is determine the full path of the command (probably /usr/bin/firefox) and then tell the kernel to execute the program at that location (to be more technical, it uses the fork/exec model where it launches a child process, and then has the kernel replace that process with the /usr/bin/firefox binary). The firefox binary then uses functions that communicate with the X server, which is essentially the definition of a graphical application. There is no real difference between a CLI-only application or a GUI application: the only difference is that the latter uses code that causes GUI things to happen.

Hence my above proposal. To communicate with the X server, a program must link with the libX11.so library (as this is where the functions to do so are stored). So if you run "ldd /usr/bin/xterm", you will see that it links against libX11.so. But if you run "ldd /bin/bash", it will not link against libX11.so.

This does not always work, though. For instance, "firefox" is actually a script that eventually executes yet another program (firefox-bin). The "firefox" script is not graphical, but "firefox-bin" is.

And, of course, you could have the reverse effect where you could have a CLI application that performs some sort of diagnostic information on the X server. So it would link against libX11.so, but not actually be a graphical application.

In short, there is no real difference between a CLI application and a GUI application except for the details of the code. So the only foolproof way of doing this without actually executing the program would be to analyse the code of every program, which is obviously infeasible.

This, of course, is why if you run a graphical application without an X server running, the program will execute just fine, but will have errors when it tries to do graphical things. Because nobody knows that the program is graphical until it actually tries to execute graphical code.