شباب فلسطين

زهراء المغرب · 11-15-2007, 07:59 PM

Unix (officially trademarked as UNIX®, sometimes also written as Unix or Unix® with small caps) is a computer operating system originally developed in 1969 by a group of AT&T employees at Bell Labs including Ken Thompson, Dennis Ritchie and Douglas McIlroy. Today's Unix systems are split into various branches, developed over time by AT&T as well as various commercial vendors and non-profit organizations.

As of 2007, the owner of the trademark UNIX® is The Open Group, an industry standards consortium. Only systems fully compliant with and certified to the Single UNIX Specification qualify as "UNIX®" (others are called "Unix system-like" or "Unix-like").

During the late 1970s and early 1980s, Unix's influence in academic circles led to large-scale adoption of Unix (particularly of the BSD variant, originating from the University of California, Berkeley) by commercial startups, the most notable of which is Sun Microsystems. Today, in addition to certified Unix systems, Unix-like operating systems such as Linux and BSD derivatives are commonly encountered.

Sometimes, "traditional Unix" may be used to describe a Unix or an operating system that has the characteristics of either Version 7 Unix or UNIX System V.

[edit] Overview
Unix operating systems are widely used in both servers and workstations. The Unix environment and the client-server program model were essential elements in the development of the Internet and the reshaping of computing as centered in networks rather than in individual computers.

Both Unix and the C programming language were developed by AT&T and distributed to government and academic institutions, causing both to be ported to a wider variety of machine families than any other operating system. As a result, Unix became synonymous with "open systems".

Unix was designed to be portable, multi-tasking and multi-user in a time-sharing configuration. Unix systems are characterized by various concepts: the use of plain text for storing data; a hierarchical file system; treating devices and certain types of inter-process communication (IPC) as files; and the use of a large number of small programs that can be strung together through a command line interpreter using pipes, as opposed to using a single monolithic program that includes all of the same functionality. These concepts are known as the Unix philosophy.

Under Unix, the "operating system" consists of many of these utilities along with the master control program, the kernel. The kernel provides services to start and stop programs, handle the file system and other common "low level" tasks that most programs share, and, perhaps most importantly, schedules access to hardware to avoid conflicts if two programs try to access the same resource or device simultaneously. To mediate such access, the kernel was given special rights on the system, leading to the division between user-space and kernel-space.

The microkernel tried to reverse the growing size of kernels and return to a system in which most tasks were completed by smaller utilities. In an era when a "normal" computer consisted of a hard disk for storage and a data terminal for input and output (I/O), the Unix file model worked quite well as most I/O was "linear". However, modern systems include networking and other new devices. Describing a graphical user interface driven by mouse control in an "event driven" fashion didn't work well under the old model. Work on systems supporting these new devices in the 1980s led to facilities for non-blocking I/O, forms of inter-process communications other than just pipes, as well as moving functionality such as network protocols out of the kernel.

[edit] History

A partial list of simultaneously running processes on a Unix system.In the 1960s, the Massachusetts Institute of Technology, AT&T Bell Labs, and General Electric worked on an experimental operating system called Multics (Multiplexed Information and Computing Service), which was designed to run on the GE-645 mainframe computer. The aim was the creation of a commercial product, although this was never a great success. Multics was an interactive operating system with many novel capabilities, including enhanced security. The project did develop production releases, but initially these releases performed poorly.

AT&T Bell Labs pulled out and deployed its resources elsewhere. One of the developers on the Bell Labs team, Ken Thompson, continued to develop for the GE-645 mainframe, and wrote a game for that computer called Space Travel.[1] However, he found that the game was too slow on the GE machine and was expensive, costing $75 per execution in scarce computing time.[2]

Thompson thus re-wrote the game in assembly language for Digital Equipment Corporation's PDP-7 with help from Dennis Ritchie. This experience, combined with his work on the Multics project, led Thompson to start a new operating system for the PDP-7. Thompson and Ritchie led a team of developers, including Rudd Canaday, at Bell Labs developing a file system as well as the new multi-tasking operating system itself. They included a command line interpreter and some small utility programs.[3]

Editing a shell script using the ed editor. The dollar-sign at the top of the screen is the prompt printed by the shell. 'ed' is typed to start the editor, which takes over from that point on the screen downwards.
[edit] 1970s
In the 1970s the project was named Unics, and eventually could support two simultaneous users. Brian Kernighan invented this name as a contrast to Multics; the spelling was later changed to Unix.

Up until this point there had been no financial support from Bell Labs. When the Computer Science Research Group wanted to use Unix on a much larger machine than the PDP-7, Thompson and Ritchie managed to trade the promise of adding text processing capabilities to Unix for a PDP-11/20 machine. This led to some financial support from Bell. For the first time in 1970, the Unix operating system was officially named and ran on the PDP-11/20. It added a text formatting program called roff and a text editor. All three were written in PDP-11/20 assembly language. Bell Labs used this initial "text processing system", made up of Unix, roff, and the editor, for text processing of patent applications. Roff soon evolved into troff, the first electronic publishing program with a full typesetting capability. The UNIX Programmer's Manual was published on November 3, 1971.

In 1973, Unix was rewritten in the C programming language, contrary to the general notion at the time "that something as complex as an operating system, which must deal with time-critical events, had to be written exclusively in assembly language".[4] The migration from assembly language to the higher-level language C resulted in much more portable software, requiring only a relatively small amount of machine-dependent code to be replaced when porting Unix to other computing platforms.

AT&T made Unix available to universities and commercial firms, as well as the United States government under licenses. The licenses included all source code including the machine-dependent parts of the kernel, which were written in PDP-11 assembly code. Copies of the annotated Unix kernel sources circulated widely in the late 1970s in the form of a much-copied book by John Lions of the University of New South Wales, the Lions' Commentary on UNIX 6th Edition, with Source Code, which led to considerable use of Unix as an educational example.

Versions of the Unix system were determined by editions of its user manuals, so that (for example) "Fifth Edition UNIX" and "UNIX Version 5" have both been used to designate the same thing. Development expanded, with Versions 4, 5, and 6 being released by 1975. These versions added the concept of pipes, leading to the development of a more modular code-base, increasing development speed still further. Version 5 and especially Version 6 led to a plethora of different Unix versions both inside and outside Bell Labs, including PWB/UNIX, IS/1 (the first commercial Unix), and the University of Wollongong's port to the Interdata 7/32 (the first non-PDP Unix).

In 1978, UNIX/32V, for the VAX system, was released. By this time, over 600 machines were running Unix in some form. Version 7 Unix, the last version of Research Unix to be released widely, was released in 1979. Versions 8, 9 and 10 were developed through the 1980s but were only released to a few universities, though they did generate papers describing the new work. This research led to the development of Plan 9 from Bell Labs, a new portable distributed system.

[edit] 1980s

A late-80s style Unix desktop running the X Window System graphical user interface. Shown are a number of client applications common to the MIT X Consortium's distribution, including Tom's Window Manager, an X Terminal, Xbiff, xload, and a graphical manual page browser.AT&T licensed UNIX System III, based largely on Version 7, for commercial use, the first version launching in 1982. This also included support for the VAX. AT&T continued to issue licenses for older Unix versions. To end the confusion between all its differing internal versions, AT&T combined them into UNIX System V Release 1. This introduced a few features such as the vi editor and curses from the Berkeley Software Distribution of Unix developed at the University of California, Berkeley. This also included support for the Western Electric 3B series of machines.

Since the newer commercial UNIX licensing terms were not as favorable for academic use as the older versions of Unix, the Berkeley researchers continued to develop BSD Unix as an alternative to UNIX System III and V, originally on the PDP-11 architecture (the 2.xBSD releases, ending with 2.11BSD) and later for the VAX-11 (the 4.x BSD releases). Many contributions to Unix first appeared on BSD systems, notably the C shell with job control (modelled on ITS). Perhaps the most important aspect of the BSD development effort was the addition of TCP/IP network code to the mainstream Unix kernel. The BSD effort produced several significant releases that contained network code: 4.1cBSD, 4.2BSD, 4.3BSD, 4.3BSD-Tahoe ("Tahoe" being the nickname of the Computer Consoles Inc. Power 6/32 architecture that was the first non-DEC release of the BSD kernel), Net/1, 4.3BSD-Reno (to match the "Tahoe" naming, and that the release was something of a gamble), Net/2, 4.4BSD, and 4.4BSD-lite. The network code found in these releases is the ancestor of much TCP/IP network code in use today, including code that was later released in AT&T System V UNIX and early versions of Microsoft Windows. The accompanying Berkeley Sockets API is a de facto standard for networking APIs and has been copied on many platforms.

Other companies began to offer commercial versions of the UNIX System for their own mini-computers and workstations. Most of these new Unix flavors were developed from the System V base under a license from AT&T; however, others were based on BSD instead. One of the leading developers of BSD, Bill Joy, went on to co-found Sun Microsystems in 1982 and created SunOS (now Solaris) for their workstation computers. In 1980, Microsoft announced its first Unix for 16-bit microcomputers called Xenix, which the Santa Cruz Operation (SCO) ported to the Intel 8086 processor in 1983, and eventually branched Xenix into SCO UNIX in 1989.

For a few years during this period (before PC compatible computers with MS-DOS became dominant), industry observers expected that UNIX, with its portability and rich capabilities, was likely to become the industry standard operating system for microcomputers.[5] In 1984 several companies established the X/Open consortium with the goal of creating an open system specification based on UNIX. Despite early progress, the standardization effort collapsed into the "Unix wars," with various companies forming rival standardization groups. The most successful Unix-related standard turned out to be the IEEE's POSIX specification, designed as a compromise API readily implemented on both BSD and System V platforms, published in 1988 and soon mandated by the United States government for many of its own systems.

AT&T added various features into UNIX System V, such as file locking, system administration, streams, new forms of IPC, the Remote File System and TLI. AT&T cooperated with Sun Microsystems and between 1987 and 1989 merged features from Xenix, BSD, SunOS, and System V into System V Release 4 (SVR4), independently of X/Open. This new release consolidated all the previous features into one package, and heralded the end of competing versions. It also increased licensing fees.

During this time a number of vendors including Digital Equipment, Sun, Addamax and others began building trusted versions of UNIX for high security applications, mostly designed for military and law enforcement applications.

The Common Desktop Environment or CDE, a graphical desktop for Unix co-developed in the 1990s by HP, IBM, and Sun as part of the COSE initiative.
[edit] 1990s
In 1990, the Open Software Foundation released OSF/1, their standard Unix implementation, based on Mach and BSD. The Foundation was started in 1988 and was funded by several Unix-related companies that wished to counteract the collaboration of AT&T and Sun on SVR4. Subsequently, AT&T and another group of licensees formed the group "UNIX International" in order to counteract OSF. This escalation of conflict between competing vendors gave rise again to the phrase "Unix wars".

In 1991, a group of BSD developers (Donn Seeley, Mike Karels, Bill Jolitz, and Trent Hein) left the University of California to found Berkeley Software Design, Inc (BSDI). BSDI produced a fully functional commercial version of BSD Unix for the inexpensive and ubiquitous Intel platform, which started a wave of interest in the use of inexpensive hardware for production computing. Shortly after it was founded, Bill Jolitz left BSDI to pursue distribution of 386BSD, the free software ancestor of FreeBSD, OpenBSD, and NetBSD.

By 1993 most commercial vendors had changed their variants of Unix to be based on System V with many BSD features added on top. The creation of the COSE initiative that year by the major players in Unix marked the end of the most notorious phase of the Unix wars, and was followed by the merger of UI and OSF in 1994. The new combined entity, which retained the OSF name, stopped work on OSF/1 that year. By that time the only vendor using it was Digital, which continued its own development, rebranding their product Digital UNIX in early 1995.

Shortly after UNIX System V Release 4 was produced, AT&T sold all its rights to UNIX® to Novell. (Dennis Ritchie likened this to the Biblical story of Esau selling his birthright for the proverbial "mess of pottage".[6]) Novell developed its own version, UnixWare, merging its NetWare with UNIX System V Release 4. Novell tried to use this to battle against Windows NT, but their core markets suffered considerably.

In 1993, Novell decided to transfer the UNIX® trademark and certification rights to the X/Open Consortium.[7] In 1996, X/Open merged with OSF, creating the Open Group. Various standards by the Open Group now define what is and what is not a "UNIX" operating system, notably the post-1998 Single UNIX Specification.

In 1995, the business of administering and supporting the existing UNIX licenses, plus rights to further develop the System V code base, were sold by Novell to the Santa Cruz Operation.[1] Whether Novell also sold the copyrights is currently the subject of litigation (see below).

In 1997, Apple Computer sought out a new foundation for its Macintosh operating system and chose NEXTSTEP, an operating system developed by NeXT. The core operating system was renamed Darwin after Apple acquired it. It was based on the BSD family and the Mach kernel. The deployment of Darwin BSD Unix in Mac OS X makes it, according to a statement made by an Apple employee at a USENIX conference, the most widely used Unix-based system in the desktop computer market.

[edit] 2000 to present
See also: SCO-Linux controversies

A modern Unix desktop environment (Solaris 10)In 2000, SCO sold its entire UNIX business and assets to Caldera Systems, which later on changed its name to The SCO Group. This new player then started legal action against various users and vendors of Linux. SCO have alleged that Linux contains copyrighted Unix code now owned by The SCO Group. Other allegations include trade-secret violations by IBM, or contract violations by former Santa Cruz customers who have since converted to Linux. However, Novell disputed the SCO group's claim to hold copyright on the UNIX source base. According to Novell, SCO (and hence the SCO Group) are effectively franchise operators for Novell, which also retained the core copyrights, veto rights over future licensing activities of SCO, and 95% of the licensing revenue. The SCO Group disagreed with this, and the dispute resulted in the SCO v. Novell lawsuit.

In 2005, Sun Microsystems released the bulk of its Solaris system code (based on UNIX System V Release 4) into an open source project called OpenSolaris. New Sun OS technologies such as the ZFS file system are now first released as open source code via the OpenSolaris project; as of 2006 it has spawned several non-Sun distributions such as SchilliX, Belenix, Nexenta and MarTux.

The Dot-com crash has led to significant consolidation of Unix projects. Of the many commercial flavors of Unix that were born in the 1980s, only Solaris, HP-UX, and AIX are still doing relatively well in the market, though SGI's IRIX persisted for quite some time. Of these, Solaris has the most market share, and may be gaining popularity due to its feature set and also since it now has an Open Source version.[8]

Standards
Beginning in the late 1980s, an open operating system standardization effort now known as POSIX provided a common baseline for all operating systems; IEEE based POSIX around the common structure of the major competing variants of the Unix system, publishing the first POSIX standard in 1988. In the early 1990s a separate but very similar effort was started by an industry consortium, the Common Open Software Environment (COSE) initiative, which eventually became the Single UNIX Specification administered by The Open Group). Starting in 1998 the Open Group and IEEE started the Austin Group, to provide a common definition of POSIX and the Single UNIX Specification.

In an effort towards compatibility, in 1999 several Unix system vendors agreed on SVR4's Executable and Linkable Format (ELF) as the standard for binary and object code files. The common format allows substantial binary compatibility among Unix systems operating on the same CPU architecture.

The Filesystem Hierarchy Standard was created to provide a reference directory layout for Unix-like operating systems, particularly Linux. This type of standard however is controversial, and even within the Linux community its adoption is far from universal.

[edit] Components
See also: list of Unix programs
The Unix system is composed of several components that are normally packaged together. By including — in addition to the kernel of an operating system — the development environment, libraries, documents, and the portable, modifiable source-code for all of these components, Unix was a self-contained software system. This was one of the key reasons it emerged as an important teaching and learning tool and has had such a broad influence.

The inclusion of these components did not make the system large — the original V7 UNIX distribution, consisting of copies of all of the compiled binaries plus all of the source code and documentation occupied less than 10Mb, and arrived on a single 9-track magtape. The printed documentation, typeset from the on-line sources, was contained in two volumes.

The names and filesystem locations of the Unix components has changed substantially across the history of the system. Nonetheless, the V7 implementation is considered by many to have the canonical early structure:

Kernel — source code in /usr/sys, composed of several sub-components:
conf — configuration and machine-dependent parts, including boot code
dev — device drivers for control of hardware (and some pseudo-hardware)
sys — operating system "kernel", handling memory management, process scheduling, system calls, etc.
h — header files, defining key structures within the system and important system-specific invariables
Development Environment — Early versions of Unix contained a development environment sufficient to recreate the entire system from source code:
cc — C language compiler (first appeared in V3 Unix)
as — machine-language assembler for the machine
ld — linker, for combining object files
lib — object-code libraries (installed in /lib or /usr/lib) libc, the system library with C run-time support, was the primary library, but there have always been additional libraries for such things as mathematical functions (libm) or database access. V7 Unix introduced the first version of the modern "Standard I/O" library stdio as part of the system library. Later implementations increased the number of libraries significantly.
make - build manager (introduced in PWB/UNIX), for effectively automating the build process
include — header files for software development, defining standard interfaces and system invariants
Other languages — V7 Unix contained a Fortran-77 compiler, a programmable arbitrary-precision calculator (bc, dc), and the awk "scripting" language, and later versions and implementations contain many other language compilers and toolsets. Early BSD releases included Pascal tools, and many modern Unix systems also include the GNU Compiler Collection as well as or instead of a proprietary compiler system.
Other tools — including an object-code archive manager (ar), symbol-table lister (nm), compiler-development tools (e.g. lex & yacc), and debugging tools.
Commands — Unix makes little distinction between commands (user-level programs) for system operation and maintenance (e.g. cron), commands of general utility (e.g. grep), and more general-purpose applications such as the text formatting and typesetting package. Nonetheless, some major categories are:
sh — The "shell" programmable command-line interpreter, the primary user interface on Unix before window systems appeared, and even afterward (within a "command window").
Utilities — the core tool kit of the Unix command set, including cp, ls, grep, find and many others. Subcategories include:
System utilities — administrative tools such as mkfs, fsck, and many others
User utilities — environment management tools such as passwd, kill, and others.
Document formatting — Unix systems were used from the outset for document preparation and typesetting systems, and included many related programs such as nroff, troff, tbl, eqn, refer, and pic. Some modern Unix systems also include packages such as TeX and Ghostscript.
Graphics — The plot subsystem provided facilities for producing simple vector plots in a device-independent format, with device-specific interpreters to display such files. Modern Unix systems also generally include X11 as a standard windowing system and GUI, and many support OpenGL.
Communications — Early Unix systems contained no inter-system communication, but did include the inter-user communication programs mail and write. V7 introduced the early inter-system communication system UUCP, and systems beginning with BSD release 4.1c included TCP/IP utilities.

The 'man' command can display a 'man page' for every command on the system, including itself.Documentation — Unix was the first operating system to include all of its documentation online in machine-readable form. The documentation included:
man — manual pages for each command, library component, system call, header file, etc.
doc — longer documents detailing major subsystems, such as the C language and troff

[edit] Impact
The Unix system had significant impact on other operating systems.

It was written in high level language as opposed to assembly language (which had been thought necessary for systems implementation on early computers). Although this followed the lead of Multics and Burroughs, it was Unix that popularized the idea.

Unix had a drastically simplified file model compared to many contemporary operating systems, treating all kinds of files as simple byte arrays. The file system hierarchy contained machine services and devices (such as printers, terminals, or disk drives), providing a uniform interface, but at the expense of occasionally requiring additional mechanisms such as ioctl and mode flags to access features of the hardware that did not fit the simple "stream of bytes" model. The Plan 9 operating system pushed this model even further and eliminated the need for additional mechanisms.

Unix also popularized the hierarchical file system with arbitrarily nested subdirectories, originally introduced by Multics. Other common operating systems of the era had ways to divide a storage device into multiple directories or sections, but they had a fixed number of levels, often only one level. Several major proprietary operating systems eventually added recursive subdirectory capabilities also patterned after Multics. DEC's RSX-11M's "group, user" hierarchy evolved into VMS directories, CP/M's volumes evolved into MS-DOS 2.0+ subdirectories, and HP's MPE group.account hierarchy and IBM's SSP and OS/400 library systems were folded into broader POSIX file systems.

Making the command interpreter an ordinary user-level program, with additional commands provided as separate programs, was another Multics innovation popularized by Unix. The Unix shell used the same language for interactive commands as for scripting (shell scripts — there was no separate job control language like IBM's JCL). Since the shell and OS commands were "just another program", the user could choose (or even write) his own shell. New commands could be added without changing the shell itself. Unix's innovative command-line syntax for creating chains of producer-consumer processes (pipelines) made a powerful programming paradigm (coroutines) widely available. Many later command-line interpreters have been inspired by the Unix shell.

A fundamental simplifying assumption of Unix was its focus on ASCII text for nearly all file formats. There were no "binary" editors in the original version of Unix — the entire system was configured using textual shell command scripts. The common denominator in the I/O system was the byte — unlike "record-based" file systems. The focus on text for representing nearly everything made Unix pipes especially useful, and encouraged the development of simple, general tools that could be easily combined to perform more complicated ad hoc tasks. The focus on text and bytes made the system far more scalable and portable than other systems. Over time, text-based applications have also proven popular in application areas, such as printing languages (PostScript), and at the application layer of the Internet Protocols, e.g. Telnet, FTP, SSH, SMTP, HTTP and SIP.

Unix popularized a syntax for regular expressions that found widespread use. The Unix programming interface became the basis for a widely implemented operating system interface standard (POSIX, see above).

The C programming language soon spread beyond Unix, and is now ubiquitous in systems and applications programming.

Early Unix developers were important in bringing the theory of modularity and reusability into software engineering practice, spawning a "Software Tools" movement.

Unix provided the TCP/IP networking protocol on relatively inexpensive computers, which contributed to the Internet explosion of world-wide real-time connectivity, and which formed the basis for implementations on many other platforms. (This also exposed numerous security holes in the networking implementations.)

The Unix policy of extensive on-line documentation and (for many years) ready access to all system source code raised programmer expectations, and contributed to the 1983 launch of the free software movement.

Over time, the leading developers of Unix (and programs that ran on it) evolved a set of cultural norms for developing software, norms which became as important and influential as the technology of Unix itself; this has been termed the Unix philosophy.

[edit] 2038
Main article: Year 2038 problem
Unix stores system time values as the number of seconds from midnight January 1, 1970 (the "Unix Epoch") in variables of type time_t, historically defined as "signed 32-bit integer". On January 19, 2038, the current time will roll over from a zero followed by 31 ones (01111111111111111111111111111111) to a one followed by 31 zeros (10000000000000000000000000000000), which will reset time to the year 1901 or 1970, depending on implementation, because that toggles the sign bit. As many applications use OS library routines for date calculations, the impact of this could be felt much earlier than 2038; for instance, 30-year mortgages may be calculated incorrectly beginning in the year 2008.

Since times before 1970 are rarely represented in Unix time, one possible solution that is compatible with existing binary formats would be to redefine time_t as "unsigned 32-bit integer". However, such a kludge merely postpones the problem to February 7, 2106, and could introduce bugs in software that compares differences between two sets of time.

Some Unix versions have already addressed this. For example, in Solaris on 64-bit systems, time_t is 64 bits long, meaning that the OS itself and 64-bit applications will correctly handle dates for some 292 billion years (several times greater than the age of the universe). Existing 32-bit applications using a 32-bit time_t continue to work on 64-bit Solaris systems but are still prone to the 2038 problem.

Free Unix-like operating systems

Linux is a modern Unix-like systemIn 1983, Richard Stallman announced the GNU project, an ambitious effort to create a free software Unix-like system; "free" in that everyone who received a copy would be free to use, study, modify, and redistribute it. GNU's goal was achieved in 1992. Its own kernel development project, GNU Hurd, had not produced a working kernel, but a compatible kernel called Linux was released as free software in 1992 under the GNU General Public License. The combination of the two is frequently referred to simply as "Linux", although the Free Software Foundation and some Linux distributions, such as Debian GNU/Linux, use the combined term GNU/Linux.

In addition to their use in the Linux operating system, many GNU packages — such as the GNU Compiler Collection (and the rest of the GNU toolchain), the GNU C library and the GNU core utilities — have gone on to play central roles in other free Unix systems as well.

Linux distributions, comprising Linux and large collections of compatible software have become popular both with hobbyists and in business. Popular distributions include Red Hat Enterprise Linux, Fedora, SUSE Linux Enterprise, openSUSE, Debian GNU/Linux, Ubuntu, Mandriva Linux, Slackware Linux and Gentoo.

A free derivative of BSD Unix, 386BSD, was also released in 1992 and led to the NetBSD and FreeBSD projects. With the 1994 settlement of a lawsuit that UNIX Systems Laboratories brought against the University of California and Berkeley Software Design Inc. (USL v. BSDi), it was clarified that Berkeley had the right to distribute BSD Unix — for free, if it so desired. Since then, BSD Unix has been developed in several different directions, including the OpenBSD and DragonFly BSD variants.

Linux and the BSD kin are now rapidly occupying the market traditionally occupied by proprietary Unix operating systems, as well as expanding into new markets such as the consumer desktop and mobile and embedded devices. A measure of this success may be seen when Apple Computer incorporated BSD into its Macintosh operating system by way of NEXTSTEP. Due to the modularity of the Unix design, sharing bits and pieces is relatively common; consequently, most or all Unix and Unix-like systems include at least some BSD code, and modern BSDs also typically include some GNU utilities in their distribution, so Apple's combination of parts from NeXT and FreeBSD with Mach and some GNU utilities has precedent.

In 2005, Sun Microsystems released the bulk of the source code to the Solaris operating system, a System V variant, under the name OpenSolaris, making it the first actively developed commercial Unix system to be open sourced (several years earlier, Caldera had released many of the older Unix systems under an educational and later BSD license). As a result, a great deal of formerly proprietary AT&T/USL code is now freely available.

-----------------------------------------------------------------------------------------------------------------------------------
The Open Group holds the definition of what a UNIX system is and its associated trademark in trust for the industry.

In 1994 Novell (who had acquired the UNIX systems business of AT&T/USL) decided to get out of that business. Rather than sell the business as a single entity, Novell transferred the rights to the UNIX trademark and the specification (that subsequently became the Single UNIX Specification) to The Open Group (at the time X/Open Company). Subsequently, it sold the source code and the product implementation (UNIXWARE) to SCO. The Open Group also owns the trademark UNIXWARE, transferred to them from SCO more recently.

Today, the definition of UNIX ® takes the form of the worldwide Single UNIX Specification integrating X/Open Company's XPG4, IEEE's POSIX Standards and ISO C. Through continual evolution, the Single UNIX Specification is the defacto and dejure standard definition for the UNIX system application programming interfaces. As the owner of the UNIX trademark, The Open Group has separated the UNIX trademark from any actual code stream itself, thus allowing multiple implementations. Since the introduction of the Single UNIX Specification, there has been a single, open, consensus specification that defines the requirements for a conformant UNIX system.

There is also a mark, or brand, that is used to identify those products that have been certified as conforming to the Single UNIX Specification, initially UNIX 93, followed subsequently by UNIX 95, UNIX 98 and now UNIX 03.

The Open Group is committed to working with the community to further the development of standards conformant systems by evolving and maintaining the Single UNIX Specification and participation in other related standards efforts. Recent examples of this are making the standard freely available on the web, permitting reuse of the standard in open source documentation projects , providing test tools ,developing the POSIX and LSB certification programs.

From this page you can read about the history of the UNIX system over the past 30 years or more. You can learn about the Single UNIX Specification, and read or download online versions of the specification. You can also get involved in the ongoing development and maintenance of the Single UNIX Specification, by joining the Austin Group whose approach to specification development is "write once, adopt everywhere", The Open Group's Base Working Group or get involved in the UNIX Certification program.

--------------------------------------------------------------------------------------------------------------------------------
In 1983 Digital Equipment Corporation (DEC) was ramping up their engineering group to create and ship their first UNIX system product.

One of the stalwarts of the group was Armando P. Stettner. Armando was a UNIX system devotee. He lived and he breathed the UNIX system. When he got his new car, it was natural that he got vanity license plates that said "UNIX" on them. And it only made it better that the state motto of New Hampshire was "Live Free or Die".

Armando often got requests from people along the lines of "When will we be able to get our UNIX system license directly from DEC?" And Armando kept saying "Real Soon Now" (RSN).

Armando was going to a conference and he was dreading having to say "RSN" many more times, so he had a bright idea. Amando went prepared to give out "UNIX licenses". On stage, when the question came up, "When will we be able to get our UNIX system license directly from DEC?", Armando yelled "Right Now!" and produced facsimilies of his license plate, holding it up for all to see. It was an almost perfect likeness of his license plate, with the trademark "UNIX" in the middle of it, but instead of having "Live Free or Die" across the bottom of the plate (as in the real case), it had it across the top. Across the bottom was the trademark acknowledgement.

DEC made UNIX license plates up in small numbers and handed them out at events. They usually ran out. The demand for the license plates never did abate. People saw them on an office wall, or heard about them somewhere, and wanted one of their own.

Armando left the state for the sunny climes of California, and had taken his car and license plate with him. Or so many people thought.

In 1989 Jon 'maddog' Hall was purchasing a new car, a Jeep Wrangler. And of course the license plate had to be relevant. So Jon, a long time DEC employee and UNIX system guru, submitted his application with many variations and the clerk said "I think we can give you your first choice...." and gave him the temporary paper plates (to be used on the car until the @_@@_@@_@@_@l plates were manufactured) with "UNIX" on them. And so it has been ever since. Jon's Jeep has been the holder of the UNIX license plate.

Of course there are other "UNIX" plates: from Massachusetts, New York, California, and we are sure others exist. If you know of or find another one, please let us know and send us a photo! (if there is enough interest we'll setup a gallery)

Links: How to obtain a License Plate

Download the Wall Poster

Acknowledgements
The Open Group thanks Jon "maddog" Hall for sharing the story of the UNIX license plate.

About The Open Group
The Open Group, a vendor-neutral and technology-neutral consortium, has a vision of Boundaryless Information Flow achieved through global interoperability in a secure, reliable and timely manner. The Open Group's mission is to drive the creation of Boundaryless Information Flow by:

Working with customers to capture, understand and address current and emerging requirements, establish policies, and share best practices;

Working with suppliers, consortia and standards bodies to develop consensus and facilitate interoperability, to evolve and integrate specifications and open source technologies;

Offering a comprehensive set of services to enhance the operational efficiency of consortia; and

Developing and operating the industry's premier certification service and encouraging procurement of certified products.

More information about The Open Group can be found at www.opengroup.org.

-----------------------------------------------------------------------------------------------------------
http://www.ee.surrey.ac.uk/Teaching/Unix/
------------------------------------------------------------------------------------------------------------
http://en.wikipedia.org/wiki/Unix
------------------------------------------------------------------------------------------------------------
http://www.unix.org/
-----------------------------------------------------------------------------------------------------------

القلب النابض · 11-15-2007, 10:17 PM

يا زهراء اسفة كتير كتير بس موقع الجامعة زبط وبكره ان شاء الله بدي سلم البحث صحيح انا غلبتك كتير والله خجلانه منك بس شو اعمل والله ما هي الشغلة بايدي بس اذا ممكن تفتحي الايميل بكره لتعطيني شو رايك بالبحث انا رح ضل طول نهار بكره ان شاء الله اسفة كتير على الازعاج

القلب النابض · 11-16-2007, 06:51 PM

شو اخذتيه ولا لا ردي علي اخذتيه ولا شو اعيده

زهراء المغرب · 11-16-2007, 07:02 PM

Le Système d'Exploitation

UNIX*

TABLE DES MATIERES

1. INTRODUCTION, ACCES AU SYSTEME 4
1.1. PRESENTATION GENERALE 4
1.1.1. LES GRANDES LIGNES 4
1.1.2. HISTORIQUE 4
1.1.3. LES VERSIONS D'UNIX 5
1.1.4. STRUCTURE GENERALE 6
1.1.5. L'AVENIR D'UNIX 7
1.2. ACCES AU SYSTEME 8
1.2.1. CONNEXION/DECONNEXION 8
1.2.2. CONVENTIONS DE FRAPPE 9
1.2.3. COMMANDES SIMPLES 9
2. ENVIRONNEMENT UTILISATEUR 9
2.1. SYSTEME DE FICHIERS 9
2.2. ACCES AUX FICHIERS ET AUX REPERTOIRES 11
2.3. PROTECTIONS 12
2.4. COMMANDES D'ETAT DU SYSTEME 15
2.4.1. LISTE DES UTILISATEURS CONNECTES : who 15
2.4.2. GESTION DES PROCESSUS : ps, kill 15
2.4.3. CONFIGURATION DU TERMINAL : stty 16
3. PRINCIPALES COMMANDES DE L'UTILISATEUR 16
3.1. LE GUIDE DE L'UTILISATEUR 16
3.2. MANIPULATIONS DU SYSTEME DE FICHIERS 16
3.3. MANIPULATIONS DE FICHIER 18
3.3.1. RECOPIE DE FICHIER : mv, cp 18
3.3.2. DESTRUCTION DE FICHIER : rm 18
3.3.3. VISUALISATION DE FICHIER : cat 18
3.3.4. IMPRESSION DE FICHIERS : pr, lpr 19
3.3.5. FILTRE ECRAN : more 19
3.3.6. COMPARAISON DE FICHIER : cmp, diff 19
3.3.7. DECOUPAGE DE FICHIER : tail, split, head 19
3.4. MANIPULATIONS DE TEXTES 20
3.4.1. COMPTAGE DE CARACTERES : wc 20
3.4.2. TRADUCTION DE CARACTERE : tr 20
3.4.3. TRI DE LIGNES DANS UN FICHIER : sort, uniq 20
3.4.4. RECHERCHE DE CHAINE DANS UN FICHIER : grep 21
3.4.5. LES EXPRESSIONS REGULIERES 21
3.4.6. REGLES D'ECRITURE DES EXPRESSIONS REGULIERES 22
4. LE LANGAGE DE COMMANDES SHELL 24
4.1. LE LANGAGE DE COMMANDE 24
4.2. SYNTAXE DES COMMANDES 24
4.3. PRINCIPE DE FONCTIONNEMENT DU SHELL 25
4.4. LES CARACTERES SPECIAUX 26
4.5. PROCEDURES DE COMMANDE 27
4.6. RE-DIRECTIONS 28
4.7. LE SHELL BOURNE 31
4.7.1. LES VARIABLES SHELL 31
4.7.2. VARIABLES PREDEFINIES 31
4.7.3. RECUPERATION DE RESULTATS DE COMMANDE 32
4.7.4. TRANSMISSION DE PARAMETRES 32
4.7.5. TRAITEMENT DES COMMANDES 33
4.7.6. LES COMMANDES INTERNES 34
4.7.7. LES STRUCTURES DE CONTROLE 35
4.7.7.1. LA STRUCTURE IF - THEN - ELSE : 35
4.7.7.2. LA BOUCLE FOR 36
4.7.7.3. LA BOUCLE WHILE 36
4.7.7.4. L'INSTRUCTION CASE 37
4.7.7.5. TRAITEMENT DES EVENEMENTS 38
4.8. LE "C-SHELL" 39
4.8.1. HISTORIQUE DES COMMANDES 39
4.8.2. SYNONYMES DE COMMANDES : alias, unalias 40
4.8.3. GESTION DES "JOBS" 41
4.8.4. CREATION DE SHELL SCRIPTS EN C-SHELL 42
4.8.5. COMMENTAIRES EN C-SHELL 42
4.8.6. VARIABLES C-SHELL 43
4.8.7. VARIABLES PREDEFINIES PROPRES A C-SHELL 44
4.8.8. TEST D'EXPRESSIONS 45
4.8.9. LES STRUCTURES DE CONTROLE 46
4.8.9.1. L'INSTRUCTION : if 46
4.8.9.2. L'INSTRUCTION : while 47
4.8.9.3. L'INSTRUCTION : foreach 47
4.8.9.4. L'INSTRUCTION : switch 47
4.8.9.5. GESTION DES ERREURS 48
4.9. FICHIERS D'INITIALISATION DU SHELL 48
5. GESTION DU SYSTEME 49
5.1. MISE EN PLACE DES PERIPHERIQUES 49
5.2. MISE EN PLACE DES SYSTEMES DE FICHIERS 50
5.3. LA HIERARCHIE STANDARD 51
5.4. MISE EN PLACE DU TEMPS PARTAGE 52
5.4.1. PRINCIPE DU LANCEMENT DU TEMPS PARTAGE 52
5.4.2. MISE EN PLACE DES TERMINAUX 53
5.4.3. MISE EN PLACE DES ACTIONS TEMPORELLES REPETITIVES 53
5.4.4. LA PROCEDURE DE "START-UP" /etc/rc 54
5.4.5. MISE EN PLACE DES UTILISATEURS 54
5.4.6. ARRET DU TEMPS PARTAGE 55
6. UNE APPROCHE SYSTEME 56
6.1. LES FONCTIONS SYSTEME SOUS UNIX 56
6.2. PROCESSUS : CREATION, GESTION ET PLANIFICATION 56
6.3. PARTAGE ET VERROUILLAGE DE FICHIER 57
6.4. GESTION DE LA MEMOIRE 58
6.5. COMMUNICATION INTER-PROCESSUS 60
6.6. DEVELOPPEMENT D'UNE APPLICATION 60
7. ANNEXE 63

1. INTRODUCTION, ACCES AU SYSTEME
1.1. PRESENTATION GENERALE
1.1.1. LES GRANDES LIGNES
D'après ses concepteurs, D.M. RITCHIE et K. THOMPSON :

UNIX* est un système d'exploitation en temps partagé d'usage général, multi-utilisateurs et interactif

dont les principales caractéristiques sont :

* Système de gestion de fichiers hiérarchisé incluant la possibilité de volumes amo¬vibles,
* Compatibilité totale des entrées-sorties qu'elles aient lieu sur fichier, sur périphérique ou entre processus,
* Possibilité d'exécution des processus de manière asynchrone,
* Langage de commandes puissant,
* Plusieurs sous-systèmes permettant le développement de logiciels dans la majorité des langages évolués,
* Haut degré de portabilité.

Par contre, UNIX n'est pas un système d'exploitation purement "TEMPS REEL" (bien qu'il existe dorénavant des versions adaptées au Temps Réel telles Lynx-OS).

ATTENTION : UNIX est une marque déposée des laboratoires BELL (U.S.A.).
1.1.2. HISTORIQUE
UNIX fut d'abord un système d'exploitation en Temps Partagé destiné à des applications de traitement de textes et de développement de logiciels. Ses origines remontent à 1969 aux labo¬ratoires BELL d'A.T.T. (USA) où Ken THOMPSON travaille alors sur un PDP-7 DIGITAL. Rapidement rejoint par Dennis RITCHIE, concepteur du Langage C, une version d'UNIX portable écrite principalement en C est mise au point. En 1971, UNIX fonc¬tionne sur PDP-11 et en 1978 plus de 600 sites travaillent "sous" UNIX. Ensuite, favorisé par l'énorme développement des ordinateurs et des microprocesseurs et grâce à des tra¬vaux d'universités telle l'Université de BERKELEY en Californie, UNIX est devenu dispo¬nible sur la quasi-totalité des ordinateurs du marché. La crois¬sance des développements de logiciels de ces dernières années n'a pû que favoriser l'implantation d'UNIX aussi bien dans les milieux universitaires que dans la recherche ou même dans les labora¬toires d'étude industriels.
1.1.3. LES VERSIONS D'UNIX
A l'image du développement fulgurant d'UNIX il faut associer une multitude de travaux menés de par le monde, travaux qui, hélas, ne se sont pas toujours accomplis très harmonieu¬sement : d'où une multitude de versions du système, versions pas toujours compatibles ! Sans compter toutes les versions "Unix-like" (ressemblant à UNIX mais pas dévelop¬pées à partir du système de base des "BELL Labs", d'ATT et ne donnant donc pas droit de licence à ces derniers) on peut distinguer trois versions majeures d'UNIX :

* les versions A.T.T., (lieu d'origine du développement d'Unix) avec une grande évolu¬tion dans le temps :

. UNIX version 7, mise au point sur PDP-11 DIGITAL par les BELL Labs et pre¬mière à avoir été distribuée commercialement.

. PWB/UNIX (Programmer's Workbench), 1973, spécialisée pour le développement de très grands projets logiciels.

. UNIX System III, (1981) mise à jour de la Version 7 incluant la plupart des fonc¬tionnalités de PWB/unix.

. UNIX System V, version majeure et officielle, annoncée en 83, offre de meilleures performances et une amélioration des communications interprocessus ainsi que des optimisations du noyau. En 1993, la version stabilisée de SYSTEM V est appelée SVR4 (System V Release 4).

* UNIX Berkeley : Une grande partie des développements UNIX s'est faite à l'extérieur des laboratoires BELL; l'université de BERKELEY à SAN DIEGO en Californie (USA) s'est spécialisée très tôt et a produit son propre ensemble d'utilitaires ainsi qu'une version d'Unix appelée UNIX Berkeley 4.1 BSD puis 4.2 BSD. Cette dernière supporte la ges¬tion de la mémoire virtuelle (utilisée à l'origine pour les machines VAX DIGITAL) et offre un Shell amélioré, le C-Shell. Unix 4.2 BSD et aujourd'hui 4.3 BSD ont connu un succès tel que plusieurs de ces améliorations ont été reprises par ATT dans System V.

* XENIX (Microsoft), UNIX SCO (Santa Cruz Operation), INTERACTIVE, COHERENT (Mark Williams Co)... : Ce sont des versions d'UNIX adaptées aux micro-ordi¬nateurs (PC et autres). Extension de la Version 7 et de System III à l'origine elles offrent aujourd'hui la plupart des fonctionnalités de System V. Leur prix modique (de 1 000 à 10 000 francs) et la multitude de micro-ordinateurs en font les versions d'UNIX les plus répan¬dues au monde.
Chez les constructeurs, UNIX se "décline" sous des noms à consonance "unixienne" (pour reprendre le terme consacré du jargon des utilisateurs UNIX) telles que : ULTRIX (DIGITAL), AIX (IBM), BOS (BULL), HP-UX (HP), SUN OS (SUN), MPIX (TELMAT), etc.
1.1.4. STRUCTURE GENERALE
Un système UNIX ou compatible comporte toujours quatre parties principales distinctes :

* le Noyau (kernel) : rési¬dent en mémoire centrale, assure la gestion de la mémoire, des en¬trées-sorties de bas niveau ainsi que l'ordonnancement des processus. Ce noyau, de petite taille (quelques centaines de ko), offre aux autres programmes une indépendance quasi-totale vis à vis du matériel puisque tout utilitaire ou programme utilisateur fait appel aux services du noyau, lesquels sont toujours présents sur toutes les implémentations.

* L'interpréteur du langage de commandes, appelé plus généralement le SHELL ; il en existe plusieurs versions mais les trois plus connues sont : la plus ancienne, mais aussi la plus simple, le "Bourne Shell" du nom de son auteur, le "C-Shell" apparu sur Unix 4.2 BSD et enfin le plus puissant mais le plus complexe : le "Korn-Shell". Le Shell ne fait pas partie du système d'exploitation mais c'est lui qui permet l'utilisation de toutes les fonctionnalités du système. Disposant d'instructions très puis¬santes il est presqu'aussi souple qu'un langage de programmation évolué !

* Les programmes utilitaires fournis avec UNIX, comportant d'office au moins un compilateur C et une multitude de commandes et d'outils (plusieurs centaines !) qui font la puissance et la réputa¬tion d'UNIX (éditeurs de texte, traitements de texte, génération de compilateur, langages de pro¬grammation, communications inter-utilisateurs ou inter-systèmes, gestion et manipulation de fi¬chiers, etc.).

* Les programmes utilisateurs développés avec les utilitaires, achetés chez des dévelop¬peurs ou développés directement par l'utilisateur. Une fois installés sur la machine, ils sont indis¬sociables des utilitaires.

En ce qui concerne la documentation, le système UNIX est toujours fourni avec au moins deux jeux de documents (parfois succincts hélas !), les volumes 1 et 2 avec respectivement, pour :

le Volume 1 : 8 sections repérées par un numéro (de 1 à 8) décrivant les ressources du système (les 3 premières sections constituent les ouvrages de base de l'informaticien travaillant sous UNIX !) :

section 1 : les commandes utilisateurs (elles sont nombreuses !),
section 2 : les appels système,
section 3 : sous-programmes des bibliothèques (C, curses, Xwindow,...),
section 4 : description des fichiers spéciaux et des pilotes de périphériques,
section 5 : format des fichiers utilisés par UNIX,
section 6 : jeux (!),
section 7 : divers,
section 8 : gestion et administration du système.

le volume 2 : c'est, en fait, une collection d'articles décrivant plus en détail certains utili¬taires.

D'autre part, chaque fournisseur apporte des compléments spécifiques à son implémen¬tation de façon à rendre la documentation de base (relativement succincte et peu adaptée à un utilisateur novice) utilisable plus facilement et mieux architecturée.
1.1.5. L'AVENIR D'UNIX
Très tôt, dès la multiplication des versions d'Unix le reproche est apparu d'une absence totale de standard unique. A l'instar d'une association d'utilisateurs (dénommée "/usr/group"), un comité a mis en chantier l'élaboration d'un standard. A l'arrivée de System V, ATT annonça sa décision de le considérer comme la version de référence; toute version ultérieure serait compa¬tible de manière ascendante et respecterait le S.V.I.D. (System V Interface Definition). En paral¬lèle, dès 1985 le comité de normalisation 1003 de l'I.E.E.E. travaille à la mise au point du standard POSIX (Portable Operating System Standard for Computer Environments) qui, globalement, combine les fonctionnalités des souches UNIX ATT et BSD. En 1990, l'IEEE (Institute of Electrical and Electronics Engineers) et l'ISO (International Standard Organization) publient la norme POSIX/ISO/IEC 9945-1 plus connue sous le sigle POSIX IEEE 1003.1 dont les grandes lignes concernent l'interface avec le système de base (liée au langage C) : appels système, gestion des processus, des fichiers, des utilisateurs, des primitives d'E/S.
Initialement prévu pour fédérer les différentes versions d'UNIX, POSIX, norme internationale, concerne aujourd'hui tous les systèmes informatiques : chaque constructeur s'efforce de rendre son système d'exploitation "conforme à POSIX" tels VMS/POSIX de DIGITAL ou MPE/IX de Hewlett Packard par exemple. POSIX devient donc un dénominateur commun minimal entre systèmes ce qui permet de garantir un degré de portabilité maximal des applications.
En ce qui concerne le développement des normes et la promotion des systèmes informatiques tels que POSIX il existe, outre les organismes normalisateurs tels que l'IEEE, l'ISO ou l'ANSI, différentes associations ou consortiums internationaux aux buts encore plus larges et dont l'impact est non négligeable dans la communauté informatique actuelle :
• O.S.F. (Open Software Foundation) regroupant des grands constructeurs et des fournisseurs d'informatique avec pour but de promouvoir les "systèmes ouverts". Ses plus intéressantes réalisations sont les suivantes :
* MOTIF : Interface graphique pour applications UNIX,
* OSF/1 : Système d'exploitation conforme UNIX à base de noyau MACH (Université CARNEGIE MELLON, USA),
* D.C.E. : (Distributed Computing Environment) mécanisme de base pour le développement d'applications distribuées.
• U.S.L. (Unix System Laboratories) émanation industrielle et surtout commerciale d'A.T.T. chargée d'assurer le suivi et le développement des versions d'UNIX System V.
• X/Open : Organisme international composé de constructeurs et de fournisseurs informatiques avec pour but la promotion d'UNIX, des systèmes ouverts (et non plus "propriétaires") ainsi que de la portabilité des applications au moyen de C.A.E. (Common Application Environment). Ses travaux s'articulent autour de trois axes principaux : guides de référence, étude des besoins des utilisateurs et attribution de labels de conformité. Son fameux guide XPG3 (X Portability Guide version 3) concerne la portabilité des applications en environnement X-Window.
• X-Consortium : consortium promouvant les travaux du M.I.T. (Massachusett's Institute of Technology) autour de X-Window, le moteur de multi-fenêtrage et le support de souris pour systèmes UNIX. Il suit l'évolution du standard X11, qui est le coeur de X-Window (sur lequel peut être implantée, par exemple, l'interface graphique MOTIF).
• 88/Open : Consortium international ayant pour but la promotion des systèmes UNIX conçus sur une architecture matérielle basée sur les processeurs de la famille RISC 88000 de MOTOROLA et la conformité au standard BCS (Binary Compatible Systems) qui offre une compatibilité binaire stricte des applications.
1.2. ACCES AU SYSTEME
1.2.1. CONNEXION/DECONNEXION
Comme dans tout système d'exploitation multi-utilisateurs digne de ce nom, un utilisateur ne pourra SE CONNECTER sur la machine que si le responsable du système lui a, au préalable, ouvert un "compte" caractérisé par un nom. C'est ce nom d'utilisateur qui sera demandé au termi¬nal suite à la question :
"login :"
Une fois entré le nom validé par RETOUR-CHARIOT et saisie le mot de passe associé (qui ne s'affiche pas à l'écran), un message d'entrée défini par le responsable système s'affiche, puis vient le message d'invite (prompt) qui est en géné¬ral le caractère dollar ("$").

ATTENTION : il est nécessaire d'entrer son nom d'utilisateur en minuscules !

Pour SE DECONNECTER du système, en fin de session, il faut effectuer un "logout" (par opposition au "login" du début de session) soit en utilisant tout simplement le caractère de fin de fichier qui est "Control-D" soit en tapant la commande "login".
1.2.2. CONVENTIONS DE FRAPPE
Traditionnellement, le dialogue avec un système UNIX se déroule toujours en MINUSCULES même si l'entrée des majuscules est possible MAIS les minuscules sont interprétées différemment des majuscules sauf spécification contraire (Unix est dit "case sensitive"). On notera qu'UNIX permet la frappe anticipée de commandes ("type ahead"), toutefois les résultats à l'affichage peuvent être très curieux.

Les commandes UNIX sont (en général) des contractions de termes américains et consti¬tuées de très peu de lettres pour en faciliter la mémorisation (mais pas la lisibilité). Les abrévia¬tions de commandes ne sont pas permises. Une commande peut être accompagnée d'options et de paramètres, ces paramètres étant séparés les uns des autres par des espaces. La saisie d'une com¬mande est terminée sur détection du RETOUR-CHARIOT et l'utilisateur ne récupère le prompt qu'après exécution de ladite commande.

En cas d'erreur de frappe avant la fin de commande il est possible d'annuler le dernier carac¬tère frappé au moyen de BACKSPACE (parfois "#") ou d'annuler toute la ligne avec "@".

Il existe un grand nombre de caractères qui ont une signification spéciale pour SHELL : "DELETE" permet l'arrêt de l'exécution d'une commande, "Control-S" pour stopper l'affichage sur l'écran et "Control-Q" pour le reprendre.
1.2.3. COMMANDES SIMPLES
Pour se familiariser avec UNIX voici quelques exemples de commandes très simples :

* "date" : permet l'affichage de la date et de l'heure,

* "who" : donne la liste des utilisateurs actuellement connectés sur le système,

* "tty" : donne le nom du terminal à partir duquel est lancée la commande,

* "passwd" : permet de mettre en place (ou modifier) sont mot de passe (toute saisie de mot de passe se faisant sans écho des carac¬tères à l'écran pour des raisons de sécurité !).
2. ENVIRONNEMENT UTILISATEUR
2.1. SYSTEME DE FICHIERS
Le système hiérarchisé de fichiers UNIX se compose de fichiers et de répertoires, eux-mêmes assimilables à des fichiers (particuliers). Les fichiers sont des suites de "caractères" (ou octets) adressables au niveau caractère. L'ensemble des fichiers "est structuré sous forme arbores¬cente, la racine se nommant par convention "/" (ou "root"), les noeuds étant les répertoires et les feuilles des fichiers (au sens strict). La majorité des systèmes UNIX respecte une hiérarchie stan¬dard qui est de la forme générale suivante :

Nota : les rectangles en trait plein symbolisent des répertoires normalisés sous UNIX alors que les rectangles en pointillés indiquent des répertoires utilisateurs. Les autres éléments désignent des fichiers.

Toute arborescence "UNIX" contient les répertoires particuliers suivants :

* bin : les commandes les plus importantes, pas de sous-répertoire

* dev : fichiers spéciaux ou "devices" assurant l'interface avec l'extérieur; ils sont traités comme des fichiers mais au moyen de commandes spéciales,

* etc : informations pour l'administration du système,

* lib : bibliothèques système (très utiles en programmation),

* usr : répertoire des utilisateurs, avec un répertoire par utilisateur et un répertoire "tmp" ré¬servé aux fichiers temporaires créés par le système.

Un utilisateur possède donc un répertoire de nom en général identique à son nom d'utilisateur dans lequel il peut à nouveau créer des répertoires à sa guise pour classer ses fichiers par projet, par thème,...
Tout fichier UNIX est repéré par son nom, qui est composé de caractères alphanumériques (lettres, chiffres et symboles). Sur les anciennes versions d'UNIX la taille du nom était limité à 14 caractères mais avec les dernières versions le nombre de caractères n'est plus limité. Dans la mesure où l'interpréteur de commandes shell utilise des caractères avec une signification particulière on se restreindra, de préférence, aux lettres, aux chiffres et au trait souligné "_".

ATTENTION : tout fichier dont le nom débute par un point est un "fichier caché" (hidden file) dans la mesure où il n'est pas visualisé par une commande "ls" classique.
Il est à noter que le système UNIX autorise les "liens" entre fichiers. Cette notion de lien ("link") s'appuie sur le fait que les feuilles de l'arborescence de fichiers correspondent à des noms de fichiers (et NON au fichier lui-même) : un même fichier peut être adressé par plusieurs noms ! En fait un fichier se voit associé un compte de liens ("link count") permettant la connaissance du contenu d'un fichier lors des accès par les autres noms. Un nom de fichier est créé lors de la créa¬tion d'un fichier avec ce nom ou par création d'un lien sur un fichier déjà existant. Un fichier n'est accédé que par un nom et il ne peut être détruit que s'il n'existe plus d'autre lien.
2.2. ACCES AUX FICHIERS ET AUX REPERTOIRES
Pour accéder aux différents éléments de cette arborescence il existe des règles simples permettant de désigner rigoureusement et sans ambiguïté un fichier ou un répertoire donné :

* un NOM ABSOLU donne le chemin à parcourir au sein de l'arborescence des fichiers pour aboutir au point désiré depuis la racine (on utilise le "/" en tête) et en séparant les diffé¬rents noms de réper¬toires par le caractère "/".
Exemples :
"/" Répertoire racine
"/bin/cat" programme de concaténation
"/usr/jean" répertoire de Jean
"/usr/jean/fortran/filtre" un fichier de Jean
"/dev/tty" terminal en cours d'utilisation

à tout instant on se trouve dans un répertoire appelé le répertoire courant ("working directory"), répertoire qui est déterminé au début de session, mais qui peut être modifié en cours de travail au moyen de la commande "cd nom_de_répertoire".

* un NOM RELATIF permet de désigner un fichier relativement au répertoire courant. Ce type de désignation se distingue très facilement de la précédente dans la mesure où elle n'utilise pas le "/" en tête.
Exemple :
$ pwd
/usr/jean
$ cd fortran
$ pwd
/usr/jean/fortran

Pour "remonter" dans l'arborescence on pourra utiliser un nom absolu ou, mieux, la nota¬tion ".." qui désigne le répertoire de niveau immédiatement supérieur. De même la notation "." désigne le répertoire courant.
Exemples :
$ pwd
/usr/jean/fortran
$ cd ..
$ pwd
/usr/jean
$ cd ../..
$ pwd
/
Pour connaître le contenu d'un répertoire il suffit d'utiliser la commande "ls" avec ou sans paramètre :
Exemples :
$ cd /usr
$ ls
jean marc oscar
$ ls ..
bin dev etc lib swp tmp unix usr

La commande "ls" dispose d'une option "-l" permettant d'obtenir de plus amples rensei¬gnements sur les fichiers (protections, nombre de liens, nom du propriétaire, taille du fichier en octets, date et heure de création et nom).
De même, il est possible de visualiser la liste complète des fichiers, y compris les fichiers "cachés" au moyen de l'option "-a" qui donnera également les fichiers dont le nom débute par un point.
2.3. PROTECTIONS
Sous UNIX tout fichier se voit affecté de droits d'accès permettant d'en autoriser ou d'en protéger l'accès. Pour ce faire, trois classes d'utilisateurs existent :
* le propriétaire (owner) ou créateur du fichier,
* les membres du même groupe (ou projet), non compris le propriétaire,
* les autres utilisateurs (world) du système n'appartenant pas au groupe,
classes auxquelles vient s'ajouter l'utilisateur privilégié qu'est le responsable système ("superuser" de nom "root") et qui a toute latitude quant aux accès fichiers. Pour chaque classe d'utilisateur il existe trois types d'accès : l'accès en lecture "r", l'accès en écriture "w" et l'accès en exécution "x".

Pour un fichier ordinaire les droits d'accès sont :
* "r" pour la lecture du contenu du fichier,
* "w" pour l'écriture, la modification ou la destruction du fichier,
* "x" pour l'exécution du fichier.

Par contre, pour un répertoire, les droits d'accès ont une signification légèrement diffé¬rente :
* "r" pour lire et donc lister le contenu du répertoire,
* "w" pour écrire ou modifier le contenu du répertoire (c'est à dire manipuler des fichiers),
* "x" pour accéder aux fichiers de ce répertoire.
La commande "ls -l" permet de lister toutes ces caractéristiques :

$ ls -l
total 62
-rwxr-xr-x 2 marc 2356 Mar 13 10:23 calcul.c
-rw-r--r-- 1 marc 451 Jan 5 16:54 a.out
drwx--x--x 2 marc 32 Mar 10 10:01 fortran
...
Les informations affichées sont dans l'ordre et de la gauche vers la droite :
* type du fichier : "d" pour répertoire, "-" pour fichier ordinaire, "c" pour un périphérique géré en mode caractère,...
* accès autorisé "r", "w", "x" pour dans l'ordre : propriétaire, groupe et autres,
* nombre de liens sur ce fichier,
* nom du propriétaire,
* taille en octets,
* date et heure de dernière modification,
* nom du fichier ou répertoire.

La commande chmod permet de modifier les protections d'un fichier ou d'un répertoire suivant la syntaxe suivante :

$ chmod permissions liste_de_fichiers
permissions indique soit sous forme numérique octale (!), soit sous forme symbolique le type de permission à appliquer à liste_de_fichiers. La forme numérique doit fournir l'image en octal des 9 bits représentatifs des 3 autorisations pour les 3 types d'utilisateurs, dans l'ordre : owner, group, world.

ce qui donne, par exemple :

0744 pour rwxr--r--
0500 pour r-x------
La forme symbolique associe les lettres u à owner, g à group, o à world et a pour les trois confondus ainsi que les droits r, w et x, droits que l'on peut ajouter ou retrancher par + ou -.
Exemple :
$chmod
$ ls -l ff
-rw-r--r-- 1 gm 5477 Mar 4 15:39 ff
$ chmod 755 ff
$ ls -l ff
-rwxr-xr-x 1 gm 5477 Mar 4 15:39 ff
$
$ chmod a-rwx ff
$ ls -l ff
---------- 1 gm 5477 Mar 4 15:39 ff
$ chmod u+rxw ff
$ ls -l ff
-rwx------ 1 gm 5477 Mar 4 15:39 ff
$

Un autre aspect de la protection sous UNIX est celui de l'accès réservé à certaines com¬mandes ou primitives système auxquelles seul l'utilisateur privilégié a droit. Les autres utilisateurs peuvent toutefois accéder à l'exécution d'une telle commande au moyen de la modification d'identité de l'utilisateur ("set user-id"). C'est un droit d'accès en exécution particulier tel que pendant l'exécution de la commande le programme associé sera exécuté sous le nom du proprié¬taire du fichier et non sous le nom de l'utilisateur : c'est le droit d'accès "s" au lieu de "x" pour le propriétaire du fichier. Cette caractéristique est très utilisée pour les commandes sensibles (de manipulations de répertoires par exemple) et on aura ainsi :

$ ls -l /bin/*dir
-rwsr-xr-x 1 root 17408 Apr 23 1987 /bin/mkdir
-rwsr-xr-x 1 root 7629 Apr 23 1987 /bin/rmdir

En ce qui concerne les protections (ou permissions) attribuées d'office à un fichier nouvellement créé elles sont déduites à partir d'un masque de bits modifiable par la commande shell umask. Ce masque de bits, codé en octal, représente les permissions à supprimer par rapport aux permissions par défaut des fichiers nouvellement créés qui sont :
666 (rw-rw-rw-) pour un fichier texte ordinaire,
777 (rwxrwxrwx) pour un répertoire ou un exécutable.
Ainsi, une valeur de umask égale à 027 interdit l'accès en écriture pour les membres du groupe et tout accès pour les autres utilisateurs que le propriétaire du fichier ce qui donnera les permissions effectives suivantes :
640 (rw-r-----) pour un fichier texte,
750 (rwxr-x---) pour un répertoire ou un exécutable.
La commande umask entrée sans paramètre fournit la valeur courante du masque des permissions à supprimer ; par contre, la modification du masque est réalisée en fournissant la valeur octale.
Exemple :
csh> umask
22
csh> cat .profile >f1
csh> ls -l f1
-rw-r--r-- 1 gm 182 Mar 9 17:55 f1
csh> umask 077
csh> cat .profile >f2
csh> ls -l f2
-rw------- 1 gm 182 Mar 9 17:55 f2
csh>
REMARQUE : on aura intérêt à introduire une commande umask adéquate dans le fichier d'initialisation .profile (en Shell Bourne) ou .login en C Shell.
2.4. COMMANDES D'ETAT DU SYSTEME
2.4.1. LISTE DES UTILISATEURS CONNECTES : who
La commande who permet de connaître la liste des utilisateurs actuellement en cours de session sur la machine, avec affichage de : nom d'utilisateur, nom du terminal, date et heure du "login".
Exemple :
$ who
gm tty01 Mar 14:01
pl tty02 Mar 14:23
$
La même commande suivie de "am i", who am i, permet d'obtenir les mêmes renseignements pour le seul utilisateur exécutant cette commande.
2.4.2. GESTION DES PROCESSUS : ps, kill
Pour connaître la liste des processus en cours de traitement par UNIX on utilisera la commande ps laquelle fournit, par processus : numéro du processus (PID, Process Identifier), nom du terminal associé, Etat du processus
I : Idle
S : Sleeping
R : Running
T : Stopped
W : Outswapped
P : Paging wait
Z : Zombie
temps machine cumulé et nom de la commande exécutée. En fonction d'options complémentaires ps permet l'affichage de différentes informations, y compris pour les processus "système".
Exemple :
$ ps -x
PID TT STAT TIME COMMAND
1403 01 I 0:09 -csh (csh)
1444 01 S 0:00 sh
1457 01 R 0:00 ps -x
$
Pour interrompre l'exécution d'un processus il suffit d'exécuter kill en indiquant le PID du processus concerné. Un utilisateur peut même détruire tous les processus qu'il a lancés au moyen de "kill 0".
2.4.3. CONFIGURATION DU TERMINAL : stty
stty permet, soit de visualiser l'état de configuration du terminal, soit de modifier cette configuration (ceci peut hélas varier d'un système à l'autre !), avec la possibilité de spécifier les caractères d'effacement de caractère (erase), de destruction de ligne (kill), de fin de fichier (eof),...
Exemple :
$ stty all
speed 9600 baud; tabs
crt
erase kill werase flush susp intr quit stop eof
^? ^U ^W ^O ^Z/^Y ^C ^\ ^S/^Q ^D
$
$ stty erase '^H'
$ stty all
speed 9600 baud; tabs
crt
erase kill werase flush susp intr quit stop eof
^H ^U ^W ^O ^Z/^Y ^C ^\ ^S/^Q ^D
$
3. PRINCIPALES COMMANDES DE L'UTILISATEUR
3.1. LE GUIDE DE L'UTILISATEUR
La plupart des systèmes UNIX proposent, dans la mesure où il reste de l'espace disque disponible, une documentation "en ligne" accessible au terminal par la commande "man". cette commande affiche à l'écran le contenu de la documentation écrite "Unix Programmer's Manual", laquelle est généralement stockée sous le répertoire "usr/man". Il suffit d'indiquer en paramètre le nom de la commande pour laquelle on désire de l'aide.
Exemple :
"man cd"
3.2. MANIPULATIONS DU SYSTEME DE FICHIERS
On ne citera ici que les principales commandes usuelles permettant de gérer le système de fichiers :
* Changement et visualisation de répertoire : "cd", "pwd"
La commande "cd" permet de se positionner sur un répertoire spécifié de façon absolue ou relative alors que "pwd" (print working directory) donne le nom du répertoire courant.
Exemple :
$ cd /usr/man/man1
$ pwd
/usr/man/man1
$
* Création, destruction de répertoires : "mkdir", "rmdir"
La commande mkdir crée un répertoire de nom passé en paramètre avec des modes de protection déterminés pour utilisateur, groupe et autres. Il est nécessaire d'avoir les auto¬risations d'accès au répertoire "père". Il est possible de détruire un répertoire par rmdir dans la mesure où il est vide.

* Visualisation du contenu d'un répertoire : "ls"
Cette commande, comme déjà vu plus haut, donne la liste des fichiers d'un répertoire avec, sur demande (option -l) des informations très complètes sur chaque fichier; d'autres options permettent d'obtenir des renseignements particuliers associés aux fichiers.
* Recherche de fichier dans l'arborescence : "find"
Il est parfois difficile de localiser précisément un fichier au sein de l'arborescence : "find" permet de retrouver très facilement un ou des fichiers moyennant l'indication (complexe) de plusieurs para¬mètres (qui peuvent être très sophistiqués).
Exemple :
/* liste des fichiers situés sous "/usr" de nom calcul.c */
$ find /usr -name calcul.c -print
/usr/jean/projet_x/c/calcul.c
/usr/marc/essais/calcul.c
/usr/marc/essais/c/calcul.c
$

/* liste de tous les fichiers de plus de 500 blocs ! */
$ find / -size +500 -print
...

* Liens entre fichiers : "ln"
Unix permet de créer des liens sur un fichier c'est à dire qu'un même fichier physique peut avoir plusieurs noms (!). Le contenu ou les attributs du fichier peuvent être modifiés au moyen de n'importe quel nom.

ATTENTION : on ne peut pas créer de liens entre répertoires pas plus qu'entre deux systèmes de fichiers différents.

REMARQUE : Depuis l'avènement de SYSTEM V les liens décrits ci-dessus sont appelés "Hard links" par opposition aux "Symbolic links" qui, eux, permettent des liens entre répertoires ou entre fichiers de systèmes de fichiers différents.
Exemple :
$ ls -l fexiste
-rwx------ 1 gm 5477 Mar 4 16:52 fexiste
$ ln fexiste flien
$ ls -l f*
-rwx------ 2 gm 5477 Mar 4 16:52 fexiste
-rwx------ 2 gm 5477 Mar 4 16:52 flien
$ rm flien
$ ls -l f*
-rwx------ 1 gm 5477 Mar 4 16:52 fexiste
$

crée un lien "flien" sur le fichier existant "fexiste".
3.3. MANIPULATIONS DE FICHIER
3.3.1. RECOPIE DE FICHIER : mv, cp
Les deux commandes possèdent la même syntaxe :

$ mv fichier_ancien fichier_nouveau
$ cp fichier_ancien fichier_nouveau
ou :
$ mv liste_fichier répertoire
$ cp liste_fichier répertoire

Dans le premier cas "fichier_ancien" est recopié dans "fichier_nouveau", alors que dans le second cas la liste de fichiers (à séparer par des espaces) est recopiée dans "répertoire". La différence entre mv et cp est la suivante : cp réalise effectivement une copie alors que mv détruit le(s) fichier(s) original(aux) ce qui consiste à le(s) renommer.

ATTENTION : Si les fichiers destinations existent ils sont purement et simplement écrasés (sauf s'ils sont protégés).
3.3.2. DESTRUCTION DE FICHIER : rm
La commande "remove" rm réalise la destruction de fichiers de la manière suivante : elle décrémente le nombre de liens sur le fichier physique et supprime le nom dans le répertoire concerné. Le fichier est effectivement supprimé physiquement lorsque le nombre de liens tombe à zéro. "rm" dispose de deux options importantes :
* i : fonctionnement interactif avec demande de confirmation de destruction
* r : destruction "récursive" des sous répertoires de niveau inférieur et de leur contenu
3.3.3. VISUALISATION DE FICHIER : cat
La commande cat permet de visualiser sur la sortie standard un fichier texte (en général) mais, comme son nom le sous-entend, elle peut concaténer plusieurs fichiers, quel qu'en soit le type, soit pour les visualiser si ce sont des textes, soit pour les enregistrer dans un autre fichier unique au moyen d'une redirection.
Exemple :
$ cat texte
$ cat texte1 texte2
$ cat texte1 texte2 >résultat
$ cat texte3 texte4 texte5 >> résultat
3.3.4. IMPRESSION DE FICHIERS : pr, lpr
La commande pr permet de mettre en forme un fichier texte avec affichage sur la sortie standard avec découpage en pages de forme variable, ajout d'entête, positionnement multi-colonnes.
Exemple :
$ pr fichier
Pour réaliser l'impression lpr offre un moyen sûr par utilisation d'un "spooler", c'est à dire une gestion de file d'attente.
Exemple :
$ lpr fichier
3.3.5. FILTRE ECRAN : more
Pour pallier l'inconvénient de l'affichage en continu des commandes cat, pr, où il faut sans cesse stopper/relancer l'affichage, la commande more offre un moyen efficace de visualiser à l'écran un ou plusieurs fichiers de façon très pratique, page par page, ligne par ligne... more dispose même d'une aide intégrée en tapant la touche h au lieu de l'espace qui force le passage à la page suivante, ou de return qui affiche seulement la ligne suivante.
Bien évidement, more peut être utilisé pour réaliser un filtre avec l'aide du "*".
Exemple :
$ more fichier f.doc
$ pr fichier.doc | more
3.3.6. COMPARAISON DE FICHIER : cmp, diff
La commande cmp compare deux fichiers désignés, quels que soient leurs types : s'ils sont identiques il n'y a aucun message alors qu'en cas de différence la position du premier caractère différent et sa ligne sont affichés.
Exemple :
$ cmp f1 f2
A la différence de cmp, diff fournit en résultat toutes les différences entre les deux fichiers sous une forme semblable à des commandes de l'éditeur ligne ed. L'option -e permet même d'obtenir la liste des commandes de l'éditeur ed à exécuter pour régénérer f2 à partir de f1.
3.3.7. DECOUPAGE DE FICHIER : tail, split, head
Lorsqu'un fichier devient trop volumineux il peut être nécessaire de le découper en plusieurs sous-fichiers de taille moins importante : c'est le rôle de la commande split
Exemple :
$ split fichier
produira par défaut (si la taille le nécessite) plusieurs fichiers de nom : xaa, xab, xac, ... alors que

$ split fichier morceau.
produira les fichiers morceau.aa, morceau.ab, morceau.ac, ...
Sans vouloir découper un fichier il peut être nécessaire de récupérer (visualiser) une portion de fichier : soit le début du fichier, soit la fin du fichier :
$ head fichier
visualise les 10 premières lignes de fichier alors que
$ tail fichier
visualise les 10 dernières lignes.
Il est possible se préciser en option le nombre de lignes à visualiser :
$ tail -150 fichier
visualise les 150 dernières lignes.
3.4. MANIPULATIONS DE TEXTES
Les commandes qui suivent, tout en permettant de manipuler des fichiers, sont plus particulièrement adaptées au traitement de fichiers Textes ASCII.
3.4.1. COMPTAGE DE CARACTERES : wc
wc compte les lignes, les mots et les caractères d'un fichier.
Exemple :
$ wc fichier
8 48 203 fichier

signifie qu'il y a 8 lignes, 48 mots et 203 caractères dans le fichier.

NOTA : une ligne est constituée par une suite de caractères ASCII terminée par RETURN.
3.4.2. TRADUCTION DE CARACTERE : tr
tr permet de substituer tous les caractères indiqués dans chaîne1 par le caractère de même rang de chaîne2, ceci étant appliqué à l'entrée et la sortie standards.
Exemple :
$ tr axw AXW < fichier > code

transformera tout a en A, tout x en X, et tout w en W.
3.4.3. TRI DE LIGNES DANS UN FICHIER : sort, uniq
sort fournit en sortie standard la liste des lignes triées dans l'ordre lexicographique. Le tri pouvant être adapté en fonction des options spécifiées.
Exemple :
$ sort -o fichier fichier
et non :
sort fichier > fichier

réalise le tri en ordre alphabétique des lignes du fichier.
La commande uniq permet d'éliminer les lignes dupliquées d'un fichier trié au préalable (par sort par exemple).
Exemple :
$ tr -cs A-Za-z '\012' <f | sort | uniq > index
************** *** *** ***

1°) réalise la traduction par tr de tous les caractères non alphabétiques en un NEWLINE (passage à la ligne) en laissant intacts les mots composés de lettres, ce qui fournit une liste de lignes composées de 1 seul mot
2°) tri des lignes par sort
3°) élimination des lignes identiques par uniq
4°) stockage de la liste alphabétique des mots dans le fichier index.
3.4.4. RECHERCHE DE CHAINE DANS UN FICHIER : grep
grep ainsi que egrep permettent d'obtenir les lignes d'un fichier contenant une expression ou chaîne de caractère particulière.
La syntaxe d'utilisation est la suivante :

grep options expression liste_de_fichiers

ATTENTION : expression représente soit la chaîne de caractères, soit de façon plus générale une "expression régulière" pouvant contenir des caractères spéciaux permettant d'affiner la recherche.
Exemple :
$ grep 'emacs' f*.c
recherche la chaîne "emacs" dans tous les fichiers sources C dont le nom commence par f.
$ grep '^emacs' f*.c
fera la même chose mais seulement pour les chaînes situées en début de ligne.
3.4.5. LES EXPRESSIONS REGULIERES
De même qu'une formule mathématique de la forme utilise la notation générique x pour représenter une valeur numérique quelconque il est possible sous UNIX de manipuler des groupes de caractères de façon générale très simple au moyen d'une notation particulière : les expressions régulières

Les expressions régulières sont aux chaînes de caractères ce que les expressions algébriques sont aux nombres. On les appelle régulières car elles obéissent à différentes règles dont les plus importantes sont :

• Tout caractère est une expression régulière équivalente à ce caractère.
• Lors d'une concaténation d'expressions régulières le résultat est une expression régulière équivalente aux caractères équivalents à chaque sous-expression.
Exemple :
$ ls | bin | grep iz
page size
size
$
La spécification de iz dans la commande grep spécifie une expression régulière qui est équivalente à toutes les chaînes composées du caractère i et du caractère z.

Une autre règle va rendre ces expressions très puissantes :

• Le caractère "." est équivalent à n'importe quel caractère.
Exemple :
$ ls
fal file1 file2 fo1 profile1 profile2
$ ls * | grep f.l
fal
file1
file2
profile1
profile2
On voit bien ici que le "." a été substitué par a ou i.
3.4.6. REGLES D'ECRITURE DES EXPRESSIONS REGULIERES
Toute expression régulière est composée de caractères ordinaires et de caractères spéciaux ou métacaractères.

Expression Règle de substitution

un chiffre, une lettre Correspond au caractère lui-même.
minuscule ou majuscule
. Correspond à n'importe quel caractère.
\car Correspond au caractère "car" suivant l'antislash quel qu'il soit, métacaractère ou non.
* Correspond à un nombre quelconque d'occurrences de l'expression régulière qui précède.
[caractères] Correspond à n'importe lequel des caractères indiqués entre les crochets. Une plage de caractères peut être notée en indiquant les deux extrêmes séparés par un tiret. [0-9a-z] correspond à tout caractère numérique ou lettre minuscule.
^ Correspond au début d'une ligne de texte si placé en tête d'expression régulière. Utilisé dans les crochets et placé en tête permet d'exclure les caractères qui suivent dans les
crochets.
$ Correspond à la fin d'une ligne de texte si placé en fin d'expression régulière.
+ Correspond à une ou plusieurs occurrences de l'expression régulière qui précède.
? Correspond à 0 ou 1 occurrence de l'expression régulière qui précède.
expr1 expr2 Forme une expression régulière correspondant à toute chaîne
correspondant à expr1 puis à expr2, etc.
(expr) Encapsule une expression ce qui permet aux métacaractères de traiter l'expression expr comme une simple expression.
* Sépare plusieurs expressions régulières consécutives.

Les règles ci-dessus peuvent être associées pour réaliser des expressions complexes lesquelles pourront être utilisées avec des commandes telles que : ed, vi, ex, sed, grep.
Exemple :
$ grep '#\.' fichier

recherche toutes les chaînes "#." dans fichier. L'intérêt des apostrophes est intéressant car sans elles le shell risque, lui aussi, d'interpréter certains caractères. Sans apostrophes il eût fallu écrire :

$ grep #\\. fichier
4. LE LANGAGE DE COMMANDES SHELL
4.1. LE LANGAGE DE COMMANDE
Le "langage shell" est non seulement un langage de commandes mais pratiquement un langage de programmation : on y retrouve en effet les notions de variables et de structures de contrôle évoluées existant dans les langages procéduraux avec ici les commandes dans le rôle des instructions.
Il existe trois shell classiques depuis le plus ancien (et le plus simple) : le shell BOURNE jusqu'aux plus récents C-SHELL et KORN-SHELL.
4.2. SYNTAXE DES COMMANDES
Après ouverture d'une session l'utilisateur se trouve sous le contrôle de l'interpréteur de commandes : le "SHELL". Le caractère d'invite par défaut, ou prompt, "$" s'affiche invitant l'utilisateur à frapper une commande. Shell fournit l'interface avec le système UNIX en offrant la possibilité d'exécuter un ensemble de programmes ou utilitaires ainsi qu'un puissant langage de commande permettant d'automatiser et d'enchaîner les programmes.
Toute commande shell doit respecter rigoureusement la syntaxe d'écriture générale suivante :

commande [option1[option2[...]]] [fichier1[ fichier2 ]
avec :
* commande : nom de la commande (quelques caractères ... pas toujours très parlants)

* option : indication des différentes options qu'il est possible d'associer à la commande pour en moduler son exécution; elles consistent, en général, en un ou plusieurs caractères précédés d'un tiret.

* fichier : liste de fichier(s) traité(s) par la commande.
Exemple :
$ ls -l cal*.c
$ ps -al

Plusieurs commandes peuvent être spécifiées sur la même ligne (avant la frappe du Retour Chariot) à condition de les séparer par un point virgule. Une commande très longue peut être poursuivie sur la ligne suivante à condition de précéder la fin de ligne de l'antislash "\", shell affichant alors le prompt secondaire qui, par défaut, est ">".

REMARQUES :
1. UNIX ne supporte pas les abréviations de commandes (comme VAX/VMS de DIGITAL).
2. Les caractères ";" et "\" sont des caractères spéciaux ou métacaractères.

On notera que, sous UNIX, l'écho des caractères frappés n'est pas réalisé par le shell mais directement par le pilote (driver) du terminal ce qui signifie que tout caractère frappé est affiché aussitôt à l'écran même si la commande précédemment lancée n'a pas terminé son exécution (!). Une com¬mande correspond, en général, à un fichier exécutable dont le shell provoque l'exécution. Ce fi¬chier sera d'abord localisé en tenant compte de la présence ou de l'absence du caractère slash "/" dans la chaîne de caractères de la commande :

* s'il y a un "/" c'est une spécification absolue ou relative de chemin d'accès à un fichier avec indication de répertoire,

*@@ hashcoding s'il n'y a pas de "/" il y a recherche du fichier dans une liste ordonnée de répertoires (variable Shell PATH) qui contient, en général, /bin, /usr/bin et enfin le répertoire courant de l'utilisateur. Cette liste or¬donnée n'est pas figée et peut être modifiée à volonté par l'utilisateur.
4.3. PRINCIPE DE FONCTIONNEMENT DU SHELL
Le shell est lui-même une commande, "sh", "csh" ou "ksh", c'est à dire un fichier exécutable situé sous /bin ou /usr/bin. En début de session, UNIX associe au terminal utilisateur un processus shell qui interprète toute commande reçue sur ce terminal. Son principe de fonctionnement est alors le suivant :

REPETER
saisir commande frappée au clavier
créer un processus par fork()
SI le processus est le processus-fils
ALORS exec(commande)
SINON attendre fin du processus fils par wait()
FINSI
FINREPETER

Il est, dès lors, tout à fait possible d'exécuter plusieurs shell et de les "empiler" par :

$ sh
$ sh
$ ps
PID TTY TIME CMD
961 02 0 : 21 -sh Shell d'origine
1239 02 0 : 01 sh 1ère commande Shell
1240 02 0 : 01 sh 2ème commande Shell
1241 02 0 : 03 ps Commande "ps"
$
La commande "ps" montre la liste des processus actifs pour l'utilisateur. Le programme sh admet un fichier d'entrée où sont lues toutes les commandes et un fichier de sortie où sont écrits les résultats de l'exécution. En général, ces deux fichiers sont assignés au terminal ; il s'en déduit que pour terminer l'exécution d'une commande "sh" il faut fermer le fichier d'entrée en frappant "Ctrl-D" (contrôle et D) qui est le caractère de fin de fichier sous UNIX. De ce type de fonction¬nement on retiendra que shell n'est pas un programme privilégié et qu'il est possible de définir un nouvel interpréteur sans toucher au noyau d'UNIX. D'autre part les règles de recherche de fi¬chiers sont strictement propres au shell. Enfin, l'exécution des commandes utilise les deux primi¬tives fork() et exec() ce qui provoque la création d'un processus fils pour la grande majorité des commandes exécutées. Dans le fonctionnement du shell on a vu ci-dessus que le processus "sh" at¬tend la fin d'exécution du processus fils (exécutant la commande). Cette attente peut être suppri¬mée en frappant le caractère "&" (ampersand) en fin de commande; on dit alors que la commande s'exécute en arrière plan (background). Après lancement de la commande, shell affiche le numéro du proces¬sus associé (PID), lequel peut être vérifié par la commande "ps". Ce PID peut être utilisé pour stopper l'exécution du processus (et donc de la commande) au moyen de "kill". D'autre part, la commande "nice" permet de diminuer (mais pas d'augmenter) la priorité d'exécution du processus en arrière plan.
Exemple :
$ cc calcul.c&
1255
$ ps
PID TTY TIME CMD
321 02 0 : 35 -sh
1255 02 0 : 01 cc calcul.c
1256 02 0 : 01 ps
$
4.4. LES CARACTERES SPECIAUX
La plupart des commandes UNIX demandent ou acceptent des noms de fichiers en para¬mètres. Il peut être pratique de spécifier de façon abrégée les noms de ces fichiers au moyen de caractères spéciaux ou métacaractères :

* "*" permet de remplacer 0, 1 ou plusieurs caractères quelconques,
* "?" permet de remplacer un caractère unique.
Exemple :
ls -l *.c
exécute la commande "ls -l" pour tous les fichiers de type ".c" quel que soit le nom,
ls -l ??.*
liste tous les fichiers de n'importe quel type mais dont le nom comporte deux caractères exclusivement.

Il est également possible de spécifier un ensemble de caractères en extension ou par inter¬valle en précisant le premier et le dernier (dans l'ordre lexicographique) séparés par un tiret et le tout encadré par des crochets, ces constructions particulières de métacaractères sont appelées expressions régulières.
Exemple :
$ echo *
cat copy icheck mkfs mnt boot restor
$ echo [c-i]*
cat copy icheck
$
On notera la facilité de nommer des fichiers au moyen de ces métacaractères. C'est aussi pour cela que l'on s'efforcera de respecter les règles simples de nommage des fichiers en ce qui concerne le type avec, selon la convention générale Unix, ".c" pour les sources C, ".p" pour les sources Pascal, ".s" pour les sources assembleur, ".f" pour les sources Fortran, ".o" pour les fichiers objets...
Autant les métacaractères peuvent offrir d'immenses facilités à la frappe des commandes, autant il peut être difficile d'utiliser ces caractères dans un rôle non particulier : il faut pouvoir annuler leur fonction spéciale, ce qui est réalisé en faisant précéder le caractère en question d'un antislash "\", ce dernier pouvant lui même être annulé en le doublant. Toutefois, pour une chaîne de caractères l'usage du "\" s'avère vite fastidieux et il est alors préférable d'utiliser les apos¬trophes simples (') ou doubles (") pour encadrer ladite chaîne. Avec les apostrophes simples aucun des caractères de la chaîne n'est plus interprété alors que dans l'autre cas seuls les caractères apos¬trophe simple ('), antislash (\), apostrophe double (") et dollar ($) sont interprétés.
4.5. PROCEDURES DE COMMANDE
On appelle procédure de commande (ou fichier de commandes) shell script en anglais, un fichier texte conte¬nant une suite de commandes. Pour exécuter cette procédure de commandes il suffit de l'assigner en fichier d'entrée au Shell. Par défaut, la commande "sh", exécutée sans paramètre, implique que le fichier d'entrée est assigné au terminal; par contre, si un nom de fichier est passé, il est pris pour fichier d'entrée. On n'oubliera pas que le fichier en question doit être accessible en lecture. Il est également possible de lancer directement l'exécution d'une procédure en tapant son nom pourvu qu'elle ne soit pas protégée en exécution.
Exemple :
$ cat commande
echo "execution commande"
ps
echo "fin d'execution"
$ ls -l commande
-rw-rw-r-- 1 dupond 46 Mar 19 12:46 commande
$ sh commande
execution commande
PID TTY TIME CMD
296 02 0:21 -sh
418 02 0:01 sh commande
419 02 0:01 ps
fin d'execution
$ chmod u+x commande
$ ls -l commande
-rwxrw-r-- 1 dupond 46 Mar 19 12:46 commande
$ commande
execution commande
PID TTY TIME CMD
296 02 0:21 -sh
438 02 0:01 commande
440 02 0:01 ps
fin d'execution

Des options de la commande sh permettent de piloter l'exécution de la procédure de commandes :

* "-n" : lit les commandes sans les exécuter (voir man sh),
* "-v" : visualise sans interpréter les commandes avant exécution,
* "-x" : visualise après interprétation les commandes.

Dans la procédure de commandes il est possible d'utiliser des métacaractères destinés à regrouper des commandes : les accolades et les parenthèses (voir plus loin...). Ces dernières per¬mettent de forcer l'exécution des commandes qu'elles englobent dans un autre processus, dit "sous-shell" (créé par un fork) qui va exécuter les commandes par la technique du "fork-exec" sauf pour la dernière commande qui sera exécutée par un exec de façon à forcer la fin du processus sous-shell. L'environnement dans lequel s'exécutent les commandes entre parenthèses est celui du sous-shell ce qui signifie que les actions locales à cet environnement (telle un changement de réper¬toire) ne se répercutent pas sur l'environnement du shell de départ.

REMARQUE: toute ligne débutant par "#" est considérée comme commentaire par le Shell.
4.6. RE-DIRECTIONS
Toute application dans UNIX peut se décomposer en un ensemble de programmes orga¬nisés séquentiellement : chaque programme travaille sur des données fournies en entrée, les traite et produit des données en sortie; ces données de sortie peuvent ensuite être prises en compte comme données d'entrée par le programme suivant, etc. Le cheminement des données est assimilé à une structure "pipe-line", principe fondamental d'UNIX et que Ritchie et Kernighan résument en disant que "les programmes sont des filtres transformant les flux de données". Pour ce faire, tout programme travaille sur trois fichiers :

* le fichier d'entrée (standard input, stdin) contenant les données d'entrée,
* le fichier de sortie (standard output, stdout) contenant les résultats,
* le fichier d'erreur (standard error, stderr) contenant les éventuels messages d'erreur.

D'un point de vue système l'exécution d'un programme est réalisée au moyen du méca¬nisme "fork + exec" : c'est juste avant l'exec que le programme doit définir les fichiers standards à moins qu'il ne conserve ceux hérités du processus père. Ces trois fichiers sont décrits dans la table des fichiers ouverts par un numéro de descripteur normalisé : 0 pour l'entrée, 1 pour la sortie et 2 pour les erreurs. Tout programme lancé par exec s'attend à trouver ces trois fichiers ouverts. Par la suite le programme manipule ces fichiers au moyen du descripteur associé ce qui assure une indé¬pendance totale du programme vis à vis des fichiers et des terminaux effectivement utilisés. Par défaut, tout processus récupère les trois fichiers standards par héritage de son créateur à l'exception du shell lancé en début de session pour lequel le noyau assigne en général le terminal de connexion. La convention générale veut qu'une commande travaille sur le(s) fichier(s) spéci¬fié(s) en paramètre(s) ou, sinon, sur l'entrée standard. Il peut être intéressant dans certains cas de modifier ces assignations par défaut, c'est ce qui est appelé la "re-direction" des fichiers standards utilisable sous shell au moyen d'opérateurs spécifiques.

* L'opérateur ">" re-définit le fichier de sor¬tie sur le nouveau fichier désigné.
Exemple :
$ who > liste n'affichera rien !
$ cat liste affichera le résultat de la commande who.

La notion de fichier banalisé fait que la sortie peut aussi être redirigée sur un périphérique (dans la mesure où il n'est pas déjà occupé ni protégé).

* L'opérateur ">>" réalise une re-direction de la sortie standard mais les données sont ajoutées en fin de fichier alors qu'avec ">" un nouveau fichier est créé, quitte à écraser le précé¬dent s'il existait déjà.

* L'opérateur "<" réalise la re-direction du fichier standard d'entrée:
Exemple :
$ wc -l < liste
5
$

* L'opérateur "<<" re-définit le fichier standard d'entrée comme étant l'ensemble des lignes (du fichier d'entrée en cours) comprises entre le mot qui suit le "<<" et le même mot en début de ligne dans la suite du fichier.Le petit exemple suivant permettrait de mieux comprendre les effets de cet opérateur :
sh> << fin
> echo "essai"
> echo "essai 1"
> fin
sh>
provoque l'affichage suivant :
essai
essai 1

La re-direction du fichier standard d'erreur est possible à condition de placer le descripteur associé, 2, devant le ">".
Exemple :
$ cc calcul.c 2>erreurs
La re-direction peut également se faire vers un autre fichier déjà ouvert à condition d'ajouter après le ">" le signe "&" suivi du numéro de descripteur dudit fichier comme suit :

$ cc calcul.c >essai 2>&1
$ cat essai
"calcul.c", line 7 : xyz undefined
$
Dans ce cas le fichier "essai" est défini comme fichier standard de sortie et d'erreur.

Pour faire coopérer deux programmes il est possible de stocker les sorties du premier dans un fichier, ce fichier étant ensuite utilisé en entrée du second. Mais il existe un mécanisme bien plus perfor¬mant travaillant directement en mémoire centrale et réalisant le transfert de la sortie de l'un vers l'entrée de l'autre : le tube (pipe), ce qui est indiqué par l'opérateur "|".
Exemple :
$ who > liste
$ wc -l <liste
est équivalent à :
$ who | wc -l

En interne cette "commande" correspond à la création de deux processus who et wc commu¬niquant entre eux.

Généralement, les résultats intermédiaires d'un tel filtre ne sont pas intéres¬sants en tant que tels mais s'il s'avère nécessaire de les mémoriser dans un fichier la commande "tee" convient à cet effet : elle passe les informations au programme qui suit tout en les stockant dans un fichier.
Exemple :
$ who | tee liste | wc -l
5
$
...mémorise dans "liste" la liste des utilisateurs.
4.7. LE SHELL BOURNE
Dû à Steve BOURNE, c'est le plus ancien des shell (déjà présent sur UNIX Version 7) ; il est à la base des shells "modernes", C-Shell et KORN-Shell : sa connaissance est nécessaire dans la mesure où il subsiste encore de nombreuses procédures de commandes écrites en Bourne Shell. Dans ce qui suit on trouvera l'explication de ses principes fondamentaux de fonctionnement qui viennent compléter les explications précédentes.
4.7.1. LES VARIABLES SHELL
Une variable shell est identifiée par un nom (chaîne de carac¬tères commençant par une lettre) et a pour valeur une chaîne de caractères. Elle est utili¬sable au niveau interpréteur de commandes et procédures de commandes. L'affectation se fait au moyen du signe "=" sans espaces de séparation et la référence au contenu de la variable est obtenue en nommant la variable précédée du signe dollar "$".
Exemple :
sh> variable=valeur
sh> echo $variable
valeur
sh> rep=/user/dupond/c
sh> cd $rep
sh> pwd
/usr/dupond/c
sh>
Il peut être nécessaire d'encadrer le nom de la variable par des accolades afin de la dis¬tinguer des caractères qui suivent :

sh> variable0=0
sh> variable1=111
sh> v=variable
sh> echo $V1 n'affichage rien car variable V1 pas défini

sh> echo ${v}1
variable1
sh>
4.7.2. VARIABLES PREDEFINIES
Certaines variables sont pré-définies, soit par le shell, soit par UNIX.

* Variables prédéfinies par Shell :

# : nombre de paramètre(s) passé(s) à la commande,
? : valeur retournée par la dernière commande exécutée,
$ : PID de l'interpréteur de commandes,
! : PID du dernier processus lancé en arrière plan,
- : options utilisées par le shell.

* Variables prédéfinies par UNIX (ou variables d'environnement) :

HOME : paramètre par défaut (répertoire de base) de la commande cd,
PATH : liste ordonnée des répertoires à parcourir pour la recherche d'un programme exécutable,
PS1 : prompt principal ("$" par défaut) envoyé par le shell,
PS2 : prompt secondaire (">" par défaut) envoyé par le shell,
IFS : séparateur de champs dans les commandes (par défaut : espace, tabulation et fin de ligne).
TERM : Type de terminal utilisé.
Exemple :
sh> echo $PS1
sh>
sh> PS1='%'
%
% PS1='sh'
sh> echo $PATH
/bin/:/usr/bin/:/usr/dupond/bin/:.
sh>
Certaines de ces variables sont initialisées dès le début de session, telles HOME avec le répertoire de connexion et PATH avec "/bin/:/usr/bin/:".

Pour une modification systématique de variables ou l'exécution de procédures de com¬mandes spécifiques une procédure de com¬mandes spéciale de nom ".profile", située dans le réper¬toire de base de l'utilisateur, est exécutée à chaque début de session.
4.7.3. RECUPERATION DE RESULTATS DE COMMANDE
Une variable shell peut direc¬tement récupérer le résultat (une chaîne de caractères) de l'exécution d'une commande (depuis sa sortie standard) par utilisation de l'accent grave avant et après la commande :

sh> c=`pwd`
sh> echo $c
/usr/dupond/fortran
sh>
4.7.4. TRANSMISSION DE PARAMETRES
La communication entre interpréteur de commandes et procédures de commandes est réalisée au moyen des variables shell. Toutefois une variable shell n'est connue qu'à un niveau donné du shell ou que dans une même procédure : la portée est donc limitée. En utilisant la commande "export" il est possible de spécifier les variables qui seront recopiées dans le contexte de la procédure appelée. On peut même interdire la modifi¬cation d'une variable par "readonly".

La transmission peut être réalisée à l'appel de la procédure : les paramètres sont alors transmis par valeur et utilisables par la procédure appelée au moyen de leur numéro de position dans la liste des paramètres à l'appel, le paramètre 0 correspondant au nom de la procédure elle-même (d'où le nom de paramètres positionnels).
Exemple :
sh> cat proc
echo $0; echo $1; echo $2
sh> sh proc un deux trois
proc
un
deux
sh>

REMARQUE : les variables shell * et @ représentent l'ensemble des paramètres à partir du paramètre numéro un.
Exemple :
sh> cat proc
echo $*
sh> sh proc un deux trois
un deux trois
sh>
4.7.5. TRAITEMENT DES COMMANDES
Shell est un "processeur" de commandes qui réalise des substitutions après analyse syntaxique et avant exécution des commandes de la façon sui¬vante :
1) évaluation des variables,
2) substitution de commande,
3) interprétation des séparateurs,
4) expansion des noms de fichiers (*, ?, [ et ]) avec prise en compte des métaca¬ractères (\, ', ").

Pour pallier l'inconvénient de l'évaluation unique il existe la commande "eval" qui, elle, évalue complètement tous les paramètres de la ligne.
Exemple :
sh> A='>file'
sh> echo a b c $A
produira le résultat :
a b c >file
parce que le caractère > n'a pas de signification particulière après substitution, mais
sh> A='>file'
sh> eval echo a b c $A
mémorisera "a b c" dans le fichier "file".

sh> A='$B'
sh> B='abcdefgh'
sh> echo $A
sh> eval echo $A
affichera :
abcdefgh
pour le premier "echo" il y a une seule substitution.
4.7.6. LES COMMANDES INTERNES
Dans la majorité des cas, pour exécuter une com¬mande, shell crée un processus fils au moyen du fork-exec. il existe toutefois quelques commandes internes (built-in) à shell qui ne conduisent pas à la création de processus et pour lesquelles, hélas, il n'est pas possible, en général, de re-diriger les entrées-sorties :

• # ) tout ce qui suit jusqu'à la fin de ligne est un commentaire,
* . fichier ) shell exécute les commandes du fichier dans le contexte courant,

* break, continue ) gestion de boucle (voir plus loin),

* cd ) changement de répertoire,

* eval ) évaluation des arguments et utilisation du résultat comme entrée du shell,

* exec ) la commande passée en argument est exécutée en lieu et place du shell,

* exit ) fin d'exécution de procédure de commande avec retour éventuel d'un code d'état à préciser,

* export ) les variables précisées en paramètres sont placées dans l'environnement d'exécution des commandes,

* login ) pour ouverture/fermeture de session,

* newgrp ) pour changer de groupe dans la mesure où l'utilisateur appartient à plusieurs groupes,

* read ) lecture de données sur l'entrée standard,

* readonly ) protège en écriture des variables shell,

* set ) modifie l'exécution du shell suivant le paramètre :
-n : commandes lues mais non exécutées,
-v : affichage des lignes de commandes lues par shell,
-x : affichage des lignes traitées juste avant exécution,
- : annule -x et -v
"set" seul affiche les paramètres actifs.

* shift ) décalage à gauche des paramètres positionnels: $2 devient $1,...

* times ) affiche le temps d'exécution d'un processus,

* trap ) la commande passée en 1er argument sera exécutée sur détection d'un signal pré¬cisé en 2ème argument,

* umask ) masque de protection par défaut utilisé à la création de tout fichier et à passer sous forme octale (3 digits),

* wait ) le processus attend la fin d'exécution de tous ses sousprocessus.
4.7.7. LES STRUCTURES DE CONTROLE
On trouve sous shell les structures de contrôle classiques issues de la programmation structurée (alternative et itération) au moyen des mots clés suivants : if, then, else, elif, fi, case, in, esac, for, while, until, do, done; ces mots clés devront toutefois être placés en début de ligne de commande pour pouvoir être reconnus par shell. D'autre part, toute commande, sauf les excep¬tions ci-dessus, est exécutée par un processus fils pour lequel le père se met en attente par wait, laquelle fonction retourne le PID du fils et un code d'état qui, par convention, vaut 0 si l'exécution a été correcte.
4.7.7.1. LA STRUCTURE IF - THEN - ELSE :
if liste1 de commandes
then liste2 de commandes
else liste3 de commandes
fi

"liste1 de commandes" est une suite de commandes séparées par ";", interprétées de la gauche vers la droite et de résultat 0 si l'exécution de la dernière commande a été correcte; dans ce cas, le THEN est exécuté, sinon c'est le ELSE. La commande "test" permet de réaliser des tests plus poussés sur le type ou les protections d'un fichier ainsi que sur des chaînes de caractères; il existe même des opérateurs logiques tels que : "-a" pour AND, "-o" pour OR, && et ||.
Exemple :
sh> cat compare
if test $1 = $2
then echo "$1 et $2 sont identiques"
else echo "$1 et $2 sont différents"
fi
sh> sh compare AA BB
AA et BB sont différents
sh> sh compare AAA AAA
AAA et AAA sont identiques
sh>
sh> cat statut
if test -f $1 -a -r $1 -o -w $1
then echo "$1 accessible en Read, Write ou les deux"
else echo "$1 protégé en rw"
fi
sh> ls -l fichier
-rw-r--r-- 1 dupond 153 Mar 21 21:59 fichier
sh> sh statut fichier
fichier accessible en Read, Write ou les deux
sh> chmod -rw fichier
sh> ls -l fichier
---------- 1 dupond 153 Mar 21 21:59 fichier
sh> sh statut fichier
fichier protégé en rw
sh>
Dans le cas de plusieurs if imbriqués "elif" permet de condenser la notation.
4.7.7.2. LA BOUCLE FOR
for variable in val1 val2 val3 ...
do liste de commandes
done
Variable est une variable shell prenant pour valeurs successives val1, val2, val3,... lors de chaque exécution de la liste de commandes placée entre DO et DONE.
Exemple :
sh> cat bouclefor
for i in un deux trois
do echo $i
done
sh> sh bouclefor
un
deux
trois
sh>
Si les valeurs de la variable sont omises, la boucle est effectuée pour chacune des valeurs des paramètres positionnels, c'est à dire"$*".
4.7.7.3. LA BOUCLE WHILE
while liste1 de commandes
do liste2 de commandes
done
Si la valeur retournée par la dernière commande de la liste1 vaut 0 la liste2 est exécutée, sinon la boucle est terminée.
Exemple :
sh> cat bouclew
while test $# -ne 0
do
echo $1
shift
done
sh> sh bouclew 1 2 3
1
2
3
sh>
La boucle UNTIL est la symétrique de WHILE avec répétition jusqu'à ce qu'une condi¬tion soit satisfaite.
Exemple :
sh> cat attente
until test -f fichier
do
echo "attente de fichier"
sleep 10
done
echo "le fichier a été créé !"
sh> ls fichier
fichier: not found
sh> sh attente&
2428
sh> attente de fichier
attente de fichier
cat >fichier
^D
sh> le fichier a été créé !
4.7.7.4. L'INSTRUCTION CASE
case variable in
mot1) liste1 de commandes ;;
mot2) liste2 de commandes ;;
...
esac

Shell recherche le cas satisfait par variable : s'il en existe un, la liste de commandes asso¬ciée est exécutée. Les métacaractères "*", "?", "[" et "]" sont utilisables de la même manière que pour les noms de fichiers, ainsi que l'opérateur "|" (ou) pour regrouper plusieurs cas.
Exemple :
sh> cat case
for i
do
case $i in
a) echo 'occurrence de "a"';;
b) echo 'occurrence de "b"';;
?) echo 'occurrence de caractère autre que a et b';;
*) echo 'occurrence de chaîne de plus de 1 caractère';;
esac
done
sh> sh case a b c dd
occurence de "a"
occurrence de "b"
occurrence d'un caractère autre que a et b
occurrence d'une chaîne de plus de 1 caractère
sh>
4.7.7.5. TRAITEMENT DES EVENEMENTS
Sous Unix un processus peut recevoir un signal c'est-à-dire une interruption matérielle ou logicielle (on parle alors plutôt d'exception logicielle) pour signifier un événement particulier : problème matériel, fin de saisie au terminal, ordre de destruction (kill), reçu d'un autre processus. Ce signal pourra être géré par le processus récepteur. Pour un processus exécutant le Shell la commande trap demande au programme Shell d'exécuter la commande donnée lorsque survient l'un des signaux indiqués. Si aucune commande n'est indiquée trap repositionne le signal donné à sa valeur originale. Si la commande consiste en une chaîne vide le Shell ignore le signal. Si le numéro de signal vaut 0 le Shell exécute la com¬mande lors de la fin de son exécution. Utilisée sans paramètre la commande trap affiche les signaux et la commande associée pour tous les signaux gérés par Shell.

Liste des signaux pouvant être interceptés par le Shell :
1 hangup Perte de la porteuse dans une communication
2 Intr Interruption de commande (Touche DEL ou Ctrl.C)
3 quit Fin d'exécution
9 Kill Destruction du processus
Exemple :
sh>trap 'rm *.tmp; exit 1' 1 2 9
Exemple :
sh> cat trappe
trap 'echo je prends le Ctrl-C' 2
for i in 1 2 3
do
echo "j'attends"
sleep 10
done
sh> sh trappe
j'attends
^Cje prends le Ctrl-C
j'attends
^Cje prends le Ctrl-C
j'attends
sh>
On peut ainsi ou provoquer le traitement d'une commande spécifique ou laisser le fonc¬tionnement standard (arrêt de la procédure). Toutefois, la commande "nohup" (no hangup) permet de forcer la non prise en compte de ces signaux.
Exemple :
sh> cat rebours
trap 'continue' 2 # 'continue' force le passage à la boucle suivante
for i in 5 4 3 2
do
echo "on arrete dans $i minutes"
sleep 60
done
trap '' 2
echo "on s'arrete dans 1 minute"
sleep 60
echo "c'est fini !"
sh> sh rebours
on s'arrete dans 5 minutes
^C
^C
on s'arrete dans 3 minutes
^C
^C
on s'arrete dans 1 minute
^C^C^Cc'est fini !
sh>
4.8. LE "C-SHELL"
C-Shell est un autre interpréteur de commandes développé à BERKELEY et dérivé du shell standard BOURNE dont il constitue une extension. Parmi les nouvelles fonctionnalités on citera :

* L'édition des commandes par mémorisation d'un historique des commandes avec possi¬bilité de les rappeler au moyen de "!", de les modifier et de les relancer.
* La gestion des "jobs.
* La fonction d'alias qui permet la définition de synonyme de commandes.
* La protection contre l'écrasement involontaire d'un fichier existant lors d'une redirection (seulement) au moyen d'une variable binaire "noclobber" qui sera positionnée à 1 pour éviter tout ennui (Rappel: UNIX ne gère pas les versions de fichiers !).
* Un langage de commandes différent de celui du shell BOURNE et très proche du lan¬gage C d'où le nom de cet interpréteur.
4.8.1. HISTORIQUE DES COMMANDES
Toutes les commandes entrées au clavier sont mémorisées et constituent l'historique. La taille de cet historique peut être modifiée en modifiant la valeur de la variable numérique history. La commande history fournit la liste des dernières commandes, sachant qu'elles sont numérotées à partir de 1. Les dernières commandes mémorisées peuvent être rappelées pour édition éventuelle et ré-exécution en entrant le point d'exclamation ! suivi du numéro de la commande ou d'une séquence de caractères d'une des commandes. Les possibilités d'édition sont très variées mais on citera principalement :

!!
rappelle et exécute la dernière commande

!n:s/ch1/ch2
substitue ch1 par ch2 dans la commande n

^ch1^ch2
substitue ch1 par ch2 dans la dernière commande entrée

!?chaine?
rappelle et exécute la dernière commande contenant chaine

Exemple :
csh> alias hi history
csh> hi
1 alias hi history
2 hi
csh> ps -x
PID TT STAT TIME COMMAND
4155 01 I 0:04 -csh (csh)
4195 01 R 0:00 ps -x
csh> hi
1 alias hi history
2 hi
3 ps -x
4 hi
csh> !p
ps -x
PID TT STAT TIME COMMAND
4155 01 I 0:04 -csh (csh)
4196 01 R 0:00 ps -x
csh>
4.8.2. SYNONYMES DE COMMANDES : alias, unalias
C Shell conserve une liste des alias ou synonymes de commandes établis par la commande alias et détruits par unalias. Lorsque le shell analyse une ligne de commandes il scrute la ligne de gauche à droite et vérifie s'il n'y a pas d'alias afin de les traduire systématiquement (y compris de façon récursive si besoin !).
Exemple :
csh> alias
hi history
vt100 set term = vt100
csh> alias ll 'ls -l'
csh> ll
total 3
drwxr-xr-x 6 root 512 Mar 1 11:51 apii4
drwxr-xr-x 2 root 512 Mar 9 14:56 apii5
drwxr-xr-x 5 root 512 Mar 9 09:26 profs
csh> alias
hi history
ll ls -l
vt100 set term = vt100
csh>
4.8.3. GESTION DES "JOBS"
C-Shell associe un index de JOB à chaque commande (ou filtre réalisé avec des "pipelines") qu'il doit exécuter. La commande jobs permet d'afficher la liste des jobs en cours de traitement, chacun d'entre eux étant répertorié au moyen d'un numéro : lorsqu'il y a plusieurs jobs simultanément le premier à avoir été lancé est indiqué par un + tandis que le suivant est indiqué par un -. Toute commande lancée en "background" au moyen du & se voit associée un job numéroté comme indiqué dans l'exemple ci-après. Sur un terminal donné un seul job est en "foreground" mais plusieurs autres jobs peuvent travailler en "background", le détail des jobs étant fourni par la commande jobs. Une commande lancée en "foreground", un job lui étant associé d'office, pourra être passée en "background" à condition d'interrompre le job par Ctrl-Z ce qui permet au shell courant de "reprendre la main", puis de faire passer le job en question en "background" par la commande bg ; la commande fg permet, elle, de repasser un job background en foreground en indiquant directement le numéro de job précédé de %. Si un job doit être détruit il suffit de "signaler" le job par kill %n où n représente le job à détruire.
Exemple:
csh> man sh > sh.doc &
[1] 4140
csh> man csh > csh.doc &
[2] 4145
csh> man ksh > ksh.doc &
[3] 4150
csh> jobs
[1] + Running man sh > sh.doc
[2] - Running man csh > csh.doc
[3] Running man ksh > ksh.doc
csh> kill %1
[1] Exit 1 man sh > sh.doc
csh> jobs
[2] + Running man csh > csh.doc
[3] - Running man ksh > ksh.doc
csh> %2
man csh > csh.doc
^Z
Stopped
csh> jobs
[2] + Stopped man csh > csh.doc
[3] - Running man ksh > ksh.doc
csh> fg %3
man ksh > ksh.doc
^Z
Stopped
csh> kill %3
[3] Exit 1 man ksh > ksh.doc
csh> fg
man csh > csh.doc
^Z
Stopped
csh> bg
[2] man csh > csh.doc &
csh> jobs
[2] Running man csh > csh.doc
csh>
4.8.4. CREATION DE SHELL SCRIPTS EN C-SHELL
Les règles d'écriture des shell-scripts C-Shell sont très voisines de celles utilisées en Shell Bourne.
Exemple :
csh> cat > swaps
mv $1 swaps.tmp
mv $2 $1
mv swap.tmp $2
^D
csh> chmod u+x swap
csh> ls
f1 f2 f3
csh> swaps f1 file1
csh> ls
file1 f2 f3
4.8.5. COMMENTAIRES EN C-SHELL
En se souvenant de l'interêt fondamental de commenter les programmes en informatique on pensera également à commenter les procédures de commandes. En shell, le caractère dièse # force la non prise en compte depuis le dièse inclus jusqu'à la fin de la ligne de la procédure de commande (principe valable aussi en shell BOURNE).
Toutefois, pour C-Shell, le signe # permet de fournir une indication très importante quant au bon interprêteur shell à utiliser pour exécuter une procédure de commande : shell Bourne, C-shell ou autre de la manière suivante :
* Placer en première ligne et en premier caractère le signe # ; mais ceci s'avère gênant car ressemble au caractère de début de commentaire.
* Pour éviter toute confusion il suffit d'adjoindre au caractère # un point d'exclamation ce qui force C-Shell à interpréter le reste de la ligne comme une commande shell ordinaire qui peut être la spécification du shell à exécuter /bin/sh ou /bin/csh suivant le shell à exécuter.
Exemple :
csh> cat shell_C
#! /bin/csh
# commentaire
...
csh>
Ainsi, C-Shell exécutera la liste des commandes du shell script au moyen du shell indiqué en première ligne.
4.8.6. VARIABLES C-SHELL
C-Shell permet, tout comme le shell Bourne, la manipulation de variables. Elles sont toutefois de trois types :
- chaînes de caractères,
- nombres entiers,
- variables binaires on ou off.

Pour initialiser ou modifier une chaîne de caractères on utilisera la commande set selon la forme générale suivante :

csh> Set var = chaîne

chaîne est alors affectée, en tant que chaîne de caractères à la variable var.

Si une chaîne doit contenir des espaces il faudra l'encadrer par des apostrophes

csh> set phrase = "essai d'utilisation d'espaces"

Une variable numérique entière s'initialise comme une variable de type chaîne mais peut se manipuler avec @.

set nombre = 15
@ nombre = $nombre + 12
@ nombre = ($nombre + 3) / 8

ATTENTION :Les 4 opérateurs arithmétique +, *, /, - peuvent être utilisés mais on notera l'obligation de séparer opérandes et opérateurs par au moins un espace.
Une variable binaire sera à l'état "on" si elle a été initialisé simplement par :

set variable

Si elle n'a pas été initialisé elle est considéré à off.

La destruction des variables C-Shell est réalisé au moyen de :
unset variable
Les variables C-Shell sont utilisables à condition de faire précéder leur nom du signe dollar $.

csh> set nb = 15
csh> set chaîne = "essai de chaîne longue"
csh> echo $chaîne
essai de chaîne longue
csh> echo $nb
15
csh>

C-Shell permet de manipuler des tableaux de mots (multi Word string) à condition d'affecter à une variable la liste des mots entre parenthèses.
Exemple :
csh> set liste = (liste de mots)
csh> echo liste[3]
mots

on voit ici qu'il est dès lors possible de référencer un mot dans la liste des mots à condition d'indiquer sa position entre crochets.
Exemple :
csh> set liste = (Essai de liste de mots)
csh> set index = 3
csh> echo $ liste [$index] # affichera liste
csh> @ index = $index + 1
csh> echo $ liste [$index] # affichera de

Lors de l'utilisation de telles variables il sera possible de vérifier leur existence en insérant un ? après le dollar ce qui fournira en résultat 1 si elle existe et 0 dans le cas contraire. D'autre part, pour une variable existante, $#variable donne le nombre de mots de la variable. Comme en shell Bourne on peut manipuler les paramètres passés dans la ligne de commande, sous la forme $0, $1, $2, ... mais C-Shell dispose d'une variable argv qui est un tableau des mots passés à l'exécution de la commande.
Exemple :
csh> cat f
#! /bin/csh
mv $argv[1] swap.tmp
mv $argv[2] $argv[1]
mv swap.tmp $argv[2]
csh>
4.8.7. VARIABLES PREDEFINIES PROPRES A C-SHELL
$< représente la prochaine ligne de caractères frappée au clavier avant un RETURN.
Exemple :
echo -n "Votre Nom : "
set nom = ($<)

$$ représente le PID du shell courant ce qui permet de générer des noms de fichiers uniques puisque le PID est par définition unique.

status compte rendu d'exécution de la dernière commande exécutée : vaut 0 (zéro) en cas de succès et différente de 0 autrement.
cwd (Current Working Directory) mémorise le nom du répertoire courant pour le présent shell.

home nom du répertoire de base de l'utilisateur. On rencontre aussi, de façon équivalente le caractère tilde ~.

path liste ordonnée des répertoires à scruter pour retrouver un fichier exécutable.

prompt valeur de la chaîne de prompt.
4.8.8. TEST D'EXPRESSIONS
C-Shell permet de réaliser différents tests sur des variables shell ou des fichiers. Une expression de test sera écrite encadrée par des parenthèses. Un premier type de test concerne les fichiers : ce sont les tests primaires :
- d le fichier est un répertoire
- e le fichier existe
- f le fichier est un véritable fichier, non un répertoire
- o l'utilisateur possède le fichier
- r le fichier est accessible en lecture
- w le fichier est accessible en écriture
- x le fichier est accessible en exécution
- z le fichier est vide (taille = 0)
Exemple :
(-e liste) est vrai si liste existe

Il existe également la possibilité de tester des expressions utilisant des opérateurs binaires pour l'évaluation de variables vis à vis d'autres variables ou de constantes numériques ou chaînes de caractères. L'expression sera vraie si le test est satisfait et fausse sinon. Les opérateurs utilisables sont :
= = égal
! = différent de
< inférieur
> supérieur
< = inférieur ou égal
> = supérieur ou égal
= ~ satisfait l'expression contenant un nom de fichier
! ~ ne satisfait pas l'expression contenant un nom de fichier
Les opérateurs > et < ne fonctionnent que sur des variables numériques.
Les opérateurs = ~ et ! ~ sont utiles pour manipuler des noms de fichiers et ce d'autant plus que les caractères de substitution *, ? et les crochets sont admis.

ATTENTION : ce ne sont pas des expressions régulières !
Exemple :
($nom =~ file.*)
($nom =~ file.[1-6])

Différents types de tests peuvent être combinés ensemble au moyen des opérateurs binaires suivants pour lesquels l'expression sera aussi entre parenthèses.
&& ET
** OU
Exemple :
(($1 = = "") && ($2 != ""))
4.8.9. LES STRUCTURES DE CONTROLE
Les structures de contrôle utilisent le résultat de l'évaluation d'une expression pour déterminer la suite des opérations : soit choisir un traitement parmi 2 ou plusieurs traitements possibles, soit exécuter de façon répétitive une série de commandes.
4.8.9.1. L'INSTRUCTION : if
C'est l'alternative classique SI ALORS SINON, qui peut exister sous trois formes différentes, avec les mots clés : if, then, else, endif.

* if (expression) action

* if (expression) then
action 1
action 2
---
endif

* if (expression) then
actions
---
else
---
endif
Exemple :
if ($1 = = "") then
echo -n "Nom du fichier ?"
set argV = ($<)
endif
if (-e $1) then
cp $1 csh>1.bak
vi $1
pr $1 * lpr
else
echo "fichier inexistant !"
endif
4.8.9.2. L'INSTRUCTION : while
C'est l'instruction TANT QUE qui boucle tant qu'une condition est vraie : elle est encadrée par les mots clés while et end.
Exemple :
while ($1 = = "")
echo -n "Nom du fichier ?"
set argV = ($<)
end
Cette boucle "bouclera" tant que l'on n'aura pas saisi au moins un caractère.
4.8.9.3. L'INSTRUCTION : foreach
foreach permet d'exécuter une série d'actions en utilisant une liste de données, chaque séries d'actions étant exécuter pour chacune des données : c'est la boucle contrôlée, encadrée par foreach et end.
Exemple :
foreach i ($argV)
cp $i $i.bak
end
4.8.9.4. L'INSTRUCTION : switch
switch constitue une solution pour des alternatives multiples en évitant de nombreux if. switch évalue l'expression et exécute les instructions associées à la valeur de cette expression selon la forme suivante :

switch (expression)
case val 1 :
action 1
breaksw
case val 2 :
action 2
breaksw
default :
action -d
endsw
Exemple :
switch ($1)
case "backup" :
cp $2 $2.bak
case "edit" :
vi $2
breaksw
endsw

ATTENTION : l'absence du mot clé breaksw en fin d'un case provoque l'exécution des instructions du case suivant ; breaksw provoque en fait l'arrêt de l'instruction switch. La valeur "default" permet de prévoir un traitement particulier pour les valeurs imprévues.
4.8.9.5. GESTION DES ERREURS
La gestion des erreurs dans un shell script reste toujours à la charge du programmeur : il devra vérifier la validité des données, l'existence de paramètres, tester les données et en déduire les traitements appropriés. Pour faciliter les traitements l'instruction exit permet de forcer la fin d'exécution d'une procédure de commandes avec la possibilité de retourner un compte rendu non nul pour signifier l'erreur ou nul en cas de succès. Sans paramètre exit retourne le status de la dernière commande exécutée.
Exemple :
cp $1 $2 >& /dev/null *
if ($status ! = 0) then
echo "Erreur en cours de copie !"
exit 1 *
endif
Dans cet exemple, en *, il y a renvoi des messages vers le périphérique /dev/null (bit bucket) ce qui permet d'annuler l'affichage. En * il y a retour d'un compte rendu incorrect.
4.9. FICHIERS D'INITIALISATION DU SHELL
Pour faciliter le travail des utilisateurs il est possible de placer des commandes à exécuter systématiquement lors de toute nouvelle session avec un shell et éventuellement lors du lancement du shell dans un fichier qui sera lu et exécuté lors du lancement dudit shell : ce sont les fichiers d'initialisation ou de démarrage (startup file) dont les noms sont les suivants :

Bourne Shell
.profile à la connexion

C Shell
.login et .cshrc à la connexion ("login"),
.cshrc lors de tout autre appel

Korn Shell
.profile et .kshrc à la connexion ("login"),
.kshrc lors de tout autre appel

REMARQUE : Au moment de la déconnexion (logout) C Shell exécute les commandes placées dans le fichier .logout.
ATTENTION : Ces fichiers doivent être placés dans le répertoire de base de l'utilisateur.
5. GESTION DU SYSTEME
5.1. MISE EN PLACE DES PERIPHERIQUES
La première chose à faire est de se placer dans le directory /dev pour initialiser les fichiers spéciaux (c'est à dire les périphériques) disponibles dans la configuration. Sous /dev on rencontre généralement au moins les périphériques suivants :

swap, le périphérique de "swapping" ;
mem, le pseudo-périphérique "mémoire" utilisé par les metteurs au point (adb) ;
kmem, le pseudo-périphérique "mémoire du noyau" utilisé par les commandes nécessitant un accès dynamique aux tables système ;
tty, le pseudo-périphérique "terminal de temps partagé".

Tous les autres périphériques sont déclarés grâce à la commande /etc/mknod, dont la syntaxe générale est la suivante :

/etc/mknod device type major minor
où :
. device est le nom du périphérique (son nom complet sera en fait /etc/device) :
. type est soit b pour un périphérique en mode "bloc" (disques, bandes magnétiques, ...), soit c pour un périphérique en mode caractère (terminaux, imprimantes et aussi disques et bandes -- voir remarque plus bas) ;
. major est le major device number du périphérique
. minor est le minor device number du périphérique ; c'est en fait le rang du périphérique parmi tous ceux de même major.

REMARQUE : Dans le cas des disques (ou des partitions disque), il convient de générer deux fichiers spéciaux, l'un en mode bloc, l'autre en mode caractère. Le nom du fichier en mode caractère est en général celui du mode bloc préfixé par r (comme "raw"). Ainsi

/etc/mknod/dev/msm0b b 2 1
/etc/mknod/dev/rmsm0b c 7 1

crée les deux versions pour le disque de nom msm0. On remarque que les major et minor device numbers sont différents.

Pour une bande magnétique, il faut, en général, créer deux fichiers spéciaux correspondant respectivement à la bande en mode rembobiné après le transfert d'un fichier (par exemple /dev/rmt0), la même bande mais en mode non rembobiné (/dev/nrmt0).

Un certain nombre de noms de périphériques sont habituels sur tous les systèmes UNIX. (mt pour une bande magnétique par exemple). En particulier, l'imprimante porte généralement le nom /dev/lp, et les terminaux interactifs s'appellent /dev/tty00, /dev/tty01, etc... . Le nom des disques dépend de leur type et de leur marque.

RAPPEL : On peut connaître les major et minor device numbers d'un fichier spécial grâce à la commande ls -l.

PROTECTIONS : Après ces déclarations de périphériques, un administrateur système doit établir les droits d'accès de ces fichiers spéciaux (par la commande /bin/chmod). Une imprimante sera en général déclarée en écriture seule, et si elle est "spoolée", en écriture pour le propriétaire (super-utilisateur) uniquement (ses protections seront -w-------).
Il serait très maladroit de laisser un utilisateur normal avoir accès en écriture à un volume disque ; il faut leur donner les protections rw-r--r--. Pour les bandes magnétiques, cela dépend de la présence ou non d'un opérateur permanent. Les protections des terminaux (/dev/tty00, ...) évoluent dynamiquement, et il est inutile de les toucher ; en revanche, il est préférable que le pseudo-périphérique /dev/tty soit accessible en lecture/écriture (rw-rw-rw-) pour tous ; en effet /dev/tty désigne, pour tout utilisateur, le nom générique de son terminal.
5.2. MISE EN PLACE DES SYSTEMES DE FICHIERS
Après avoir déclaré les noms des disques ou des partitions il convient de les initialiser, c'est-à-dire d'établir la structure d'accueil des fichiers d'UNIX : le "super-bloc", la "i-liste", et la "zone libre". C'est le rôle de l'utilitaire /etc/mkfs ("make file system"). Son utilisation est très simple :

/etc/mkfs device taille options
où :
. device est un nom de périphérique déclaré par /etc/mknod (On n'initialise qu'une des versions, bloc ou caractère, de chaque disque et il est préférable de spécifier ici la version caractère car cela va plus vite) ;
. taille est la taille en blocs de la partition, cette taille est au plus égale à celle qui a été définie dans les fichiers de configuration ;
. options dépend du type de disque, de sa marque ou de son contrôleur.

C'est seulement après cette initialisation que les systèmes de fichiers d'UNIX seront opérationnels. Mais ils ne sont pas encore directement accessibles. Pour qu'ils le soient, il faut les monter en ligne. C'est la commande /etc/mount qui le permet :

/etc/mount device directory

La racine du disque (ou de la partition) désigné par device prend alors la place et le nom du directory (qui doit exister dans l'arborescence accessible avant le mount). Ainsi après

/etc/mount/dev/ra1g/usr

tout le contenu de la partition disque /dev/ra1g sera connu comme le directory /usr, et l'utilisateur normal n'aura plus à se soucier de cette correspondance. Ce montage pourra être effectué automatiquement en général au lancement du système.

La commande /etc/mount sans paramètre donne la liste des volumes en ligne. Par contre :

/etc/umount /dev/ra1g

"démonte" un volume précédemment monté.
5.3. LA HIERARCHIE STANDARD
Tout administrateur système doit avoir à l'esprit la structure standard de l'arborescence de fichiers. L'un de ses rôles est de répartir au mieux (c'est-à-dire le plus efficacement compte tenu du matériel disponible) cette hiérarchie sur les différents volumes disques. Un autre devoir est de protéger certains noeuds de cette hiérarchie des accès intempestifs des utilisateurs "normaux". Ces protections sont rarement initialisées correctement dans les versions fournies. On trouvera ci-après quels sont les droits d'accès qui nous paraissent souhaitables pour les utilisateurs "normaux".

/ La racine qui contient en particulier le fichier exécutable du noyau (unix) r-x
/etc Le directory des utilitaires système "dangereux" (nous en avons déjà vu quelques uns) : r-x
/dev Les fichiers spéciaux (périphériques) : r-x
/bin Les commandes UNIX de la section 1 du manuel : r-x
/lib Les bibliothèques d'exécution : r-x
/tmp La zone de fichiers temporaires des utilisateurs ; elle mérite une partition disque pour elle toute seule : rwx
/usr Extension du système ; souvent associée à une partition disque : r-x
/usr/bin D'autres commandes UNIX (du volume 1 du manuel ou des extensions) : r-x
/usr/lib Extensions des librairies d'exécution : r-x
/usr/include Les fichiers d'en-tête pour la programmation C : r-x.. Contient un sous- répertoire sys pour la programmation système.
/usr/man La documentation en ligne (commande man), avec un sous-directory par section du manuel (man0, man1, ..., man8) : r-x
/usr/doc La source des articles du volume 2 du manuel UNIX : r-x
/usr/adm La zone utilisée par les fichiers de comptabilité : r-x
/usr/tmp Une autre zone de fichiers temporaires, moins utilisée que /tmp en général : rwx
/usr/spool La zone de "spooling" : r-x
/usr/spool/lpd La zone des fichiers temporaires de l'imprimante : rwx
/usr/spool/mail La zone des boîtes à lettres utilisées par mail (une par utilisateur) : rwx
/usr/spool/uucp La zone de spool pour les communications d'UNIX à UNIX : rwx
/users La zone des utilisateurs : r-x. Un sous-répertoire par utilisateur (dont les protections sont celles mises en place par son propriétaire). Certains systèmes rattachent directement les répertoires utilisateurs à /usr ; ne pas le faire permet de les isoler dans une partition disque séparée de celles du système, ce qui est sans doute préférable (mais alors le nom de /usr est bien mal choisi pour une partition uniquement réservée au système !).
5.4. MISE EN PLACE DU TEMPS PARTAGE
5.4.1. PRINCIPE DU LANCEMENT DU TEMPS PARTAGE
Lorsque toutes les manipulations précédentes ont été effectuées, il faut lancer le système en Temps Partagé. Un certain nombre de tâches restent cependant à accomplir pour que ce lancement se déroule dans de bonnes conditions. Néanmoins il est utile, avant de les décrire, de posséder quelques notions sur la manière dont UNIX passe en mode multi-utilisateur.

Ce passage est effectué grâce au programme /etc/init. On peut l'activer directement depuis le mode mono-utilisateur par

/etc/init

mais il est sans doute plus simple de signaler une fin de fichier (par CONTROL.D) au shell qui gère le mono-utilisateur : cela aura le même effet. En effet /etc/init était actif depuis longtemps. C'est le processus de descripteur (pid) numéro 1 ; il a été lancé juste après le chargement initial d'UNIX, et c'est lui qui a "forké" et exécuté le shell qui gère la console opérateur. Il s'est mis en attente de son fils (wait), et la fin de celui-ci (le CONTROL-D) le réveille. Que fait-il alors ?

Il commence par faire un fork et exécuter le shell sur le fichier /etc/rc. Ce fichier contient une suite de commandes (rc = run command) à exécuter lors de chaque lancement du temps partagé.

A la fin de ce shell, qu'il a attendu, il lit le fichier /etc/ttys qui contient la liste des terminaux utilisateurs, ceux sur lesquels les usagers vont travailler. Pour chacun des terminaux de la liste, il forke ; chacun de ses fils ouvre le terminal en lecture et écriture (les descripteurs 0 pour l'entrée standard, 1 pour la sortie standard, et 2 pour les erreurs sont affectés à ce moment), et fait un exec du programme /etc/getty. Ce nouveau programme affiche le message

login :

sur le terminal, lit le nom de l'utilisateur en essayant d'adapter la vitesse de la ligne, et exécute le programme /bin/login avec le nom en argument. Si le nom et le mot de passe qui suit sont corrects, login positionne le répertoire courant de l'utilisateur et invoque (par exec) le shell propre à l'utilisateur ; ces informations sont trouvés dans le fichier /etc/passwd.
Lorsque un shell utilisateur se termine, le processus init est prévenu (il était en attente par wait d'un tel événement) ; il relance un processus de login sur le terminal correspondant en invoquant à nouveau getty. On voit donc que le lancement du temps partagé, dans son élégance et sa simplicité, fait appel à tous les mécanismes de gestion de processus d'UNIX. Mais on voit aussi qu'un certain nombre de fichiers et de tables doivent être correctement initialisées pour que tout ceci se déroule correctement ; c'est ce qui est décrit dans ce qui suit.
5.4.2. MISE EN PLACE DES TERMINAUX
Les terminaux accessibles en temps partagé doivent être placés dans le fichier /etc/ttys. A chaque terminal correspond une ligne ; si le premier caractère de cette ligne est le caractère 0, le terminal est inaccessible en temps partagé ; si c'est 1, il est accessible, et un processus getty devra être exécuté sur lui. Le deuxième caractère de la ligne est un paramètre qui est passé tel quel à getty. Sa signification dépend du système hôte ; il sert en général à établir la vitesse de la ligne asynchrone, ou le point de départ du balayage des vitesses possibles, lorsque l'on laisse le soin à getty de faire l'adaptation. Le reste de la ligne est le nom du terminal, débarrassé du préfixe /dev/.

Il convient aussi d'initialiser une table donnant pour chaque nom de terminal son type afin de permettre l'affectation de la variable d'environnement shell TERM.

REMARQUE : Le détail du fichier /etc/ttys peut varier suivant les implémentations.
5.4.3. MISE EN PLACE DES ACTIONS TEMPORELLES REPETITIVES
UNIX permet de spécifier l'exécution d'actions à certains instants précis. Pour cela il faut lancer le programme /etc/cron, qui exploite le fichier /usr/lib/crontab.

Ce fichier est constitué de lignes comportant chacune 6 champs ; ces champs sont séparés par des espaces ou des "tabulations". Les 5 premiers spécifient respectivement les minutes, les heures, le jour du mois, le mois, et le jour de la semaine. Le sixième champ contient une commande qui doit être exécutée à l'instant spécifié.
On peut, par ce procédé, lancer des actions "domestiques" à des moments précis (nettoyage des gros fichiers disques inutiles, compactage des fichiers de comptabilité, ...). On peut aussi lancer l'utilitaire /usr/lib/atrun (toutes les 5 ou 10 minutes par exemple), qui est utilisé par la commande at (cette commande permet à tout utilisateur de repousser l'exécution d'une commande à une heure et une date donnée).
5.4.4. LA PROCEDURE DE "START-UP" /etc/rc
La plupart des actions précédentes, ainsi que certaines actions qui dépendent des divers sites, peuvent être lancées dans le fichier /etc/rc. Ce fichier contient une suite de commandes shell qui sont exécutées par /etc/init à chaque lancement du temps partagé. /etc/rc contient en général au moins :

* L'initialisation de la date courante.
* La vérification de la cohérence des disques car le temps partagé ne doit être lancé que si ces disques sont dans un état correct.
* Le lancement de /etc/update (qui forcera la mise à jour effective des disques), et éventuellement ceux de /etc/cron (toujours) et de /etc/accton (comptabilité). On peut décider de se passer de la comptabilité soit par volonté délibérée, soit parce que l'on estime que cela consomme trop de place disque.
* Le nettoyage des répertoires et fichiers temporaires, et la destruction des verrous de blocage de certains périphériques partagés (comme une imprimante spoolée par exemple).
5.4.5. MISE EN PLACE DES UTILISATEURS
Le rôle de l'administrateur du système est aussi de déclarer les nouveaux utilisateurs : il doit y en avoir au moins un au lancement du temps partagé : le "super-utilisateur". Les autres pourront être alloués au fur et à mesure. la mise en place d'un utilisateur comporte deux phases :

* La déclaration du nom de l'utilisateur et de son groupe dans les fichiers /etc/passwd et /etc/group ;

* La création du répertoire initial de l'utilisateur ("home directory") et de son "shell" initial.

Si les anciennes versions d'UNIX ne fournissaient aucun utilitaire pour effectuer ces tâches ; aujourd'hui des procédures de commandes shell automatisent ce travail.

Le fichier /etc/passwd contient une ligne par utilisateur, dont les champs sont séparés par un ":" . Ces champs sont les suivants et dans l'ordre :
* Le nom de l'utilisateur (à entrer au "login") qui doit être unique.
* Le mot de passe (encodé) ; l'utilisateur s'en donnera éventuellement un lui-même (par la commande passwd).
* Le numéro d'utilisateur correspondant à ce nom ; il doit être lui aussi unique.
* Le numéro du groupe d'utilisateur, tel qu'on le retrouvera dans le fichier /etc/group.
* Un champ commentaire : On trouve parfois ici des informations comme le nom complet (civil) de l'utilisateur.
* Le nom absolu du répertoire initial de l'utilisateur.
* Le nom du fichier exécutable qui contient son "shell" initial (son langage de commande) ; si ce champ est vide (mais les deux-points ":" qui le précèdent doivent être présents même dans ce cas), /bin/sh est pris par défaut.
Exemple :
csh> cat /etc/passwd
root:GEtvBhJDKseOs:0:1:System PRIVILEGED Account:/:/bin/csh
uucp:Nologin:4:1:UNIX-to-UNIX COPY
gm:O7WW/xUew.lXo:268:79:Georges:/usr/users/profs/gm:/bin/csh
pl:r.02t7TUsxM:269:79:Pierre:/usr/users/profs/pl:/bin/csh
dat:nd8oolNuKSjng:271:84:Daniel:/usr/users/apii4/dat:/bin/csh
gdn:ZhZcAvIFKoCqM:274:84:Gedeon:/usr/users/apii4/gdn:/bin/csh
agr:e0GyyYyc2nrjQ:277:84:Agnes:/usr/users/apii4/agr:/bin/csh
csh>

Le fichier /etc/group contient pour chaque groupe la liste des utilisateurs autorisés du groupe: un même individu peut appartenir à plusieurs groupes, une commande (newgrp) permettant de se déplacer de l'un à l'autre. La plupart des systèmes UNIX utilisent assez peu les groupes. Voici cependant un exemple de fichier /etc/group correspondant au fichier /etc/passwd précédant :

csh> cat /etc/group
system:*:0:root
daemon:*:1:daemon
users:*:15:
profs:*:79:pl,gm
apii4:*:84:dat,gdn,agr
csh>
Les différents champs d'une ligne sont dans l'ordre : nom du groupe, mot de passe (rarement utilisé), numéro du groupe, nom des utilisateurs du groupe.

Quant à la mise en place des répertoires utilisateurs, elle est très simple : il suffit de les créer (par mkdir) ; il ne faut pas oublier aussi de leur donner l'utilisateur et son groupe comme nouveaux propriétaires, sinon ils continueraient à appartenir au "super-utilisateur" ; au moyen des commandes chown et chgrp.
5.4.6. ARRET DU TEMPS PARTAGE
Pour arrêter le Temps Partagé, il suffit d'envoyer à /etc/init le signal SIGINT, comme nous l'avons déjà fait remarquer. Il est préférable de le faire en mode "super-utilisateur" à la console, par :

kill -1 1

Le système repasse en mode "mono-utilisateur".

Avant de couper l'alimentation du système, il est impératif de forcer les entrées-sorties en attente (les buffers sont encore en mémoire) par la commande sync (attendre quelques secondes après avoir lancé cette commande). Bien souvent une procédure de commandes de nom shutdown réalise cette opération.
6. UNE APPROCHE SYSTEME
6.1. LES FONCTIONS SYSTEME SOUS UNIX
Le système d'exploitation UNIX offre aux développeurs de logiciels un ensemble de fonctions puissantes pour l'élaboration d'applications clés en main. On désigne par "fonctions sys¬tème" les appels à des sous-programmes du noyau UNIX. De nombre limité (environ 80), elles existent sur toutes les machines et respectent généralement un formalisme standard. Cette stan¬dardisation assure un degré élevé de portabilité des programmes sources des applications puisque le noyau UNIX se retrouve sur des machines très diverses (en taille, en puissance et en prix).
6.2. PROCESSUS : CREATION, GESTION ET PLANIFICATION
Unix permet de partitionner une application en "processus" qui se déroulent en premier plan ou en arrière plan.

* La fonction système "exec()" : Un processus peut exécuter plusieurs programmes succes¬sivement grâce à la fonction exec(). Sur appel d'exec le noyau UNIX charge le nouveau programme en mémoire et reprend l'exécution du processus. Le nouveau programme s'exécute en héritant de l'environnement laissé par le programme précédent (numéro d'utilisateur, de groupe, fichiers ouverts,...).

* La fonction système "fork()" : L'unique façon de créer un nouveau processus consiste à utiliser la fonction système fork(). Le nouveau processus créé, appelé processus fils, exécute une copie du programme exécuté par le processus père. Le processus fils peut alors utiliser exec pour débuter l'exécution d'un nouveau programme. Tout processus peut ainsi générer une hiérarchie de processus. Lors de sa création un processus dispose d'un environnement constitué d'un ensemble de variables shell exportées par la commande "export", cet héritage se faisant au moment du "fork" tandis que "exec" le conserve intact.

* Notion de numéro d'utilisateur : Un processus s'exécute normalement avec le numéro de l'utilisateur qui le lance, ce numéro permettant de contrôler les droits d'accès aux fichiers et les accès aux fonctions systèmes. Un processus hérite de ce numéro du processus père et par là même ses droits et privilèges. Toutefois, il existe des cas où un programme doit pouvoir accéder à un fichier, par exemple, même si l'utilisateur ne peut pas y accéder directement. Unix permet, pour résoudre ce problème, d'exécuter un processus avec un numéro d'utilisateur différent de celui du processus père : c'est alors le numéro d'utilisateur effectif du propriétaire du fichier contenant le programme. Un programme qui doit être exécuté de la sorte aura son fichier associé affecté de la propriété "s" au lieu de "x" au niveau des protections du propriétaire. Il existe la même possibilité au niveau du groupe.
6.3. PARTAGE ET VERROUILLAGE DE FICHIER
Unix permet l'accès simultané à un fichier par plusieurs processus différents. Tant qu'il s'agit de consultation il n'y a pas de problème alors qu'en écriture il faut être prudent. Pour régler correctement ce problème Unix permet le verrouillage de fichier : dès lors, l'accès à une zone dé¬terminée du fichier (voire tout le fichier) est réservé en exclusivité au programme à l'origine du verrouillage tant qu'il ne le déverrouille pas. Les autres programmes désirant accéder à la zone verrouillée seront mis en attente; il existe en fait deux types de verrouillage :

* * le verrouillage en lecture : pour le blocage en lecture et écriture des autres programmes,
* * le verrouillage en écriture : pour le blocage des autres en écriture seulement (les lectures étant autorisées).

D'autre part Unix permet le verrouillage obligatoire, les droits d'accès étant vérifiés lors de chaque entrée-sortie, et le verrouillage partiel où les vérifications sont moins poussées (donc plus performantes mais moins sécurisées). On notera également que Unix détecte les situations de blocage (deadlock) au niveau des verrouillages de fichiers : le programme à l'origine du blocage reçoit un code d'erreur lui signalant de bien vouloir déverrouiller les fichiers qu'il occupait.

* PLANIFICATION DE PROCESSUS : Sous UNIX la planification ou ordonnancement (scheduling) des processus est basée sur la priorité des processus mais avec également la notion de partage de temps. Le noyau exécute toujours le processus éligible de plus haute priorité. Il est à noter toutefois que la priorité d'un processus varie en fonction de son comportement : un proces¬sus réalisant beaucoup d'entrées-sorties sera avantagé par rapport à un processus utilisant intensi¬vement l'unité centrale; le principe général consiste à avantager les processus interactifs du type shell, par exemple, de façon à offrir des temps de réponse acceptables pour l'utilisateur. Un utilisateur ne peut pas augmenter sa priorité mais il peut la diminuer au moyen de la commande "nice". A chaque ré-ordonnancement le noyau examine la file des processus éligibles ou actifs et décide quel processus va être exécuté. Outre l'état actif, un processus peut être dans l'un des états suivants :

* Actif ou éligible : le processus peut faire l'objet d'une exécution prochaine selon la déci¬sion de l'ordonnanceur,

* Endormi : le processus est en attente d'un évènement tel que la fin d'une entrée-sortie ou un signal,

* Invalide : prêt à être créé par fork(), les tables sont prêtes,

* Créé : le processus est en cours de création, état transitoire,

* Zombie : le processus vient d'exécuter un exit() mais certaines données qui lui sont propres peuvent être encore utilisées par Unix,

* Arrêt : état particulier utilisé lors de la mise au point de programme avec la primitive trace().
6.4. GESTION DE LA MEMOIRE
Sous Unix tout processus actif est résident en mémoire centrale (code et données). Tant qu'il n'y a pas trop de processus à gérer ils peuvent tous tenir en mémoire, faciliter le passage de l'un à l'autre et offrir des temps de réaction très faibles. Bien évidemment, en fonction des sessions en cours et des programmes utilisés, il arrive très vite que tous les processus ne tiennent pas en mémoire. Dans ce cas Unix ne va conserver en mémoire centrale que les processus actifs tandis que les autres seront sauvegardés sur disque. En fonction de la demande et des activations de processus il y aura des échanges entre mémoire centrale et disque gérés par la partie "gestion de la mémoire" de Unix. Cette gestion peut être basée sur deux méthodes différentes suivant le type d'unité centrale et selon qu'elle nécessite la présence de la totalité du programme ou qu'elle se contente de portion de programme seulement en mémoire centrale. Ces deux méthodes sont la permutation ou "va et vient" (swapping), méthode traditionnelle d'Unix et la mémoire virtuelle mise en oeuvre la première fois à BERKELEY et qui constitue la méthode standard pour System V.

* PERMUTATION DE PROCESSUS : Cette technique concerne les systèmes qui né¬cessitent la totalité du programme en mémoire centrale. Le processus "va" et "vient" entre la mémoire centrale et une zone réservée du disque appelée "zone de swapping". Malgré la perte de temps oc¬casionnée par ces transferts la permutation permet d'exécuter plus de processus que ne peut en contenir la mémoire centrale. Pour optimiser les échanges une zone spéciale du disque est réser¬vée pour stocker les images mémoires des processus "swappés"; cette image mémoire est conservée dans la zone jusqu'à la destruction du processus.

* LE BIT DE PERMANENCE (sticky bit) : Sous Unix, quelques programmes utilitaires sont utilisés très fréquemment; il serait dommage de devoir les recharger en zone de permutation lors de chaque utilisation. Pour éviter cela il est possible de les forcer à rester en permanence en zone de swap de façon à pouvoir être relancés très rapidement : cela est réalisé par indication du bit de permanence (sticky bit) indiqué par le caractère "t", au niveau des protections du fichier. Ce type de propriété sera réservé surtout au shell, à l'éditeur de textes et au compilateur C.

* LA MEMOIRE VIRTUELLE : Certaines machines disposent de dispositifs matériels per¬mettant de ne disposer en mémoire que d'une fraction du programme à exécuter. L'unité cen¬trale exé¬cute la portion de programme située en mémoire jusqu'à détecter, par le matériel, qu'il lui manque une portion du programme, le système d'exploitation doit alors charger une autre portion de programme en mémoire de façon à pouvoir poursuivre son exécution. Cette technique consistant à fractionner les pro¬grammes et à charger les différentes fractions en fonction du temps et de la demande s'appelle la mémoire virtuelle. On notera que que cette technique fait appel à du matériel et du logiciel; la plupart des microprocesseurs modernes 32 bits offrent la possibilité de gérer la mémoire virtuelle : MOTOROLA 68010-68020-68040, INTEL 386-486, NATIONAL 32032,... ainsi, bien évidem¬ment, que les ordinateurs de milieu ou haut de gamme (VAX DIGITAL par exemple). La mémoire virtuelle offre deux avantages :

* possibilité d'exécuter de très gros programmes dont la taille dépasse celle de la mémoire centrale,
* possibilité de conserver plus de processus en mémoire centrale.

* LES BIBLIOTHEQUES PARTAGEES (shared library) : les dernières versions d'Unix offrent une amélioration en ce qui concerne les bibliothèques : les bibliothèques partagées. Tout programme fait fréquemment appel à des routines de bibliothèque (routines prêtes à l'emploi fournies par le constructeur). Par défaut, sur un système classique, chaque programme exécutable contient une copie des routines utilisées ce qui prend beaucoup de place sur disque et en mémoire centrale lorsque plusieurs programmes contenant les mêmes appels s'exécutent simul¬tanément. Avec une bibliothèque partagée Unix n'incorpore plus de copie de la routine de bibliothèque dans le fichier exécutable mais seulement un pointeur sur cette routine. A l'exécution, ces pointeurs sont renseignés par Unix pour désigner les adresses réelles des routines placées en mémoire (de façon unique). Un exemplaire de ces routines est donc partagé par tous les programmes appelant cette routine (nécessité de ré-entrance pour chacune de ces routines); il en découle trois avantages :

* économie de mémoire centrale,
* économie d'espace disque,
* mise à jour transparente des bibliothèques sans nécessité de nouvelle édition de liens.
6.5. COMMUNICATION INTER-PROCESSUS
Dans la mesure où Unix permet la création d'une hiérarchie de processus il s'avère très utile de pouvoir communiquer des informations entre ces processus. Dans ce but, Unix dispose de divers outils : les tubes, les tubes nommés, la fonction message IPC, la mémoire partagée et les sémaphores.

* Le TUBE (pipe) : c'est un canal de communication uni-directionnel (à sens unique) entre deux processus issus d'un même processus père : l'émetteur et le récepteur. Ce tube est "vu" comme un fichier ordi¬naire. Pour une communication bidirectionnelle il faut utiliser deux tubes, un pour chaque sens de communication. Le noyau gère les tubes en mode FIFO : l'émetteur place des informations par "write" alors que le récepteur les lit par "read". L'asynchronisme des écritures-lectures ne gêne en rien le fonctionnement d'autant que les situations "tube plein" ou "tube vide" sont détectées.

* Le TUBE NOMME (named pipe) : c'est un type de tube plus puissant qui solutionne la restriction des tubes ordinaires pour lesquels les processus communicants doivent être issus du même père. Un tube ordinaire est en fait une structure de données temporaire associée à un pro¬cessus et détruite en fin de processus; un tube nommé, par contre, est assimilable à un périphérique : il appa¬raît en tant que fichier spécial sous "/dev" et tout processus peut y accéder.

* La FONCTION MESSAGE IPC (Inter Process Communication) : c'est une alterna¬tive aux tubes mais elle est réservée à la communication de messages brefs avec ici la possibilité de plusieurs émetteurs et plusieurs récepteurs pouvant accéder en lecture-écriture à la file (FIFO) des messages.

* MEMOIRE PARTAGEE et SEMAPHORES : le partage de mémoire permet à plusieurs processus d'accéder à une même zone mémoire. Les processus accèdent à cette mémoire partagée à l'aide de fonctions systèmes et ce de façon immédiate ce qui donne des performances maximales mais nécessite une discipline d'accès très rigoureuse. Les sémaphores, structures de données classiques et formalisées par DIJKSTRA, offrent un outil simple et efficace pour gérer la mémoire partagée et, plus généralement, résoudre les problèmes de partage de ressources.
6.6. DEVELOPPEMENT D'UNE APPLICATION
La structure simple et modulaire d'Unix offre un terrain de choix pour les développeurs de logiciels. Par assemblage d'éléments de base il est possible de construire des applications dédiées relativement facilement avec un degré de portabilité maximal.

Personnalisation des procédures de démarrage : En standard, Unix exécute la séquence des quatre utilitaires suivants lors du démarrage de la machine : init, getty, login et shell. Le noyau utilise init pour initialiser le système, puis getty pour afficher le message d'invite sur les terminaux et attendre la frappe d'un nom d'utilisateur qui sera traité par login (avec saisie et contrôle du mot de passe) puis enfin lancement du shell. A la déconnexion le shell prend fin et c'est init qui relance getty sur le terminal associé.

* "init" bascule le système en différents modes de fonctionnement dont notamment le mode mono-utilisateur (toute première phase du démarrage, réservée à la maintenance) et le mode multi-utilisateurs (fonctionnement normal). Pour ce faire, "init" utilise la table /etc/inittab et la procédure de commandes /etc/rc qui réalise la vérification du système de fichiers, la destruc¬tion de fichiers temporaires, la mise en route de la comptabilité système (accounting). En mode multi-utilisateur "init" crée un processus fils par terminal, lequel exécute "getty". "getty" affiche le message d'entrée, attend la frappe du nom d'utilisateur et "exec"écute login qui contrôle le mot de passe au moyen du fichier /etc/passwd contenant la description de tous les utilisateurs : nom abrégé, mot de passe crypté, numéro d'utilisateur, numéro de groupe, nom en clair de l'utilisateur, nom du répertoire à la connexion, nom du programme à exécuter à la connexion (généralement le shell). Si la phase de connexion est correcte "login" fixe numéros d'utilisateur et de groupe, place l'utilisateur dans le répertoire de connexion et exécute le shell. Avant d'afficher le prompt principal, shell exécute, s'ils existent, deux fichiers de "profil" : "/etc/profile", procédure de com¬mandes communes à tous les utilisateurs et ".profile" dans le répertoire principal propre à l'utilisateur et où il peut placer les commandes qu'il désire faire exécuter en début de toute ses¬sion.

* APPLICATION INDEPENDANTE DU TERMINAL : Dans l'esprit d'Unix toute ap¬plication doit assurer un degré de portabilité maximal y compris vis à vis des terminaux (qui sont souvent bien différents dans les fonctionnalités offertes et la façon d'en tirer parti). L'utilitaire "stty" permet de configurer le type de terminal de façon à pouvoir développer un logiciel indé¬pendamment de son type et de sa marque au moyen des routines de la bibliothèque "curses" et du fichier "terminfo" (respectivement "termcap" sur les anciennes versions d'Unix). En premier lieu, stty informe le noyau des caractéristiques physiques de la ligne de communication (vitesse, nombre de bits, parité,...). Ensuite toutes les fonctions faisant usage de l'écran (effacement, posi¬tionnement, attributs vidéo,...) sont standardisées dans la mesure où la "base de données" /etc/terminfo contient la description précise des fonctions existantes et des codes de contrôle associés pour les terminaux les plus courants (cette base peut être enrichie par l'utilisateur en fonction des besoins). Pour chaque utilisateur il suffit d'indiquer dans la variable shell TERM le nom du terminal de façon à retrouver la description des fonctions associées dans terminfo et en déduire les codes nécessaires. Il est également possible d'utiliser uniquement les services de la bi¬bliothèque "curses" qui travaille avec des fonctions vidéo normalisées indépendantes du terminal et gérées de façon transparente à l'utilisateur : ces routines s'adaptent en fonction de TERM et de terminfo.

7. ANNEXE
Liste des principales commandes UNIX

adb utilitaire de mise au point ("Debugger")
ar gestionnaire d'archives et de bibliothèques
as assembleur
at exécute des commandes à une date ultérieure
awk langage de recherche d'expression et d'édition
basename supprime préfixe et suffixe d'un nom de fichier
bc calculatrice en précision arbitraire
bs filtre de détection des caractères BACKSPACE
cal affiche le calendrier
calendar aide-mémoire
cat filtre de concaténation et d'affichage
cb enjolive les programmes écrits en C
cc compilateur C
chmod change les protections d'un fichier
cmp compare deux fichiers
col filtre les "sauts de ligne"
comm garde ou rejette les lignes communes à deux textes
cp copie de fichiers
crypt cryptage/décryptage de fichier
date affiche ou modifie la date-heure système
dc calculatrice de bureau
dd convertit et copie un fichier
deroff supprime les commande nroff, troff, tbl et eqn
df donne la place libre sur disque
diff donne les différences entre fichiers
diff3 compare des fichiers
du donne l'occupation disque par des fichiers
echo affiche ses arguments
ed éditeur de textes (ligne)
eq,neqn,checkeq traitement de textes mathématiques
expr évalue ses arguments comme un expression Shell
f77 compilateur Fortran 77
factor,primes factorise un nombre, génère des nombres premiers
file détermine le type d'un fichier
find trouve des fichiers dans une arborescence
graph tracé de graphiques
grep,egrep,fgrep recherche des expressions dans des fichiers
join opérateur relationnel de base de données
kill termine l'exécution d'un processus
ld éditeur de liens
learn enseignement assisté d'Unix par Unix
lex générateur d'analyseur lexical
lint vérificateur de syntaxe de programmes en C
ln génération de lien sur fichier
login début/fin de session
look trouve des lignes dans une liste triée
lpr gère la file d'attente d'impression
ls liste le contenu d'un répertoire
m4 macro-processeur
mail émission-réception de courrier
make reconstructeur de programme
man guide utilisateur
mesg permet/inhibe la réception de messages
mkdir création de répertoire
mv déplace/renomme un fichier
nice,nohup exécute une commande avec une priorité basse
nm donne la table des symboles d'un module objet
nroff traitement de texte (non interactif)
od "dump" à l'écran d'un fichier
passwd change le mot de passe
plot filtre graphique
pr prépare un fichier pour listage
prep prépare un texte pour traitement statistique
ps état des processus
ptx création d'un index permuté
pwd donne le répertoire courant
quot résumé de l'occupation disque
ranlib convertit des archives en bibliothèques
ratfor dialecte fortran structuré
refer,looklib trouve et insère des références bibliographiques
rev renverse l'ordre des lignes d'un fichier
rm détruit un fichier (ou un lien)
rmdir détruit un répertoire
sccs gestionnaire de versions de fichiers
sed filtre de transformation (édition) de textes
sh langage de commande standard
size taille d'un fichier objet
sleep suspend momentanément l'exécution d'un processus
sort trie ou fusionne des fichiers
spell correcteur orthographique
spline interpolation de courbes régulières
split partitionne un fichier
struct structure un programme Fortran
stty définit les paramètres d'un terminal
sum somme et compte les blocs d'un fichier
sync met à jour le "super-bloc"
tabs définit les tabulations d'un terminal
tail donne la fin d'un fichier
tar archivage sur bande magnétique
tbl prépare le traitement de tables
tc simule une photocomposeuse sur terminal TEXTRONIX
tee filtre en Té
test valeur logique d'une expression
time mesure le temps d'exécution d'une commande
tk filtre d'écran pour terminal TEXTRONIX 4014
touch met à jour la date de dernière modif. d'un fichier
tpc commandes du dérouleur de bande magnétique
tr filtre de transcription de caractères
troff traitement et impression de textes
true,false renvoie la valeur logique associée
tsort tri topologique
tty donne le nom du terminal de travail
uniq filtre les lignes répétées d'un fichier
units conversion d'unités classiques
wc compte lignes, mots, caractères d'un fichier
who liste les utilisateurs en cours de session
write envoie un message à un autre utilisateur
yacc générateur d'analyseur syntaxique

القلب النابض · 11-16-2007, 07:09 PM

بس طمنيني اخذتي الايميل ولا لا شو ردي او ردي على الاهداءات يلا بسرعة

القلب النابض · 11-16-2007, 07:12 PM

انا بستناكي بسرعة ضيفيني يلا

القلب النابض · 11-16-2007, 07:16 PM

اها شو صار معك هيني كتبنه شو اخذتيه

الذين يشاهدون محتوى الموضوع الآن : 1 ( الأعضاء 0 والزوار 1)

الإهداءات
إضافة إهداء