5

I want to install a local tar file in such a way that it's immediately available on the command line, just as if I had used "sudo apt-get install XYZ" (assume there are no dependencies).

I know how to unpack the tar and then compile with configure/make, but that just leaves me with an executable that I have to add a path to later.

I suppose I could copy to /bin and be done with it, but I was just wondering what the standard practice was here.

As a bonus, it would be nice to know how to do this with RPM's and other types of packages as well.

closed as too broad by Jeff Schaller, Scott, Satō Katsura, Rui F Ribeiro, Archemar Sep 2 '17 at 21:00

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Does the tar file contain files in various usable paths, such that you could extract it from / and have the binaries land in /usr/bin or /usr/local/bin and ditto the man pages and libraries? – Jeff Schaller Sep 2 '17 at 3:40
  • It wasn't really a specific tar I had in mind, just the general case I was wondering about. Not sure if that would be a great idea anyway. I mean, it could possibly clobber a file/directory, couldn't it? – Sir Galahad Sep 2 '17 at 4:08
  • 1
    @JeffSchaller -C / is probably easier. – Hauke Laging Sep 2 '17 at 8:38
  • Use stow – Gilles Sep 2 '17 at 22:53
5

If the program you want to install follows good practice, you can install it with

./configure
make
make install

./configure checks if your system meets all requirements and configures the install options. make compiles everything, and make install copies all necessary files to the right places. You don't want to do the last step by hand, because it will be quite tedious to get all the libraries, man pages and whatnot to the right place.

You can also define where the packages should be installed. For example, if you want to install a package in your home directory (because e.g. you don't have admin rights), you can use

./configure --prefix="$HOME"/somefolder

make install will then install it to this folder. Usually you won't need this, though.

  • Ah, yeah I just tried that with one particular tar I had and it seemed to work as you described. But that "prefix" switch still might come in handy someday, so I'll keep that trick in mind too. Edit: sorry, not enough reps to accept or upvote, but as far as I'm concerned this issue is resolved. Thanks for the help! – Sir Galahad Sep 2 '17 at 1:53
  • You should always have enough rep to accept an answer. Otherwise the system would be broken (IMHO). But anyway, glad it works! – pfnuesel Sep 2 '17 at 2:16
  • Weird, yeah I can accept it now (still can't upvote, that takes 15 reps apparently). – Sir Galahad Sep 2 '17 at 2:40
  • Note that if your home directory might have spaces in its name--I've seen this on some macOS systems--then $HOME will need to be enclosed in double quotes. – Eliah Kagan Sep 2 '17 at 4:16
  • This is of course true, and it's generally good advice to quote variables in bash. I edited my answer. – pfnuesel Sep 2 '17 at 4:19
7

This answer is based on several chat messages I posted, which now serve as an extended summary.

The $PATH Environment Variable

By "immediately available on the command line," I assume you mean that you can run it like name, rather than having to type something like /path/to/name, such as /home/galahad/bin/name or ./name.

Your $PATH environment variable contains a list of :-separated directory names. When you run a command in your shell that contains a / character, it's interpreted as the exact location and name of an executable to run. But when you run a command that does not contain a /, your shell searches the directories in $PATH for executables by that name, and runs the first one it finds. (It may also remember where executables you've run before are located. So, in practice, it does not have to search them each time.)

This is why ./name is the common way to run the executable called name located in the current directory. Running name instead would search the directories in $PATH.

If you run echo "$PATH" you will see something like this, though it may well not be exactly this:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Directories in $PATH don't have to be called bin, but this is common.

Configuring Your Build

When you have source code that is compiled by running ./configure and make, you will usually use make install (or sudo make install) to install it. This copies files from the build directory into the install location. When the thing you are installing provides executable commands, those executables are typically copied into a directory that is in $PATH or that you should consider adding to $PATH.

Although building and installing software is often as simple as running ./configure, make, sometimes make check or make test, and then make install or sudo make install, you will sometimes want to pass options to the configure script to configure the build. In particular, as pfnuesel says, this is how you configure where the software is going to be installed. Even though the make install step actually installs the software, the locations where everything will be installed are typically established in the ./configure step.

The most common option for this is --prefix. The default prefix, when you don't tell configure what to use, is usually /usr/local. (Occasionally, a program or library's source code defaults to some other prefix. Fortunately this is rare.)

So ./configure is usually equivalent to ./configure --prefix=/usr/local. To install software in your home directory, you could use ./configure --prefix=/home/galahad (if /home/galahad is your home directory) or --prefix="$HOME". Then of course you must still build and install the software with make. I should say that not all software that is distributed in source code form is built this way. You should always look for documentation inside the extracted source code archive.

What --prefix Means

When you run ./configure --prefix=directory, you are indicating that the software should be installed under the directory directory. But this rarely, if ever, places loose files in directory. Instead, it places files that serve different purposes in the different subdirectories of directory. If those subdirectories don't exist, it creates them.

Executables usually go in directory/bin, though they may go in directory/sbin if they're commonly used for system administration or they may go (more rarely, these days) in directory/games if they are games. Libraries go in directory/lib or another similarly named directory like directory/lib32. Header files go in directory/include. Manual pages go in directory/man. Data files used by the software go in directory/share.

That's what it means for directory to be a prefix. It's the parent directory that contains the locations in which different files will be installed. It thus appears as a prefix in the absolute paths of most files and directories created by running make install or sudo make install.

There are some exceptions to this. Systemwide configuration files--which are sometimes created when installing the software that will use them, though not always--usually go in /etc. This is not typically affected by specifying a different prefix. Even if you install a lot of software in /usr/local, it will still mostly use /etc, and your /usr/local/etc directory will probably be nonexistent, empty, or contain very few files.

On many systems, you can find more information about typical filesystem layout by running man hier. If you're using a GNU/Linux system you may be interested in the Filesystem Hierarchy Standard.

Where Your System Installs Software

Most of the programs that are part of your system, including programs installed by package managers in the vast majority of GNU/Linux operating systems (GoboLinux being one exception) and some other Unix-like systems, are installed with a prefix of /usr. It is rare that you should pass that prefix to ./configure, because you generally want to avoid conflicts with system-provided software.

/usr is permitted to be on a network share or a partition that is otherwise not yet mounted very early in the boot process. Software that must be accessible at this time is usually installed in /. That's why both /usr/bin and /bin exist and why sh is usually /bin/sh.

Package Management

Most package managers have support for installing binaries (though there are exceptions). Usually when you install software in a GNU/Linux system with your package manager, you are installing binary packages. In this case, the package manager doesn't compile anything itself. However, installation still involves copying or extracting files to locations in the filesystem.

This is what I mean when I say your package manager installs most things with a prefix of /usr. I do not mean it necessarily runs ./configure --prefix=/usr or any ./configure command.

Different operating systems have different package managers. If you're using a distribution like Debian or Ubuntu that is designed for you to use utilities like dpkg, apt-get, and aptitude, then you should not typically attempt to install software with rpm, yum, and dnf.

But the core principle is the same across package managers. When a package manager installs a command, it usually goes in a directory that is expected to be in users' $PATH environment variables. In GNU/Linux systems the package manager usually manages the whole system--except whatever you install yourself in other ways--and thus installs most software with a prefix /usr, thereby placing most executable commands in /usr/bin. (Of course, like running make install or sudo make install, package managers usually install other files to other locations as well.)

Not the answer you're looking for? Browse other questions tagged or ask your own question.