In this chapter, you discover what Linux is and how it relates to its inspiration, UNIX. You take a guided tour of the facilities... more

In this chapter, you discover what Linux is and how it relates to its inspiration, UNIX. You take a guided tour of the facilities provided by a Linux development system, and write and run your first program. Along the way, you’ll be looking at

• UNIX, Linux, and GNU

• Programs and programming languages for Linux

• How to locate development resources

• Static and shared libraries

• The UNIX philosophy

... less

Having started this book on programming Linux using C, we now take a detour into writing shell programs. Why? Well, Linux... more

Having started this book on programming Linux using C, we now take a detour into writing shell programs. Why? Well, Linux isn’t like systems where the command-line interface is an afterthought to the graphical interface. UNIX, Linux’s inspiration, originally had no graphical interface at all; everything was done from the command line. Consequently, the command-line system of UNIX underwent a lot of development and became a very powerful feature. This has been carried into Linux, and some of the most powerful things that you can do are most easily done from the shell. Because the shell is so important to Linux, and is so useful for automating simple tasks, shell programming is covered early.

Throughout this chapter, we’ll be showing you the syntax, structures, and commands available to you when you’re programming the shell, usually making use of interactive (screen-based) examples. These should serve as a useful synopsis of most of the shell’s features and their effects. We will also sneak a look at a couple of particularly useful command-line utilities often called from the shell: grep and find. While looking at grep, we also cover the fundamentals of regular expressions, which crop up in Linux utilities and in programming languages such as Perl, Ruby, and PHP. At the end of the chapter, you’ll learn how to program a real-life script, which is reprogrammed and extended in C throughout the book. This chapter covers the following:

• What a shell is

• Basic considerations

• The subtleties of syntax: variables, conditions, and program control

• Lists

• Functions

• Commands and command execution

• Here documents

• Debugging

• grep and regular expressions

• find

Whether you’re faced with a complex shell script in your system administration, or you want to prototype your latest big (but beautifully simple) idea, or just want to speed up some repetitive task, this chapter is for you.

... less

In this chapter, you look at Linux files and directories and how to manipulate them. You learn how to create files, open... more

In this chapter, you look at Linux files and directories and how to manipulate them. You learn how to create files, open them, read, write, and close them. You also learn how programs can manipulate directories (to create, scan, and delete them, for example). After the preceding chapter’s diversion into shells, you now start programming in C.

Before proceeding to the way Linux handles file I/O, we review the concepts associated with files, directories, and devices. To manipulate files and directories, you need to make system calls (the UNIX and Linux parallel of the Windows API), but there also exists a whole range of library functions, the standard I/O library (stdio), to make file handling more efficient.

We spend the majority of the chapter detailing the various calls to handle files and directories. So this chapter covers various file-related topics:

• Files and devices

• System calls

• Library functions

• Low-level file access

• Managing files

• The standard I/O library

• Formatted input and output

• File and directory maintenance

• Scanning directories

• Errors

• The /proc file system

• Advanced topics: fcntl and mmap

... less

When you write a program for Linux (or UNIX and UNIX-like systems), you have to take into account that the program will run... more

When you write a program for Linux (or UNIX and UNIX-like systems), you have to take into account that the program will run in a multitasking environment. This means that there will be multiple programs running at the same time and sharing machine resources such as memory, disk space, and CPU cycles. There may even be several instances of the same program running at the same time. It’s important that these programs don’t interfere with one another, are aware of their surroundings, and can act appropriately to avoid conflicts such as trying to write the same file at the same time as another program.

This chapter considers the environment in which programs operate, how they can use that environment to gain information about operating conditions, and how users of the programs can alter their behavior. In particular, this chapter looks at

• Passing arguments to programs

• Environment variables

• Finding out what the time is

• Temporary files

• Getting information about the user and the host computer

• Causing and configuring log messages

• Discovering the limits imposed by the system

... less

In this chapter, you take a look at some improvements you might like to make to your basic application from Chapter 2. Perhaps... more

In this chapter, you take a look at some improvements you might like to make to your basic application from Chapter 2. Perhaps the most obvious failing is the user interface; it’s functional, but not very elegant. Here, you look at how to take more control of the user’s terminal; that is, both keyboard input and screen output. More than this though, you learn how to “guarantee” that the programs you write can get input from the user, even in the presence of input redirection, and ensure that the output goes to the right place on the screen.

Though the reimplemented CD database application won’t see the light of day until the end of Chapter 7, you’ll do much of the groundwork for that chapter here. Chapter 6 is on curses, which is not some ancient malediction, but rather a library of functions that provide a higher level of code to control the terminal screen display. Along the way, you’ll examine a little more of the thinking of the early UNIX meisters by introducing you to some philosophy of Linux and UNIX and the concept of terminal input and output. The low-level access presented here might be just what you’re looking for. Most of what we cover applies equally well to programs running in a console window, such as KDE’s Konsole, GNOME’s gnome-terminal, or the standard X11 xterm.

Specifically, in this chapter, you learn about

• Reading and writing to the terminal

• Terminal drivers and the General Terminal Interface

• termios

• Terminal output and terminfo

• Detecting keystrokes

... less

In Chapter 5, you learned how to obtain much finer control over the input of characters and how to provide character output... more

In Chapter 5, you learned how to obtain much finer control over the input of characters and how to provide character output in a terminal-independent way. The problem with using the general terminal interface (GTI, or termios) and manipulating escape sequences with tparm and its related functions is that it requires a lot of lower-level code. For many programs, a higher-level interface is more desirable. We would like to be able to simply draw on the screen and use a library of functions to take care of terminal dependencies automatically.

In this chapter, you’ll learn about just such a library, the curses library. The curses standard is important as a halfway house between simple “line-based” programs and the fully graphical (and generally harder to program) X Window System programs, such as GTK+/GNOME and Qt/KDE. Linux does have the svgalib (Super VGA Library, a low-level graphics library), but that is not a UNIX standard library, so is not generally available in other UNIX-like operating systems. The curses library is used in many full-screen applications as a reasonably easy and terminal-independent way to write full-screen, albeit character-based, programs. It’s almost always easier to write such programs with curses than to use escape sequences directly. curses can also manage the keyboard, providing an easy-to-use, nonblocking character input mode.

You may find that a few of the examples in this chapter don’t always display on the plain Linux console exactly as you expect. There are occasions when the combination of the curses library and the terminal definition of the console get slightly out of step and the effect is usually some slightly odd layouts when using curses. However, if you use the X Window System and use an xterm window to display the output, then things should display as you expect.

This chapter covers the following:

• Using the curses library

• The concepts of curses

• Basic input and output control

• Using multiple windows

• Using keypad mode

• Adding color

We finish the chapter by reimplementing the CD Collection program in C, summarizing what you’ve learned so far.

... less

In earlier chapters, we touched on the subject of resource limits. In this chapter, we’re going to look first at ways of... more

In earlier chapters, we touched on the subject of resource limits. In this chapter, we’re going to look first at ways of managing your resource allocation, then at ways of dealing with files that are accessed by many users more or less simultaneously, and lastly at one tool provided in Linux systems for overcoming the limitations of flat files as a data storage medium.

We can summarize these topics as three ways of managing data:

• Dynamic memory management: what to do and what Linux won’t let you do

• File locking: cooperative locking, locking regions of shared files, and avoiding deadlocks

• The dbm database: a basic, non-SQL-based database library featured in most Linux systems

... less

Now that you’ve explored some basic data management using flat files and then the simple but very quick dbm, you’re ready... more

Now that you’ve explored some basic data management using flat files and then the simple but very quick dbm, you’re ready to move on to a more full-featured data tool: the RDBMS, or Relational Database Management System.

The two best-known Open Source RDBMS applications are probably PostgreSQL and MySQL, although there are many others. There are also many commercial RDBMS products, such as Oracle, Sybase, and DB2, all of which are highly capable and run on multiple platforms. The Windows-only Microsoft SQL Server is another popular choice in the commercial marketplace. All these packages have their particular strengths; but for reasons of space, and a commitment to Open Source software, this book focuses exclusively on MySQL.

MySQL has origins going back to about 1984, but it has been commercially developed and managed under the auspices of MySQL AB for several years now. Because MySQL is Open Source, its terms of use are often confused with those of other Open Source projects. It’s worth pointing out that although MySQL can be used under the GNU General Public License (GPL) in many circumstances, there are circumstances where you must buy a commercial license to use the product. You should check the license requirements on the MySQL website (www.mysql.com) carefully, and determine which edition of MySQL is applicable to your requirements.

If you need an Open Source database and the terms for using MySQL under the GPL are not acceptable, and if you don’t want to purchase a commercial license, then the licensing terms for using PostgreSQL are, at the time of writing, much less restrictive, so you may want to consider the highly capable PostgreSQL database as an alternative. You can find details at www.postgresql.org.

Note

To learn more about PostgreSQL, check out our book, Beginning Databases with PostgreSQL: From Novice to Professional, Second Edition (Apress, 2005, ISBN 1590594789).

This chapter covers the following MySQL topics:

• Installing MySQL

• The administrative commands necessary to work with MySQL

• Basic MySQL features

• The API for interfacing your C programs with MySQL databases

• Creating a relational database that you can use for your CD database application using C

... less

This chapter looks at some of the tools available for developing programs on Linux systems, some of which are also available... more

This chapter looks at some of the tools available for developing programs on Linux systems, some of which are also available for UNIX. In addition to the obvious necessities of compilers and debuggers, Linux provides a set of tools, each of which does a single job, and allows the developer to combine these tools in new and innovative ways. This is part of the UNIX philosophy Linux has inherited. Here, you look at a few of the more important tools and see some examples of their being used to solve problems. These tools include:

• The make command and makefiles

• Source code control using RCS and CVS

• Writing a manual page

• Distributing software using patch and tar

• Development environments

... less

According to the Software Engineering Institute and the IEEE, every significant piece of software will initially contain... more

According to the Software Engineering Institute and the IEEE, every significant piece of software will initially contain defects, typically around two per 100 lines of code. These mistakes lead to programs and libraries that don’t perform as required, often causing a program to behave differently than it’s supposed to. Bug tracking, identification, and removal can consume a large amount of a programmer’s time during software development.

In this chapter, we look at software defects and consider some tools and techniques for tracking down specific instances of erroneous behavior. This isn’t the same as testing (the task of verifying the program’s operation in all possible conditions), although testing and debugging are, of course, related, and many bugs are discovered during the testing process.

Topics we cover include

• Types of errors

• General debugging techniques

• Debugging with GDB and other tools

• Assertions

• Memory use debugging

... less

Processes and signals form a fundamental part of the Linux operating environment. They control almost all activities performed... more

Processes and signals form a fundamental part of the Linux operating environment. They control almost all activities performed by Linux and all other UNIX-like computer systems. An understanding of how Linux and UNIX manage processes will hold any systems programmer, applications programmer, or system administrator in good stead.

In this chapter, you learn how processes are handled in the Linux environment and how to find out exactly what the computer is doing at any given time. You also see how to start and stop other processes from within your own programs, how to make processes send and receive messages, and how to avoid zombies. In particular, you learn about

• Process structure, type, and scheduling

• Starting new processes in different ways

• Parent, child, and zombie processes

• What signals are and how to use them

... less

In Chapter 11, you saw how processes are handled in Linux (and indeed in UNIX). These multiprocessing features have long... more

In Chapter 11, you saw how processes are handled in Linux (and indeed in UNIX). These multiprocessing features have long been a feature of UNIX-like operating systems. Sometimes it may be very useful to make a single program do two things at once, or at least to appear to do so, or you might want two or more things to happen at the same time in a closely coupled way but consider the overhead of creating a new process with fork too great. For these occasions you can use threads, which allow a single process to multitask.

In this chapter, you look at

• Creating new threads within a process

• Synchronizing data access between threads in a single process

• Modifying the attributes of a thread

• Controlling one thread from another in the same process

... less

In Chapter 11, you saw a very simple way of sending messages between two processes using signals. You created notification... more

In Chapter 11, you saw a very simple way of sending messages between two processes using signals. You created notification events that could be used to provoke a response, but the information transferred was limited to a signal number.

In this chapter, you take a look at pipes, which allow more useful data to be exchanged between processes. By the end of the chapter, you’ll be using your newfound knowledge to re-implement the CD database program as a very simple client/server application.

We cover the following topics in this chapter:

• The definition of a pipe

• Process pipes

• Pipe calls

• Parent and child processes

• Named pipes: FIFOs

• Client/server considerations

... less

In this chapter, we discuss a set of inter-process communication facilities that were originally introduced in the AT&T System... more

In this chapter, we discuss a set of inter-process communication facilities that were originally introduced in the AT&T System V.2 release of UNIX. Because all these facilities appeared in the same release and have a similar programmatic interface, they are often referred to as the IPC (Inter-Process Communication) facilities, or more commonly System V IPC. As you’ve already seen, they are by no means the only way of communicating between processes, but the expression System V IPC is usually used to refer to these specific facilities.

We cover the following topics in this chapter:

• Semaphores, for managing access to resources

• Shared memory, for highly efficient data sharing between programs

• Messaging, for an easy way of passing data between programs

... less

In this chapter, you look at yet another method of process communication, but one with a crucial difference from those we’ve... more

In this chapter, you look at yet another method of process communication, but one with a crucial difference from those we’ve discussed in Chapters 13 and 14. Until now, all the facilities we’ve discussed have relied on shared resources on a single computer system. The resource varies; it can be file system space, shared physical memory, or message queues, but only processes running on a single machine can use them.

The Berkeley versions of UNIX introduced a new communication tool, the socket interface, which is an extension of the concept of a pipe, covered in Chapter 13. Socket interfaces are available on Linux. You can use sockets in much the same way as pipes, but they include communication across a network of computers. A process on one machine can use sockets to communicate with a process on another, which allows for client/server systems that are distributed across a network. Sockets may also be used between processes on the same machine.

Also, the sockets interface has been made available for Windows via a publicly available specification called Windows Sockets, or WinSock. Windows socket services are provided by a Winsock.dll system file. So, Windows programs can communicate across a network to Linux and UNIX computers and vice versa, thus implementing client/server systems. Although the programming interface for WinSock isn’t quite the same as UNIX sockets, it still has sockets as its basis.

We can’t cover the extensive Linux networking capabilities in a single chapter, so you’ll find here a description of the principal programmatic networking interfaces. These should allow you to write your own network programs. Specifically, we look at the following:

• How a socket connection operates

• Socket attributes, addresses, and communications

• Network information and the Internet daemon (inetd/xinetd)

• Clients and servers

... less

So far in this book, we’ve covered the major topics in Linux programming that deal with complex, under-the-hood stuff. Now... more

So far in this book, we’ve covered the major topics in Linux programming that deal with complex, under-the-hood stuff. Now it’s time to breathe some life into your applications and look at how to add a Graphical User Interface (GUI) to them. In this chapter and Chapter 17, we’re going to look at the two most popular GUI libraries for Linux: GTK+ and KDE/Qt. These libraries correspond to the two most popular Linux desktop environments: GNOME (GTK+) and KDE.

All GUI libraries in Linux sit on top of the underlying windowing system called the X Window System (or more commonly X11 or just X), so before we delve into GNOME/GTK+ details we provide an overview of how X operates and help you understand how the various layers of the windowing system fit together to create what we call the desktop.

In this chapter, we cover

• The X Window System

• An introduction to GNOME/GTK+

• GTK+ widgets

• GNOME widgets and menus

• Dialogs

• CD Database GUI using GNOME/GTK+

... less

In Chapter 16, you looked at the GNOME/GTK+ GUI libraries for creating graphical user interfaces under X. These libraries... more

In Chapter 16, you looked at the GNOME/GTK+ GUI libraries for creating graphical user interfaces under X. These libraries are only half of the story; the other big player on the GUI scene in Linux is KDE/Qt, and in this chapter you look at these libraries and see how they shape up against the competition.

Qt is written in C++, the standard language in which to write Qt/KDE applications, so in this chapter you’ll be obliged to take a diversion from the usual C and get your hands dirty with C++. You might like to take this opportunity to refresh your memory on C++, especially reminding yourself of the principles of derivation, encapsulation, method overloading, and virtual functions.

In this chapter, we cover

• An introduction to Qt

• Installing Qt

• Getting started

• Signal/slot mechanism

• Qt widgets

• Dialogs

• Menus and toolbars with KDE

• Building your CD database application with KDE/Qt

... less

Linux started as just a kernel. Unfortunately, a kernel on its own is not very useful; programs are needed for logging in... more

Linux started as just a kernel. Unfortunately, a kernel on its own is not very useful; programs are needed for logging in, managing files, compiling new programs, and so forth. To make a useful system, tools were added from the GNU project. These were clones of familiar programs available on the UNIX and UNIX-like systems around at the time. Making Linux look and feel like UNIX set the first standards for Linux, providing a familiar environment for C programmers.

Different UNIX (and later Linux) vendors added proprietary extensions to the commands and utilities they made available, and the layout of the file systems they used varied slightly. It became difficult to create applications that would work on more than one system. Even worse, a programmer could not even rely on system facilities being provided in the same way or configuration files being maintained in the same place.

It was clear that some standardization was needed to prevent the UNIX systems from fragmenting, and some excellent UNIX standardization work is now in place.

Over time not only have these standards moved forward, but Linux itself has been enhanced at an impressive speed by the community, often supported by commercial organizations like Red Hat and Canonical, and even non-Linux vendors such as IBM. As Linux has progressed, it, along with the gcc compiler collection, has not only tracked the relevant standards rather well, but has also defined new standards as existing standards have been found to be insufficient. Indeed, as Linux and its associated tools and utilities have become ever more popular, the UNIX vendors have started making changes to their UNIX offerings to make them more compatible with Linux.

In this final chapter, we are going to look at these standards, pointing out areas that you should be aware of if you want not only to write applications that work on your Linux systems through upgrades, but also to create code that will be portable to other Linux distributions, and maybe even other UNIX-style systems, so that you can share your programs with others.

In particular, we look at

• The C programming language standard

• The UNIX standards, particularly the POSIX standard developed by the IEEE and The Single UNIX Specification developed by the Open Group

• Work by the Free Standards Group, particularly the Linux Standard Base, which defines a standard Linux file system layout

A good starting place for standards relating to Linux is the Linux Standard Base (LSB), which you can find from the Linux Foundation web site at http://www.linux-foundation.org/.

We are not going to look in detail at the contents of the standards; many of them are as long as this book. We are going to point out the key standards you should know about, give you a little historic background on how those standards arose, and help you decide which standards you might find helpful when writing your own programs.

... less