Thursday, June 21, 2012

GNU Make in Detail for Beginners

By Sarath Lakshman on June 9, 2012 in Developers, How-Tos, Tools / Apps · 2 Comments and 0 Reactions

Have you ever peeked into the source code of any of the applications you run every day? Ever used make install to install some application? You will see make in most projects. It enables developers to easily compile large and complex programs with many components. It’s also used for writing maintenance scripts based on timestamps. This article shows you how to have fun with make.

Large projects can contain thousands of lines of code, distributed in multiple source files, written by many developers and arranged in several subdirectories. A project may contain several component divisions. These components may have complex inter-dependencies — for example, in order to compile component X, you have to first compile Y; in order to compile Y, you have to first compile Z; and so on. For a large project, when a few changes are made to the source, manually recompiling the entire project each time is tedious, error-prone and time-consuming.

Make is a solution to these problems. It can be used to specify dependencies between components, so that it will compile components in the order required to satisfy dependencies. An important feature is that when a project is recompiled after a few changes, it will recompile only the files which are changed, and any components that are dependent on it. This saves a lot of time. Make is, therefore, an essential tool for a large software project.

Each project needs a Makefile — a script that describes the project structure, namely, the source code files, the dependencies between them, compiler arguments, and how to produce the target output (normally, one or more executables). Whenever the make command is executed, the Makefile in the current working directory is interpreted, and the instructions executed to produce the target outputs. The Makefile contains a collection of rules, macros, variable assignments, etc. (‘Makefile’ or ‘makefile’ are both acceptable.)

Installing GNU Make

Most distributions don’t ship make as part of the default installation. You have to install it, either using the package-management system, or by manually compiling from source. To compile and build from source, download the tarball, extract it, and go through the README file. (If you’re running Ubuntu, you can install make as well as some other common packages required for building from source, by running: sudo apt-get install build-essential.)

A sample project

To acquaint ourselves with the basics of make, let’s use a simple C “Hello world” project, and a Makefile that handles building of the target binary. We have three files (below): module.h, the header file that contains the declarations; module.c, which contains the definition of the function defined in module.h; and the main file, main.c, in which we call the sample_func() defined inmodule.c. Since module.h includes the required header files like stdio.h, we don’t need to include stdio.h in every module; instead, we just include module.h. Here, module.c andmain.c can be compiled as separate object modules, and can be linked by GCC to obtain the target binary.

module.h:

#include 

void sample_func();

module.c:

#include "module.h"

void sample_func()

{

    printf("Hello world!");

}

main.c:

#include "module.h"

void sample_func();

int main()

{

    sample_func();

    return 0;

}

The following are the manual steps to compile the project and produce the target binary:

slynux@freedom:~$ gcc -I . -c main.c # Obtain main.o

slynux@freedom:~$ gcc -I . -c module.c # Obtain module.o

slynux@freedom:~$ gcc main.o module.o -o target_bin #Obtain target binary

(-I is used to include the current directory (.) as a header file location.)

Writing a Makefile from scratch

By convention, all variable names used in a Makefile are in upper-case. A common variable assignment in a Makefile is CC = gcc, which can then be used later on as ${CC} or $(CC). Makefiles use # as the comment-start marker, just like in shell scripts.

The general syntax of a Makefile rule is as follows:

target: dependency1 dependency2 ...

[TAB] action1

[TAB] action2

    ...

Let’s take a look at a simple Makefile for our sample project:

all: main.o module.o

    gcc main.o module.o -o target_bin

main.o: main.c module.h

    gcc -I . -c main.c

module.o: module.c module.h

    gcc -I . -c module.c

clean:

    rm -rf *.o

    rm target_bin

We have four targets in the Makefile:

all is a special target that depends on main.o and module.o, and has the command (from the “manual” steps earlier) to make GCC link the two object files into the final executable binary.
main.o is a filename target that depends on main.c and module.h, and has the command to compile main.c to produce main.o.
module.o is a filename target that depends on module.c and module.h; it calls GCC to compile the module.c file to produce module.o.
clean is a special target that has no dependencies, but specifies the commands to clean the compilation outputs from the project directories.

You may be wondering why the order of the make targets and commands in the Makefile are not the same as that of the manual compilation commands we ran earlier. The reason is so that the easiest invocation, by just calling the make command, will result in the most commonly desired output — the final executable. How does this work?

The make command accepts a target parameter (one of those defined in the Makefile), so the generic command line syntax is make . However, make also works if you do not specify any target on the command line, saving you a little typing; in such a case, it defaults to the first target defined in the Makefile. In our Makefile, that is the target all, which results in the creation of the desired executable binary target_bin!

Makefile processing, in general

When the make command is executed, it looks for a file named makefile or Makefile in the current directory. It parses the found Makefile, and constructs a dependency tree. Based on the desired make target specified (or implied) on the command-line, make checks if the dependency files of that target exist. And (for filename targets — explained below) if they exist, whether they are newer than the target itself, by comparing file timestamps.

Before executing the action (commands) corresponding to the desired target, its dependencies must be met; when they are not met, the targets corresponding to the unmet dependencies are executed before the given make target, to supply the missing dependencies.

When a target is a filename, make compares the timestamps of the target file and its dependency files. If the dependency filename is another target in the Makefile, make then checks the timestamps of that target’s dependencies. It thus winds up recursively checking all the way down the dependency tree, to the source code files, to see if any of the files in the dependency tree are newer than their target filenames. (Of course, if the dependency files don’t exist, then make knows it must start executing the make targets from the “lowest” point in the dependency tree, to create them.)

If make finds that files in the dependency tree are newer than their target, then all the targets in the affected branch of the tree are executed, starting from the “lowest”, to update the dependency files. When make finally returns from its recursive checking of the tree, it completes the final comparison for the desired make target. If the dependency files are newer than the target (which is usually the case), it runs the command(s) for the desired make target.

This process is how make saves time, by executing only commands that need to be executed, based on which of the source files (listed as dependencies) have been updated, and have a newer timestamp than their target.

Now, when a target is not a filename (like all and clean in our Makefile, which we called “special targets”), make obviously cannot compare timestamps to check whether the target’s dependencies are newer. Therefore, such a target is always executed, if specified (or implied) on the command line.

For the execution of each target, make prints the actions while executing them. Note that each of the actions (shell commands written on a line) are executed in a separate sub-shell. If an action changes the shell environment, such a change is restricted to the sub-shell for that action line only. For example, if one action line contains a command like cd newdir, the current directory will be changed only for that line/action; for the next line/action, the current directory will be unchanged.

Processing our Makefile

After understanding how make processes Makefiles, let’s run make on our own Makefile, and see how it is processed to illustrate how it works. In the project directory, we run the following command:

slynux@freedom:~$ make

gcc -I . -c main.c

gcc -I . -c module.c

gcc main.o module.o -o target_bin

What has happened here?

When we ran make without specifying a target on the command line, it defaulted to the first target in our Makefile — that is, the target all. This target’s dependencies are module.o and main.o. Since these files do not exist on our first run of make for this project, make notes that it must execute the targets main.o and module.o. These targets, in turn, produce the main.o andmodule.o files by executing the corresponding actions/commands. Finally, make executes the command for the target all. Thus, we obtain our desired output, target_bin.

If we immediately run make again, without changing any of the source files, we will see that only the command for the target all is executed:

slynux@freedom:~$ make

gcc main.o module.o -o target_bin

Though make checked the dependency tree, neither of the dependency targets (module.o andmain.o) had their own dependency files bearing a later timestamp than the dependency target filename. Therefore, make rightly did not execute the commands for the dependency targets. As we mentioned earlier, since the target all is not a filename, make cannot compare file timestamps, and thus executes the action/command for this target.

Now, we update module.c by adding a statement printf("\nfirst update"); inside thesample_func() function. We then run make again:

slynux@freedom:~$ make

gcc -I . -c module.c

gcc main.o module.o -o target_bin

Since module.c in the dependency tree has changed (it now has a later timestamp than its target, module.o), make runs the action for the module.o target, which recompiles the changed source file. It then runs the action for the all target.

We can explicitly invoke the clean target to clean up all the generated .o files and target_bin:

$ make clean

rm -rf *.o

rm target_bin

More bytes on Makefiles

Make provides many interesting features that we can use in Makefiles. Let’s look at the most essential ones.

Dealing with assignments

There are different ways of assigning variables in a Makefile. They are (type of assignment, followed by the operator in parentheses):

Simple assignment (:=)

We can assign values (RHS) to variables (LHS) with this operator, for example: CC := gcc. With simple assignment (:=), the value is expanded and stored to all occurrences in the Makefile when its first definition is found.

For example, when a CC := ${GCC} ${FLAGS} simple definition is first encountered, CC is set togcc -W and wherever ${CC} occurs in actions, it is replaced with gcc -W.

Recursive assignment (=)

Recursive assignment (the operator used is =) involves variables and values that are not evaluated immediately on encountering their definition, but are re-evaluated every time they are encountered in an action that is being executed. As an example, say we have:

GCC = gcc

FLAGS = -W

With the above lines, CC = ${GCC} {FLAGS} will be converted to gcc -W only when an action like ${CC} file.c is executed somewhere in the Makefile. With recursive assignation, if the GCC variable is changed later (for example, GCC = c++), then when it is next encountered in an action line that is being updated, it will be re-evaluated, and the new value will be used; ${CC}will now expand to c++ -W.

We will also have an interesting and useful application further in the article, where this feature is used to deal with varying cases of filename extensions of image files.

Conditional assignment (?=)

Conditional assignment statements assign the given value to the variable only if the variable does not yet have a value.

Appending (+=)

The appending operation appends texts to an existing variable. For example:

CC = gcc

CC += -W

CC now holds the value gcc -W.

Though variable assignments can occur in any part of the Makefile, on a new line, most variable declarations are found at the beginning of the Makefile.

Using patterns and special variables

The % character can be used for wildcard pattern-matching, to provide generic targets. For example:

%.o: %.c

[TAB] actions

When % appears in the dependency list, it is replaced with the same string that was used to perform substitution in the target.

Inside actions, we can use special variables for matching filenames. Some of them are:

$@ (full target name of the current target)
$? (returns the dependencies that are newer than the current target)
$* (returns the text that corresponds to % in the target)
$< (name of the first dependency)
$^ (name of all the dependencies with space as the delimiter)

Instead of writing each of the file names in the actions and the target, we can use shorthand notations based on the above, to write more generic Makefiles.

Action modifiers

We can change the behaviour of the actions we use by prefixing certain action modifiers to the actions. Two important action modifiers are:

- (minus) — Prefixing this to any action causes any error that occurs while executing the action to be ignored. By default, execution of a Makefile stops when any command returns a non-zero (error) value. If an error occurs, a message is printed, with the status code of the command, and noting that the error has been ignored. Looking at the Makefile from our sample project: in the clean target, the rm target_bin command will produce an error if that file does not exist (this could happen if the project had never been compiled, or if make cleanis run twice consecutively). To handle this, we can prefix the rm command with a minus, to ignore errors: -rm target_bin.
@ (at) suppresses the standard print-action-to-standard-output behaviour of make, for the action/command that is prefixed with @. For example, to echo a custom message to standard output, we want only the output of the echo command, and don’t want to print the echo command line itself. @echo Message will print “Message” without the echo command line being printed.

Use PHONY to avoid file-target name conflicts

Remember the all and clean special targets in our Makefile? What happens when the project directory has files with the names all or clean? The conflicts will cause errors. Use the .PHONYdirective to specify which targets are not to be treated as files — for example: .PHONY: all clean.

Simulating make without actual execution

At times, maybe when developing the Makefile, we may want to trace the make execution (and view the logged messages) without actually running the actions, which is time consuming. Simply use make -n to do a “dry run”.

Using the shell command output in a variable

Sometimes we need to use the output from one command/action in other places in the Makefile — for example, checking versions/locations of installed libraries, or other files required for compilation. We can obtain the shell output using the shell command. For example, to return a list of files in the current directory into a variable, we would run: LS_OUT = $(shell ls).

Nested Makefiles

Nested Makefiles (which are Makefiles in one or more subdirectories that are also executed by running the make command in the parent directory) can be useful for building smaller projects as part of a larger project. To do this, we set up a target whose action changes directory to the subdirectory, and invokes make again:

subtargets:

    cd subdirectory && $(MAKE)

Instead of running the make command, we used $(MAKE), an environment variable, to provide flexibility to include arguments. For example, if you were doing a “dry run” invocation: if we used the make command directly for the subdirectory, the simulation option (-n) would not be passed, and the commands in the subdirectory’s Makefile would actually be executed. To enable use of the -n argument, use the $(MAKE) variable.

Now let’s improve our original Makefile using these advanced features:

CC = gcc # Compiler to use

OPTIONS = -O2 -g -Wall # -g for debug, -O2 for optimise and -Wall additional messages

INCLUDES = -I . # Directory for header file

OBJS = main.o module.o # List of objects to be build

.PHONY: all clean # To declare all, clean are not files

all: ${OBJS}

    @echo "Building.." # To print "Building.." message

    ${CC} ${OPTIONS} ${INCLUDES} ${OBJS} -o target_bin 

%.o: %.c  # % pattern wildcard matching

    ${CC} ${OPTIONS} -c $*.c ${INCLUDES}

list:

    @echo $(shell ls) # To print output of command 'ls'

clean:

    @echo "Cleaning up.."

    -rm -rf *.o # - prefix for ignoring errors and continue execution

    -rm target_bin

Run make on the modified Makefile and test it; also run make with the new list target. Observe the output.

Make in non-compilation contexts

I hope you’re now well informed about using make in a programming context. However, it’s also useful in non-programming contexts, due to the basic behaviour of checking the modification timestamps of target files and dependencies, and running the specified actions when required. For example, let’s write a Makefile that will manage an image store for us, doing thumbnailing when required. Our scenario is as follows:

We have a directory with two subdirectories, images and thumb.
The images subdirectory contains many large image files; thumb contains thumbnails of the images, as .jpg files, 100x100px in image size.
When a new image is added to the images directory, creation of its thumbnail in the thumbdirectory should be automated. If an image is modified, its thumbnail should be updated.
The thumbnailing process should only be done for new or updated images, and not images that have up-to-date thumbnails.

This problem can be solved easily by creating a Makefile in the top-level directory, as follows:

FILES = $(shell  find images -type f -iname "*.jpg" | sed 's/images/thumb/g')

CONVERT_CMD = convert -resize "100x100" $< $@

MSG = @echo "\nUpdating thumbnail" $@

all: ${FILES}

thumb/%.jpg: images/%.jpg

    $(MSG)

    $(CONVERT_CMD)

thumb/%.JPG: images/%.JPG

    $(MSG)

    $(CONVERT_CMD)

clean:

    @echo Cleaning up files..

    rm -rf thumb/*.jpg thumb/*.JPG

In the above Makefile, FILES = $(shell find images -type f -iname "*.jpg" | sed 's/images/thumb/g') is used to generate a list of dependency filenames. JPEG files could have the extension .jpg or .JPG (that is, differing in case). The -iname parameter to find (find images -type f -iname "*.jpg") will do a case-insensitive search on the names of files, and will return files with both lower-case and upper-case extensions — for example, images/1.jpg,images/2.jpg, images/3.JPG and so on. The sed command replaces the text “images” with “thumb”, to get the dependency file path.

When make is invoked, the all target is executed first. Since FILES contains a list of thumbnail files for which to check the timestamp (or if they exist), make jumps down to the thumb/%.jpgwildcard target for each thumbnail image file name. (If the extension is upper-case, that is,thumb/3.JPG, then make will look for, and find, the second wildcard target, thumb/%.JPG.)

For each thumbnail file in the thumb directory, its dependency is the image file in the imagesdirectory. Hence, if any file (that’s expected to be) in the thumb directory does not exist, or its timestamp is older than the dependency file in the images directory, the action (calling$(CONVERT_CMD) to create a thumbnail) is run.

Using the features we described earlier, CONVERT_CMD is defined before targets are specified, but it uses recursive assignment. Hence, the input and target filenames passed to the convert command are substituted from the first dependency ($<) and the target ($@) every time the action is invoked, and thus will work no matter from which action target (thumb/%.JPG orthumb/%.jpg) the action is invoked.

Naturally, the “Updating thumbnail” message is also defined using recursive assignment for the same reasons, ensuring that $(MSG) is re-evaluated every time the actions are executed, and thereby able to cope with variations in the case of the filename extension.

slynux@freedom:~$ make

Updating thumbnail 1.jpg

convert -resize "100x100" images/1.jpg thumb/1.jpg

… …Updating thumbnail 4.jpg

convert -resize "100x100" images/4.jpg thumb/4.jpg

If I edit 4.jpg in images and rerun make, since only 4.jpg‘s timestamp has changed, a thumbnail is generated for that image:

slynux@freedom:~$ make

Updating thumbnail 4.jpg

convert -resize "100x100" images/4.jpg thumb/4.jpg

Writing a script (shell script or Python, etc) to maintain image thumbnails by monitoring timestamps would have taken many lines of code. With make, we can do this in just 8 lines of Makefile. Isn’t make awesome?

That’s all about the basics of using the make utility. Happy hacking till we meet again!

This article was originally published in September 2010 issue of the print magazine.

Wednesday, May 23, 2012

setup of IP camera

http://www.youtube.com/watch?v=ZU_xobdKQOs

Thursday, May 10, 2012

Vim plugin

http://www.thegeekstuff.com/2009/04/ctags-taglist-vi-vim-editor-as-sourece-code-browser/

Ctags and Taglist: Convert Vim Editor to Beautiful Source Code Browser for Any Programming Language

by SATHIYAMOORTHY on APRIL 20, 2009

Photo Courtesy: mint imperial

This article is part of the on-going Vi / Vim Tips and Tricks series. As a programmer or system administrator, you will be constantly browsing source codes and shell scripts.

Following are some typical activities that you may perform while browsing a source code file:

Navigating to the function definition by specifying the function name.
Navigating to the function definition from ‘function call’.
Returning back again to function call from the definition.
Viewing the prototype/signature of functions or variables.
Viewing the number of functions in a file, etc.,

In this article, let us review how to perform the above activities efficiently in Vim editor usingctags and taglist plugin.

The techniques mentioned in this article using Vim editor can be used for any programming language.

I. Ctags Package Install and Configure

Step 1: Installing ctags Package

# apt-get install exuberant-ctags

(or)

# rpm -ivh ctags-5.5.4-1.i386.rpm
warning: ctags-5.5.4-1.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e
Preparing...          ########################################### [100%]
   1:ctags            ########################################### [100%]

Step 2: Generating ctags on your source code

Go to the directory where your source code is located. In the example below, I have stored all my C programming source code under ~/src directory.

# cd ~/src

# ctags *.c

The ctags command will create a filename tags the will contain all required information (tags) about the *.c program files. Following is partial output of the tags entries in the ctags file.

# cat tags
AddAcl  dumputils.c     /^AddAcl(PQExpBuffer aclbuf, const char *keyword)$/;"   f       file:
ArchiveEntry    pg_backup_archiver.c    /^ArchiveEntry(Archive *AHX,$/;"        f
AssignDumpId    common.c        /^AssignDumpId(DumpableObject *dobj)$/;"        f

II. 4 Powerful Ctags Usages inside Vim Editor

1. Navigate to function definition by specifying the function name using :ta

In the example below, :ta main will take you to the main function definition inside the mycprogram.c

# vim mycprogram.c
:ta main

By using this facility you can navigate to any function definition by specifying the function name.

2. Navigating to the function definition from ‘function call’ using Ctrl + ]

When the cursor is under the function call, then press CTRL + ] to go to the function definition. In the following example, when the cursor is in the function call ssh_xcalloc, pressing Ctrl + ] will take you to the ssh_xcalloc function definition.

# vim mycprogram.c
            av = ssh_xcalloc(argc, sizeof(char *));

Note: If the ctags couldn’t find that function, you’ll get the following message in the vim status bar at the bottom: E426 tag not found ssh_xcalloc

3. Returning back again to function call from the definition using Ctrl + t

Press CTRL + t which will take back to the function call again.

4. Navigating through a list of function names which has the similar names

In this example, :ta will go to the function definition whose name starts with get, and also builds a list to navigate with the relevant functions.

# vim mycprogram.c

:ta /^get

Following vim commands can be used to navigate through relevant functions

:ts – shows the list.
:tn – goes to the next tag in that list.
:tp - goes to the previous tag in that list.
:tf – goes to the function which is in the first of the list.
:tl – goes to the function which is in the last of the list.

III. Taglist Plugin: Vim Editor as Ultimate Source Code Browser

The above Ctags might have not given a source code browsing feeling, as it is driven by commands instead of visually browsing the code. So if you want to navigate through the source as like navigating in the file browser, you need to use vim taglist plugin which makes vim as a source code browser.

Author of the vim taglist plugin Yegappan Lakshmanan, says about it as

The “Tag List” plugin is a source code browser plugin for Vim and provides an overview of the structure of source code files and allows you to efficiently browse through source code files for different programming languages.

Step 1: Download the Vim Taglist plugin

Download it from from vim.org website as shown below.

$ cd /usr/src

$ wget -O taglist.zip http://www.vim.org/scripts/download_script.php?src_id=7701

Step 2: Install the TagList Vim Plugin

$ mkdir ~/.vim # if the directory does not exist already

$ cd ~/.vim

$ unzip /usr/src/taglist.zip
Archive:  /usr/src/taglist.zip
  inflating: plugin/taglist.vim
  inflating: doc/taglist.txt

Step 3: Enable the plugin in the ~/.vimrc

Add the following line to the ~/.vimrc to enable the plugin for Vim editor.

$ vim ~/.vimrc
filetype plugin on

Pre-Requisite: ctags should be installed to use taglist plugin. But it is not a must to generate the tag list manually by ctags command for using taglist plugin.

IV. 5 Powerful Features of Taglist Vim Plugin

1. Open the Tag List Window in Vim using :TlistOpen

# vim mycprogram.c
:TlistOpen

From the vim editor, execute :TlistOpen as shown above, which opens the tag list window with the tags of the current file as shown in the figure below.

Function Browser Window inside Vim Editor

Fig: Vim – Source Code Tag/Function List Windows

2. Jump to the Function Definition inside a source code

By clicking on the function name in the left panel, you would be able to go to the definition of the function as shown in the Figure below.

Fig: Jump to a function definition quickly

Apart form jumping to the function names quickly, you can jump to classes, structures, variables, etc., by clicking on the corresponding values from the tag-browser in the left hand side.

3. Jump to the function definition which is in another source file

When you are going through a function in a source file and would want to go to the function definition which is in another file, you can do this in two different methods.

Method 1:

If you had the ctags generated for that file, when the cursor is in the function call pressing CTRL + ] will take you to the function definition. And automatically the tag list window will show the tags for that newly opened file.

Method 2:

Open another file also in the same vim session which will update the tag list window with the information about that file. Search for that function name in the tag list window, and by pressing on that function name in the tag list window you can go to the function definition.

4. Viewing the prototype/signature of functions or variables.

Press ‘space’ in the function name or in the variable name in the tag list window to show the prototype (function signature) of it in the VIM status bar as shown below. In the example below, click on selectDumpableTable function from the Tag-window and press space-bar, which displays the function signature for selectDumptableTable function in the bottom Vim Status bar.

Display Function Prototype inside Vim Editor

Fig: Display Function signature at the Vim Status Bar

5. Viewing the total number of functions or variables in a source code file

press ‘space’ in the tag type in the tag list window, which shows the count of it. In the example below, when the cursor is at ‘function’ press space, which will display the total number of functions in the current source code.

Display Total Number of functions for a source code inside Vim Editor

Fig: Display the total number of functions available in the source code

For effectively writing new source code files using Vim, please refer to our earlier articles:

screen man page

screen Multiplex a physical terminal between several processes (typically interactive shells). Syntax: Start a screen session: screen [ -options ] [ cmd [args] ] Resume a detached screen session: screen -r [[pid.]tty[.host]] screen -r sessionowner/[[pid.]tty[.host]] Options: -A -[r|R] Adapt all windows to the new display width & height. -c file Read configuration file instead of .screenrc -d (-r) Detach the elsewhere running screen (and reattach here). -dmS name Start as daemon: Screen session in detached mode. -D (-r) Detach and logout remote (and reattach here). -D -RR Do whatever is needed to Reattach a screen session. -d -m Start in "detached" mode. Useful for system startup scripts. -D -m Start in "detached" mode, & don't fork a new process. -list List our SockDir and do nothing else (-ls) -r Reattach to a detached screen process. -R Reattach if possible, otherwise start a new session. -t title Set title. (window's name). -U Tell screen to use UTF-8 encoding. -x Attach to a not detached screen. (Multi display mode). -X Execute cmd as a screen command in the specified session. Interactive commands (default key bindings): Control-a ? Display brief help Control-a " List all windows for selection Control-a ' Prompt for a window name or number to switch to. Control-a 0 Select window 0 Control-a 1 Select window 1 ... ... Control-a 9 Select window 9 Control-a A Accept a title name for the current window. Control-a b Send a break to window Control-a c Create new window running a shell Control-a C Clear the screen Control-a d Detach screen from this terminal. Control-a D D Detach and logout. Control-a f Toggle flow on, off or auto. Control-a F Resize the window to the current region size. Control-a h Write a hardcopy of the current window to file "hardcopy.n" Control-a H Begin/end logging of the current window to file "screenlog.n" Control-a i Show info about this window. Control-a k Kill (Destroy) the current window. Control-a l Fully refresh current window Control-a M Monitor the current window for activity {toggle on/off} Control-a n Switch to the Next window Control-a N Show the Number and Title of window Control-a p Switch to the Previous window Control-a q Send a control-q to the current window(xon) Control-a Q Delete all regions but the current one.(only) Control-a r Toggle the current window's line-wrap setting(wrap) Control-a s Send a control-s to the current window(xoff) Control-a w Show a list of windows (windows) Control-a x Lock this terminal (lockscreen) Control-a X Kill the current region(remove) Control-a Z Reset the virtual terminal to its "power-on" values Control-a Control-\ Kill all windows and terminate screen(quit) Control-a : Enter command line mode(colon) Control-a [ Enter copy/scrollback mode(copy) Control-a ] Write the contents of the paste buffer to stdin(paste) Control-a _ Monitor the current window for inactivity {toggle on/off} Control-a * Show a listing of all currently attached displays. When screen is called, it creates a single window with a shell in it (or the specified command) and then gets out of your way so that you can use the program as you normally would. Then, at any time, you can: Create new (full-screen) windows with other programs in them (including more shells) Kill existing windows View a list of windows Switch between windows - all windows run their programs completely independent of each other. Programs continue to run when their window is currently not visible and even when the whole screen session is detached from the user's terminal. The interactive commands above assume the default key bindings. You can modify screen’s settings by creating a ~/.screenrc file in your home directory. This can change the default keystrokes, bind function keys F11, F12 or even set a load of programs/windows to run as soon as you start screen. Attaching and Detaching Once you have screen running, switch to any of the running windows and type Control-a d. this will detach screen from this terminal. Now, go to a different machine, open a shell, ssh to the machine running screen (the one you just detached from), and type: % screen -r This will reattach to the session. Just like magic, your session is back up and running, just like you never left it. Exiting screen completely Screen will exit automatically when all of its windows have been killed. Close whatever program is running or type `Exit ' to exit the shell, and the window that contained it will be killed by screen. (If this window was in the foreground, the display will switch to the previous window) When none are left, screen exits. This page is just a summary of the options available, type man screen for more. "Growing old is mandatory, but growing up is optional" - Motto of the Silver Screen Saddle Pals ======================================== Using screen (virtual terminal multiplexer) What is screen? “Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells).” (from man page) In every-day use you just type $ screen and it seems that nothing happens. :) In fact a program is run that manages multiple bash processes and allows doing cool stuff in console(s) without having to run X. Basics Ctrl+a is a basic command that allows you to control screen. After you've pressed Ctrl+a your input is not being sent to current console, but to the screen itself. That's where you issue one-letter commands. (and more, but let's not get you confused) basic commands Ctrl+a c - create new console Ctrl+a n - switch to next console (it loops) Ctrl+a p - switch to previous console (it loops) Ctrl+a a - send Ctrl+a combination to the program, I didn't want to call screen Ctrl+a k - kill current console (asks to confirm)(ends screen when last console is killed) Ctrl+a d - detach - exits screen but leaves consoles and theri processes running For jornada it might be comfortable to bind winkey to do Ctrl+a. I'll expand the tutorial when I find the best way to do it. Copy and paste [[awesome]] You like using links browser in text mode, but you hate having to start X or use wget to copy some text from a page? Screen is the answer! Ctrl+a [[ - switch to copy mode - then use arrows to move cursor - press Enter to start selection - move cursor to the end - press Enter again Now switch to another console with your awesome script being developed in an editor or just jump to a textfield on a page… Ctrl+a ]] - pastes the copied text Useful for transporting data between two separate instances of screen or for using copied text as an input file for programs: Ctrl+a > - writes copied buffer to a file given in config (/tmp/screen-exchange by default, but don't go looking through options - it'll tell you where it writes) Ctrl+a < - loads the file to buffer Splitting screen You can split your screen and display two (or more, but…) consoles at the same time. Screen avaliable in jlime repos supports only horizontal splitting, so I won't mention the vertical splitting keys. Ctrl+a S - does the split (S is Shift+s and it has to be capital S) - new screen region is created - you probably want to press //Ctrl+a c// to start a new console in there Ctrl+a Tab - switches between visible splits Ctrl+a :resize (Enter) - prompts for number of lines and resizes current split Ctrl+a X - removes current split Monitoring activity If you work in one console and running something in another you might want to monitor it. Ctrl+a M - starts monitoring current console for changes (Will inform you when a program outputs something new. Good for IM clients) Ctrl+a _ - start monitoring current console for silence (Will inform you when a program stops outputting new stuff. Good for compiling or downloading with wget) Sessions and attaching Mostly useful when working on a remote machine with screen, but you might want to know this. When you loose a connection or leave screen with Ctrl+a d your processes stay there. You might want to get to them again I suppose :) $ screen -ls There is a screen on: 21209.pts-0.computername (Detached) 1 Socket in /var/run/screen/S-username. To get back to the running screen type $ screen -r 21209 21209 in both examples above is a PID of the screen process. ===================================== http://snipplr.wordpress.com/2012/04/07/my-screenrc-with-custom-hardstatus-and-easy-switching-between-screens/ screen setup with custom hard status and dialog menu Posted on April 7, 2012 The following set of scripts produce a nice screen setup along with a dialog menu for the most common tasks. This is how it looks like And this is how it’s done. Please see inline comments for details. 01 #!/bin/bash 02 ## use shift-left/right to switch between windows 03 ## use ctrl-n to add new shellwindow 04 ## use shift-PgUp/PgDown for scrolling history hit esc to stop 05 ## use ctrl-a-k for killing a window 06 ## mark area with space, end marking with space, paste with ctrl-a-] 07 setenv TERM xterm 08 09 #kill startup messes 10 startup_message off 11 12 # detach on hangup 13 autodetach on 14 15 # define a bigger scrollback, default is 100 lines 16 defscrollback 4096 17 18 # shell 19 shell -bash 20 21 #make scrollbar work 22 termcapinfo xterm ti@:te@ 23 24 defmonitor on # turn monitoring on 25 activity "%" # tell me when stuff happens! 26 27 # Make shift-PgUp and shift-PgDn work like they do in xterm. (Note that this 28 # requires xterm to be configured to pass those keys through, and not try to 29 # act on them itself.) 30 bindkey "^[O2A" eval "copy" "stuff ^b" 31 bindkey -m "^[O2A" stuff ^u 32 bindkey -m "^[O2B" stuff ^d 33 34 bindkey "^[O2D" prev 35 bindkey "^[O2C" next 36 37 # ctrl-N for new window 38 bindkey "^N" screen 39 40 # ctrl-a-b to copy selection to osx-clipboard 41 #bind b eval "writebuf" "exec sh -c 'pbcopy < /tmp/screen-exchange'" 42 43 # Window numbering starts at 1, not 0. 44 bind c screen 1 45 bind 0 select 10 46 47 # Run everything in UTF-8. 48 defutf8 on 49 # If a window goes unresponsive, don't block the whole session waiting for it. 50 nonblock on 51 52 # An alternative hardstatus to display a bar at the bottom listing the 53 # windownames and highlighting the current windowname in blue. (This is only 54 # enabled if there is no hardstatus setting for your terminal) 55 # see http://www.debian-administration.org/articles/560 56 hardstatus on 57 hardstatus alwayslastline 58 hardstatus string "%{.bW}%-w%{.rW}%n %t%{-}%+w %=%{..G} %H %{..Y} %m/%d %C%a " 59 60 screen -t selector sh screen-selector.sh I use this via screen -c selector-screenrc. The helper script for initializing a screen session looks like this and would either connect to an existing one or create a new one. 1 #!/bin/bash 2 3 screenpid=`ps x|grep -E '(.*)SCREEN(.*)selector-screenrc\$'|awk '{print \$1}'|head -1` 4 if [ $screenpid -gt 0 ]; then 5 screen -x $screenpid -c selector-screenrc 6 else 7 screen -c selector-screenrc 8 fi The screen-selector.sh file is a bonus and provides a dialog menu for frequently used commands. It looks like this 01 #!/bin/bash 02 03 while [ 1 ]; do 04 05 select=`/opt/local/bin/dialog --stdout --menu "select task" 20 60 13 \`cat tasks | tr '\040' '_' | tr '\012' '\040'\`` 06 07 echo "selected $select" 08 09 if [ ! -z $select ]; then 10 11 echo $select 12 13 command=`grep $select tasks|awk 'BEGIN{FS=OFS="\t"}{print \$2}'|tr -d "\""` 14 15 echo "executing command \"$command\"" 16 17 $command 18 # sleep 2 19 else 20 exit 0 21 fi 22 23 done The “tasks” file holds a simple list of tasks/commands. See the example below. 1 su "screen -t rootshell sudo su -" 2 newshell "screen -t shell"