How to get Linux distribution name and version?
You might want to edit the title to make it clear the question is about doing it from C source, not as a script writer or user at the command line.
@Kolob Those were most emphatically not «more sensible» for this question; I have rolled back your change.
9 Answers 9
+1 this finally was «standardized» among the distro’s. Go back far enough though and this file doesn’t exist, instead each distro put their own file like /etc/redhat-release.
This will only work on LSB compliant Linux distributions, but is not guaranteed to work on non-compliant distributions. OTOH, it will also work on other LSB compliant non-Linux Unices. E.g. I’m pretty sure it won’t work on Adroid.
Note that on e.g. Gentoo Linux lsb_release is not always present by default. I just checked, and it’s provided by an optional package sys-apps/lsb-release, currently not installed on my system.
Will lsb-release works on all the follow Distrubtions?: Debian / Ubuntu | Red Hat Enterprise / Fedora Linux / Suse Linux / Cent OS ?
on my system yields the following from the bash (terminal) prompt:
Ubuntu 10.04.4 LTS 2.6.32-41-generic x86_64 I believe uname -mr returns the version of the Linux Kernel, so ‘lsb_release -ds’ should be all you need for the release name and version, assuming the description format is consistent across releases. Thanks, I was wondering how you were supposed to use the short parameter, I was trying it ‘lsb_release -s’ and was wondering why it was failing. Cheers!
trying this way is an interesting one and less restrictive than lsb-release.
This is the best answer, to only retrieve the name of the distro one can do: cat /etc/*-release | grep ID | head -n1 | cut -d ‘=’ -f2
What’s the purpose of getting that information?
If you’re trying to detect some features or properties of the system (e.g. does it support some syscall or does it have some library), instead of relying on output of lsb_release you should either:
- try to use given features and fail gracefully (e.g. dlopen for libraries, syscall(2) for syscalls and so on)
- make it a part of your ./configure check if applicable (standard FOSS way of automatically recognizing system features/properties)
Note that the first way above applies even if your software is binary-only.
dl = dlopen(module_path, RTLD_LAZY); if (!dl) < fprintf(stderr, "Failed to open module: %s\n", module_path); return; >funcptr = dlsym(dl, module_function); if (!funcptr) < fprintf(stderr, "Failed to find symbol: %s\n", module_function); return; >funcptr(); dlclose(dl); How can i find the location of installed software in linux?
Is there any command that I can use in the console to know the location of installed software in linux? i have copied a xyz.bin from windows machine to linuxdesktop and installed it. more over can you please tell me how to uninstall a software which is installed in linux Thanks in advance
You might be able to use the find command to search for it. Have a look at this unix.stackexchange.com/questions/19369/…
3 Answers 3
to find the path where the binary is linked to.
Other application specific files may reside in
The way a package is installed/uninstalled on Linux depends on either the specific Linux distribution AND the specific package.
Since you have used a .bin file for installation, it is likely that you have an uninstall command specific for your program in the path.
If you provide more information about the package and the Linux distribution, we can give more help.
It depends on the distribution you’re using. Supposing you are using a debian\ubuntu distribution, you can uninstall it by the apt command, using sudo apt-get remove software_name sudo apt-get purge software_name
Of course you need to have root privileges.
The softwares are usually installed in bin folders, in /usr/bin, /home/user/bin and many other places, a nice starting point could be the find command to find the executable name, but it’s usually not a single folder. The software could have components and dependencies in lib,bin and other folders.
Where is installed software stored in Linux? [duplicate]
I’m new to Linux and I want to ask a bit more about packages. In Windows, I download an .exe file and install it. When I install, I define the path where I want that application to be stored. In that folder, I have all the files required for the application. However, when I install a package in Linux using yum or apt-get , I don’t know where the package is installed to and where the required files for that application are stored. I have seen that most of the configurations are in the /etc directory. But why does Linux store the required files for an application in different directories? Can someone tell me how packages are installed, and where and how are they stored? And if my understanding about package management is wrong, please correct me.
If your distribution uses rpm , you can use rpm -q —whatprovides to find the package name for a particular file and then rpm -q -a to find out what files a package installed.
8 Answers 8
Many programs (the binaries/scripts) end up in /bin or /usr/bin with other parts in various configuration directories (often in/under etc ) as you already noted.
For any specific command you can checkout whereis
and it will give you some information about where this command is to be found. You can also try which
@KOU I don’t know the history of this, but it could be so that programs could be updated without messing up the configuration information since it would be in a different directory. This way different versions could use the same config information (assuming the format etc was not changed ie was compatible). I am just surmising here. You’d have to research the history of the Unix/Linux file system for a definite answer.
I’m not sure of the history of the decision to put all system-wide config files in /etc/ , but having one central location for config files makes it very easy to back them up. (Imagine backup up system-wide config files in Windows, where they’re scattered all through the filesystem and registry. )
You can get a list of the files that a given yum package installs by doing:
Then you can run it like so:
(Obviously, replace «yum-utils» in that second one with the name of that package whose file list you’d like to see.)
Under Windows, particularly older versions, it was common for programs to store configuration files and non-constant data in their C:\Program Files directory. This is derived from how programs were usually installed and ran under single-user, non-networked, non-file-permission DOS.
From a security standpoint, this is a bad idea. Places where executable code lives should be separated from modifiable data. That way it’s easier to apply appropriate file permissions to prevent modification of installed binaries by unauthorized users. Similarly library directories which may be updated separately from main executables should also be in a separate directory.
With the advent of Vista and UAC annoyances, this tradition is finally starting to seriously lose traction.
UNIX, and Linux, being a multiuser system from much earlier on, had the tendency to separate executable directories from other directories much earlier, since there was a need to prevent users other than root from modifying installed binaries. It’s also why /usr and even /sbin are sometimes separate partitions — a particularly security conscious admin can mount those partitions readonly and remount them read/write when an install/uninstall needs to happen.
Packages are usually installed from a package manager. There’s various package managers, such as aptitude (Debian and derived distributions), yum (Redhat and derived distributions), pacman (forget which distro this is. ), and others.
The package manager lets you browse repositories, download, install, query, and remove software, much like a sophisticated (and free) «app store.» It assumes responsibility for ensuring dependencies are taken care of and tracking what is currently installed.
Usually the package manager will also allow the same operations on a package you downloaded manually outside of any repositories. Tools are also available if you want to create your own from software you made or compiled yourself.
Since the package itself is NOT an executable file, you don’t have to run an untrusted executable which you don’t really know what it does. (Windows is finally coming around with updates by distributing .msu ‘s instead of .exe ‘s — but .msi ‘s have been around a while. )