Understanding software Installation (configure, make, make install)

This tutorial is aimed at those who have just started using Linux. Generally when users from the Windows background enter the Linux scene,they are totally stumped by the software installation method. They were used to the luxury of double clicking on a single file and getting their software installed. But now they have to type cryptic commands to do the same.

Though the installation instructions tell them what to do, they have no idea what those steps actually do. This article shall explain the basics of software installation. After reading this article you would feel more at home when installing your next software.

Generally beginners tend to search desperately for RPMs since installing RPMs is a real simple task. But this article doesn't talk about RPMs. It deals with the softwares that you generally get in the zipped formats as tarballs.


Details :

Generally you would get Linux software in the tarball format (.tgz) This file has to be uncompressed into any directory using tar command. In case you download a new tarball by the name game.tgz, then you would have to type the following command

$ tar xfvz game.tgz

This would create a directory within the current directory and unzip all the files within that new directory. Once this is complete the installation instructions ask you to execute the 3 (now famous) commands : configure, make & make install. Most of the users do this and successfully install their softwares. But most of the newbies have no idea what this really does. The rest of the article shall explain the meaning of these 3 commands

Each software comes with a few files which are solely for the purpose of installation sake. One of them is the configure script. The user has to run the following command at the prompt

$ ./configure

The above command makes the shell run the script named ' configure ' which exists in the current directory. The configure script basically consists of many lines which are used to check some details about the machine on which the software is going to be installed. This script checks for lots of dependencies on your system. For the particular software to work properly, it may be requiring a lot of things to be existing on your machine already. When you run the configure script you would see a lot of output on the screen , each being some sort of question and a respective yes/no as the reply. If any of the major requirements are missing on your system, the configure script would exit and you cannot proceed with the installation, until you get those required things.

The main job of the configure script is to create a ' Makefile ' . This is a very important file for the installation process. Depending on the results of the tests (checks) that the configure script performed it would write down the various steps that need to be taken (while compiling the software) in the file named Makefile.

If you get no errors and the configure script runs successfully (if there is any error the last few lines of the output would glaringly be stating the error) then you can proceed with the next command which is

$ make

' make ' is actually a utility which exists on almost all Unix systems. For make utility to work it requires a file named Makefile in the same directory in which you run make. As we have seen the configure script's main job was to create a file named Makefile to be used with make utility. (Sometimes the Makefile is named as makefile also)

make would use the directions present in the Makefile and proceed with the installation. The Makefile indicates the sequence, that Linux must follow to build various components / sub-programs of your software. The sequence depends on the way the software is designed as well as many other factors.

The Makefile actually has a lot of labels (sort of names for different sections). Hence depending on what needs to be done the control would be passed to the different sections within the Makefile Or it is possible that at the end of one of the section there is a command to go to some next section.

Basically the make utility compiles all your program code and creates the executables. For particular section of the program to complete might require some other part of the code already ready, this is what the Makefile does. It sets the sequence for the events so that your program does not complain about missing dependencies.

One of the labels present in the Makefile happens to be named ' install ' .

If make ran successfully then you are almost done with the installation. Only the last step remains which is

$ make install

As indicated before make uses the file named Makefile in the same directory. When you run make without any parameters, the instruction in the Makefile begin executing from the start and as per the rules defined within the Makefile (particular sections of the code may execute after one another..thats why labels are used..to jump from one section to another). But when you run make with install as the parameter, the make utility searches for a label named install within the Makefile, and executes only that section of the Makefile.

The install section happens to be only a part where the executables and other required files created during the last step (i.e. make) are copied into the required final directories on your machine. E.g. the executable that the user runs may be copied to the /usr/local/bin so that all users are able to run the software. Similarly all the other files are also copied to the standard directories in Linux. Remember that when you ran make, all the executables were created in the temporary directory where you had unzipped your original tarball. So when you run make install, these executables are copied to the final directories.

Thats it !! Now the installation process must be clear to you. You surely will feel more at home when you begin your next software installation.

Layer-7 filter protocol

L7-filter is a packet classifier for Linux. Unlike most other classifiers, it doesn't just look at simple values such as port numbers. Instead, it does regular expression matching on the application layer data to determine what protocols are being used. Since this classifier is much more processor and memory intensive than others, we recommend that you only use it if you have reason to believe that matching by port (or IP number, etc.) is insufficient for your purposes. L7-filter is right for you if you need: * to match any protocol that uses unpredictable ports (e.g. P2P filesharing) * to match traffic on non-standard ports (e.g. HTTP on port 1111) * to distinguish between protocols which share a port (e.g. P2P filesharing that uses port 80)

Regular Expression

In computing, regular expressions provide a concise and flexible means for identifying strings of text of interest, such as particular characters, words, or patterns of characters. Regular expressions (abbreviated as regex or regexp, with plural forms regexes, regexps, or regexen) are written in a formal language that can be interpreted by a regular expression processor, a program that either serves as a parser generator or examines text and identifies parts that match the provided specification. The following examples illustrate a few specifications that could be expressed in a regular expression: the sequence of characters "car" in any context, such as "car", "cartoon", or "bicarbonate" the word "car" when it appears as an isolated word the word "car" when preceded by the word "blue" or "red" a dollar sign immediately followed by one or more digits, and then optionally a period and exactly two more digits Regular expressions can be much more complex than these examples. Regular expressions are used by many text editors, utilities, and programming languages to search and manipulate text based on patterns. For example, Perl, Ruby and Tcl have a powerful regular expression engine built directly into their syntax. Several utilities provided by Unix distributions—including the editor ed and the filter grep—were the first to popularize the concept of regular expression A regular expression is a pattern describing a certain amount of text. Their name comes from the mathematical theory on which they are based.

Advanced stdin, stdout and redirection

---

You've probably heard of stdout (standard out) and stdin (standard in) before but may not know what they really mean. Basically, when you run a program in the shell like 'ls' or 'grep' the output that it produces is sent to stdout, which is your terminal window. stdin is basically the opposite, instead of getting data from a file, stdin is opened up to a pipe for input to the program. If you have ever put '| less' after a command to control the amount of output you get at once, you've used stdin. By using the pipe symbol (|) you are redirecting the stdout from a program like 'ls' to the stdin of 'less'.

[user@host ~]$ ls -l | less
total 53
drwxr-xr-x   2 suso     suso         1024 Dec  7 19:10 ./
drwxr-xr-x   3 suso     suso         1024 Nov 27 06:32 ../
-rw-------   1 suso     suso        12288 Dec  7 19:21 .ioredirect.phtml.swp
-rw-r--r--   1 suso     suso         3763 Dec  6 03:44 bangcharacter.phtml
-rw-r--r--   1 suso     suso         1574 Dec  7 03:29 electricfence-readme
-rw-r--r--   1 suso     suso          127 Nov 27 06:56 footer.phtml
-rw-r--r--   1 suso     suso          219 Dec  6 00:58 header.phtml
-rw-r--r--   1 suso     suso         1496 Dec  7 03:51 index.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 19:10 ioredirect.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 02:49 jobcontrol.phtml
-rw-r--r--   1 suso     suso         5231 Dec  6 03:33 movement.phtml
-rw-r--r--   1 suso     suso         6842 Dec  7 19:09 regularexpressions.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 02:55 regularexpressions.phtml~
-rw-r--r--   1 suso     suso         3680 Dec  5 20:00 shellvariables.phtml
(END)

The output of ls is treated just like it was a file and you had typed less .

Another way you can redirect stdout is by using the angle operators, <>. If you want to send stdout to a file you use '> filename'. If you want to send the contents of a file to the stdin of a program, you can do '<>

[user@host ~]$ ls -l > listoutput
[user@host ~]$ cat listoutput
total 53
drwxr-xr-x   2 suso     suso         1024 Dec  7 19:10 ./
drwxr-xr-x   3 suso     suso         1024 Nov 27 06:32 ../
-rw-------   1 suso     suso        12288 Dec  7 19:21 .ioredirect.phtml.swp
-rw-r--r--   1 suso     suso         3763 Dec  6 03:44 bangcharacter.phtml
-rw-r--r--   1 suso     suso         1574 Dec  7 03:29 electricfence-readme
-rw-r--r--   1 suso     suso          127 Nov 27 06:56 footer.phtml
-rw-r--r--   1 suso     suso          219 Dec  6 00:58 header.phtml
-rw-r--r--   1 suso     suso         1496 Dec  7 03:51 index.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 19:10 ioredirect.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 02:49 jobcontrol.phtml
-rw-r--r--   1 suso     suso         5231 Dec  6 03:33 movement.phtml
-rw-r--r--   1 suso     suso         6842 Dec  7 19:09 regularexpressions.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 02:55 regularexpressions.phtml~
-rw-r--r--   1 suso     suso         3680 Dec  5 20:00 shellvariables.phtml
[user@host ~]$

[root@host /usr/src/linux]# patch -p1 <>
You can also append the output of a program to a file using double
greater-than signs (>>).

[root@host ~]# tail /var/log/messages
Dec  7 18:22:51 host ftpd[26820]: FTP session closed
Dec  7 18:22:52 host ftpd[26821]: ACCESS DENIED (not in any class) TO dhcp-33.domain.net [xxx.xxx.xxx.xxx]
Dec  7 18:22:52 host ftpd[26821]: FTP LOGIN REFUSED (access denied) FROM dhcp-33.domain.net [xxx.xxx.xxx.xxx], xxxxxxxx
Dec  7 18:22:52 host ftpd[26821]: FTP session closed
Dec  7 18:23:04 host ftpd[26825]: FTP LOGIN FROM dhcp-33.domain.net [xxx.xxx.xxx.xxx], xxxxxxxx
Dec  7 18:23:06 host ftpd[26827]: FTP LOGIN FROM dhcp-33.domain.net [xxx.xxx.xxx.xxx], xxxxxxxx
Dec  7 18:26:29 host ftpd[26827]: FTP session closed
Dec  7 19:00:59 host PAM_pwdb[27479]: (su) session opened for user news by (uid=0)
Dec  7 19:01:01 host PAM_pwdb[27479]: (su) session closed for user news
Dec  7 19:59:48 host PAM_pwdb[28448]: (su) session opened for user root by suso(uid=500)
[root@host /root]# echo "Dec  7 20:00:30 host messaged: Hi Mom." >> /var/log/messages
[root@host /root]# tail /var/log/messages
Dec  7 18:22:52 host ftpd[26821]: FTP session closed
Dec  7 18:23:04 host ftpd[26825]: FTP LOGIN FROM dhcp-33.domain.net [xxx.xxx.xxx.xxx], xxxxxxxx
Dec  7 18:23:06 host ftpd[26827]: FTP LOGIN FROM dhcp-33.domain.net [xxx.xxx.xxx.xxx], xxxxxxxx
Dec  7 18:26:29 host ftpd[26827]: FTP session closed
Dec  7 19:00:59 host PAM_pwdb[27479]: (su) session opened for user news by (uid=0)
Dec  7 19:01:01 host PAM_pwdb[27479]: (su) session closed for user news
Dec  7 19:59:48 host PAM_pwdb[28448]: (su) session opened for user root by suso(uid=500)
Dec  7 20:01:00 host PAM_pwdb[28639]: (su) session opened for user news by (uid=0)
Dec  7 20:01:01 host PAM_pwdb[28639]: (su) session closed for user news
Dec  7 20:00:30 host messaged[]: Hi Mom.
[root@host /root]#


There is also stderr which with is like stdout, but is the erroneous output
that comes out of a program.  Sometimes you might be redirecting the output
of a program and you will still see output in your terminal window, this is
stderr output.

[root@host /root]# ls -l /var/log /var/log/httpd/access_og > logslist
ls: /var/log/httpd/access_og: No such file or directory
[root@host /root]#


That line of output that says that the file access_og doesn't exist was sent
by the ls program to stderr, which the > doesn't catch.  If you want to catch the
output of stderr you have to use the n> notation to express which output filehandle
number you wish to use.  In the case of stderr, that number is 2.

[root@host /root]# ls -l /var/log /var/log/httpd/access_og 2> logslist
-rw-------   1 root     root      1463915 Dec  7 20:22 cron
-rw-r--r--   1 root     root         2574 Jan 30  2000 dmesg
-rw-r--r--   1 root     root            0 May  6  1999 htmlaccess.log
drwxr-xr-x   2 root     root        17408 Dec  1 00:04 httpd/
-rw-r--r--   1 root     root       157972 Dec  7 15:10 lastlog
-rw-------   1 root     root       688206 Nov 30 23:40 maillog
-rw-------   1 root     root       365531 Dec  7 20:11 messages
-rw-r--r--   1 root     root            0 Dec  1 00:04 netconf.log
-rw-------   1 root     root       561272 Dec  7 20:19 secure
-rw-r--r--   1 root     root       162275 Dec  7 04:23 spinwebd
-rw-------   1 root     root          337 Dec  7 00:04 spooler
-rw-rw-r--   1 root     utmp        92544 Dec  7 18:26 wtmp
-rw-------   1 root     root            0 Dec  1 00:04 xferlog
[root@host /root]# cat logslist
ls: /var/log/httpd/access_og: No such file or directory
[root@host /root]#


To get both the stdout and stderr to go to a file we use a combination of
> and 2>&1, which means that we want to duplicate the output of file descriptor
1 and put it on file descriptor 2.  So both stdout (1) and stderr(2) get sent
to the file 'logslist'.


$ cat food 2>&1 > file
cat: can't open food
$ cat food file 2>&1
$

Although lots of sh manual pages don't mention this, the shell reads arguments from left to right.

1. On the first command line, the shell sees 2>&1 first. That means "make the standard error (file descriptor 2) go to the same place as the standard output (fd1) is going." There's no effect because both fd2 and fd1 are already going to the terminal. Then >file redirects fd1 (stdout) to file. But fd2 (stderr) is still going to the terminal.

2. On the second command line, the shell sees >file first and redirects stdout to file. Next 2>&1 sends fd2 (stderr) to the same place fd1 is going - that's to the file. And that's what you want.