LINUX & SHELL PROGRAMMING 3CS4

Transcription

1 POORNIMA INSTITUTE OF ENGINEERING & TECHNOLOGY DEPARTMENT OF COMPUTER ENGINEERING LINUX & SHELL PROGRAMMING 3CS4 Prepared & Compiled By: Mr. Amitesh Kumar Assistant Professor Placement Coordinator Coordinator Open Source Technology CS,PIET Specialization: Linux, Compiler, Computer Graphics, Real Time System, Distributed System, IT Laws, PHP Mr. Krutibash Nayak Assistant Professor CS,PIET Area: Linux

2 UNIT-3 Chapter 3.1: Introduction to X-window system X windows is the program that draws windows on the screen under most GUI based versions of UNIX. It is important to note that the language that X windows speaks is completey different from that of Microsoft Windows or that which Mac OS X uses. Any X window system consists of 2 distinct parts - the X server and 1 or more X clients. It is important to realise the distinction between the server and the client... The server controls the display directly, andis responsible for all input/output via the keyboard, mouse or display. The clients, on the other hand, do not access the screen directly - they communicate with the server, which handles all input and output. It is the clients which do the "real" computing work - running applications or whatever. The clients communicate with the server, causing the server to open one or more windows to handle input and output for that client. The X windows server runs on the machine to which the monitor is connected to. The clients may also run on this machine, communicating directly with the server. On most workstations, this is the normal situation. However, X is a networked window system, and it is possible for the client to run on a remote machine, communicating with the server via some form of network. It is possible to connect to one of the schools servers and lauch graphical applications from one of the UNIX servers. This does require that an X windows server, be installed on the machine from which you are connecting from. This is automatically running if you are running a GUI UNIX system. You can also install an X windows server on top of Microsoft windows, so that you can open up windows locally that are talking to the server at UMBC. Like I said earlier, this does require installing some software on the client side, and time permitting we may talk about this later in the course. Reference-

3 Chapter 3.2: x-window as client/ server system To allow programs to be run on one machine and display on another, X was designed as a network protocol--a predefined set of requests and replies--between two processes. One of these processes is an application program called a client, and the other, the server, controls the display hardware, keyboard, and pointer. The user sits at the machine running the server. At first, this use of the word server may seem a little odd, since file and print servers normally are remote machines, but the usage is consistent. The local display is accessible to other systems across the network, and for those systems the X server does act like other types of server. The X server acts as an intermediary between user programs (called clients or applications) and the resources of the local system such as the keyboard and screen. It contains all device-specific code, and insulates applications from differences among display hardware. The server (without extensions) performs the following tasks: Allows access to the display by multiple clients. The server may deny access from clients running on certain machines. Interprets network messages from clients and acts on them. These messages are known as requests. Some requests command the server to move windows and do two-dimensional drawing, while others ask the server for information. Protocol requests are generated by client calls to Xlib, either directly or through Xt and other function libraries. Passes user input to clients by sending network messages known as events, which represent key or button presses, pointer motion, and so forth. Events are generated asynchronously, and events from different devices may be intermingled. The server must pass the appropriate events to each client. The client must be prepared to handle any event it has selected at any time. Maintains complex data structures, including windows and fonts, so that the server can perform its tasks efficiently. Clients refer to these abstractions by ID numbers. Server-maintained abstractions reduce the amount of data that has to be maintained by each client and the amount of data that has to be transferred over the network. In X, the term display is often used as a synonym for server, as is the combined term display server. However, the terms display and screen are not synonymous. A screen is the actual hardware on which the graphics are drawn. A server may control more than one screen. For example, a single server might control both a color screen and a monochrome screen, allowing users to debug an application on both types of screen without leaving their seat. The user programs displaying on screens managed by a server are called its clients. There may be several clients connected to a single server. Clients may run on the same machine as the server if that machine supports multitasking, or clients may run on other machines in the network. In either case, the X Protocol is used by the client to send requests to draw graphics or to query the server for information, and is used by the server to send user input and replies to information requests back to the client.all communication between client and server uses the X Protocol. The communication path between a client and the server is called a connection. It is common for a user to have programs running on several different hosts in the network, all invoked from and displaying their windows on a single screen (see Figure 3.2). Clients running remotely can be started from the remote machine or from the local machine using the network utilities rlogin or rsh.

4 Figure 3-2. Applications can run on any system across the network This use of the network is known as distributed processing. It allows graphic output for powerful systems that don't have their own built-in graphics facilities. Distributed processing can also help solve the problem of unbalanced system loads. When one host machine is overloaded, users running clients on that machine can arrange for some of their clients to run on other hosts. Eventually there may be automatic load-balancing applications, but currently such remote execution is performed manually. It is not unusual to see users in the X environment having several xload load monitor applications running on various systems throughout the network but displaying on their screen, so that they can see the balance of loads throughout the network. Before leaving the subject of servers and clients, we should mention PC servers and X terminals. Software is available that allows various types of PCs to operate as X servers.[5] X terminals are special-purpose devices designed to run just an X server, and to connect to remote systems over a local area network. PC servers and X terminals are the least expensive way to provide an X screen for a user. Since most PCs use single-tasking operating systems, they can't run any clients at the same time as the server. Therefore, they too require a network adapter to connect to another system where clients are run. X terminals and PC servers both demonstrate the strength of X's client-server model. Even though PCs and X terminals aren't able to do multitasking on their own, they give the user the effect of multitasking workstations, because they can interact simultaneously with several clients running on remote multitasking systems. X clients The main means of communication with X is by using the keyboard and the mouse. The mouse moves a pointer round the screen. Pressing the mouse buttons activates various functions depending on where the mouse is located. To send your input from the keyboard to any particular client, you must position your mouse pointer over that client.

5 A number of the more popular programs A display usually consists of a terminal screen, keyboard and mouse. Frequently the display and the workstation are the same. This is not always the case as a display can have multiple screens. A display is controlled by a special program known as an X server. There is only one X server per display. Clients are user programs such as text editors, clocks and calculators. A client receives all of its input and output through requests to the X server. The server handles all of the input and output to the display. It creates windows, produces text and graphics on the screen, etc. Clients cannot access the display directly, they must go through the server. Referencehttp://menehune.opt.wfu.edu/Kokua/Irix_6.5.21_doc_cd/usr/share/Insight/library/SGI_bookshelves/SGI_Developer/boo ks/xlib_winsys/sgi_html/ch01.html

6 Chapter 3.2: concept of window manager Because multiple applications can be running simultaneously, rules must exist for arbitrating conflicting demands for input. For example, does keyboard input automatically go to whichever window the pointer is in, or must the user explicitly select a window? How does the user move or resize windows? Unlike most window systems, X itself makes no rules about this kind of thing. Instead, there is a special client called the window manager that manages the positions and sizes of the main windows of applications on a server's display. In Motif, this client is mwm. The window manager is just another client, but by convention it is given special responsibility to mediate competing demands for the physical resources of a display, including screen space, color resources, and the keyboard. The window manager allows the user to move windows around on the screen, resize them, and usually start new applications. The window manager also defines much of the visible behavior of the window system, such as whether windows are allowed to overlap or are forced to tile (side by side), and whether the keyboard focus simply follows the pointer from one window to the next window, or whether the user must click a pointer button in a window to change the keyboard focus. Applications are required to give the window manager certain information to help it mediate competing demands for screen space or other resources. For example, an application specifies its preferred size and size increments. These are known as window manager hints because the window manager is not required to honor them. The Toolkit provides an easy way for applications to set window manager hints. The conventions for interaction with the window manager and with other clients have been standardized by the X Consortium in a manual called the Inter-Client Communication Conventions Manual(ICCCM for short). The ICCCM defines basic policy intentionally omitted from X itself, such as the rules for transferring selections of data between applications, for transferring keyboard focus, for installing colormaps, and so on. As long as applications and window managers follow the conventions set out in the ICCCM, applications created with different toolkits will be able to coexist and work together on the same server. Toolkit applications should be immune to the effects of changes from earlier conventions because the conventions are implemented by code hidden in a standard widget called Shell. However, you should be aware that some older applications and window managers do not play by the current rules. The window manager is a rather special X client. It is a tool which allows you to move, resize, iconify and kill other windows. It provides a title bar for every window, and may make several pop-up menus available. A number of window managers are available at Strathclyde - which one you use is a matter of personal preference. The window managers available include: twm The Tab Window Manager. This is the most commonly used window manager at Strathclyde, and is probably the best one to use initially. vtwm A Virtual twm - this is an extended version of twm which allows for a "virtual desktop". This means that the apparent size of the X servers "screen" can be several times larger than the physical dimensions of the workstation screen. The workstation can be regarded as being a "window" onto the virtual desktop, and this window may be moved over the virtual desktop by using the mouse or the cursor keys. It's a useful facility to have available, but isn't really recommended for the beginner. tvtwm Another virtual twm, and a rival to vtwm. Again, not for the novice. olwm Open Look Window Manager - provides an interface of a similar style to that available under Sun's OpenWindows environment. mwm Motif Window Manager. Provides a Motif-style interface. Reference- ks/xlib_winsys/sgi_html/ch01.html

7 Chapter 3.3: xinitrc file xinit(1) is the program that actually starts X; it is called by startx(1) Its configuration file, however, determines which programs (including and especially the window manager) are run when X starts up. xinit first checks your home directory for a.xinitrc file. If the file is found, it gets run; otherwise, /var/x11r6/lib/xinit/xinitrc (the systemwide default) is used. Example: To customize your X startup, copy the default /var/x11r6/lib/xinit/xinitrc to ~/.xinitrc and edit it, replacing those program lines with whatever you like. Reference-

8 Chapter 3.4: customize X work environment and applications Customizing the X session (classic method) On a system where "/etc/x11/xsession.options" contains a line "allow-user-xsession" without preceding "#" characters, any user who defines "~/.xsession" or "~/.Xsession" is able to customize the action of "/etc/x11/xsession" by completely overriding the system code. The last command in the "~/.xsession" file should use form of "exec some-window/session-manager" to start your favorite X window/session managers. Customizing the X session (new method) Here are new methods to customize the X session without completely overriding the system code as above. The display manager gdm3 can select a specific session and set it as the argument of "/etc/x11/xsession". The "~/.xsessionrc" file is executed as a part of start up process. (desktop independent) The "~/.gnomerc" file is executed as a part of start up process. (GNOME desktop only) The GUI program based session management software may use the "~/.gnome2/session" file etc. Connecting a remote X client via SSH The use of "ssh -X" enables a secure connection from a local X server to a remote application server. Set "X11Forwarding" entries to "yes" in "/etc/ssh/sshd_config" of the remote host, if you want to avoid "-X" command-line option. Start the X server on the local host. Open an xterm in the local host. Run ssh(1) to establish a connection with the remote site as the following. localhost $ ssh -q -X loginname@remotehost.domain Password: Run an X application command, e.g. "gimp", on the remote site as the following. remotehost $ gimp & This method can display the output from a remote X client as if it were locally connected through a local UNIX domain socket. Secure X terminal via the Internet Secure X terminal via the Internet, which displays remotely run entire X desktop environment, can easily achieved by using specialized package such asldm. Your local machine becomes a secure thin client to the remote application server connected via SSH.

9 xinit You run X with the startx command. This in turn is a frontend for xinit, the program responsible for starting the X server and running various X clients that you specify. xinit (via startx) executes the shell script.xinitrc in your home directory. This script merely contains commands that you wish to run when starting X, such as xterm, xclock, and so on. If you don't have a.xinitrc file, the system default /usr/lib/x11/xinit/xinitrcis used instead. TIP: When using KDE, you will often have only one single command in your.xinitrc file: startkde. This is a shell script shipped with KDE that starts all necessary services. Your distributor might add other stuff to.xinitrc, though. Here, we'll present a sample.xinitrc file for a bare-bones X system without any desktop environment and explain what it does. You could use this as your own, very bare-bones.xinitrc or copy the system default xinitrc as a starting point: 1 #!/bin/sh 2 # Sample.xinitrc shell script 3 4 # Start xterms 5 xterm -geometry 80x fg black -bg white & 6 xterm -geometry fn 7x13bold -fg darkslategray -bg white & 7 xterm -geometry fn 7x13bold -fg black -bg white & 8 9 # Other useful X clients 10 oclock -geometry 70x & 11 xload -geometry 85x & 12 xbiff -geometry & 13 xsetroot -solid darkslateblue & # Start the window manager 16 exec fvwm2 TIP: A number of programs are started here; obviously, this will work only if you have installed them. If you go with the default installation of your distribution, chances are that either the desktop environment KDE or GNOME will be installed and these older programs will not be available. They should be on the distribution media, though, waiting to be installed. While you cannot have more than one window manager running at the same time, you can have as many of them installed as you like. This should be quite straightforward, even if you're not familiar with X. The first two lines simply identify the shell script. Lines 5-7 start up three xterm clients (recall that xterm is a terminal-emulator client). Other clients are started on lines 10-13, and on line 16 the window manager,fvwm, is started. Let's look at this in more detail. On line 5, we see that xterm is started with several options, -geometry, -fg, and - bg. Most X clients support these standard options, among others. The -geometry option allows you to specify the size and position of the window on the display. The geometry specification has the format: xsizexysize+xoffset+yoffset In this case, the option -geometry 80x puts the window at the location (10,100) on the screen (where (0,0) is the top-left corner), making it 80 characters wide by 40 characters high. Note that xterm measures the size of the window in characters, not pixels. The actual size of the window in pixels is determined by the font that is used. The -fg and -bg arguments allow you to specify the foreground (text) and background colors for the xterm window, respectively. The colors used here are a rather boring black and white, but this should work on color and monochrome displays alike. Under X, colors are usually specified by name, although you can provide your own RGB values if you prefer. The list of color names (and corresponding RGB values) is given in

10 the file /usr/lib/x11/rgb.txt. Running xcolors will display these colors, along with their names. Line 6 runs another xterm, although the arguments are slightly different: xterm -geometry fn 7x13bold -fg darkslategray -bg white & First of all, the geometry specification is just Without size parameters, xterm will use the default, which is usually 80x25. Also, we see that the xoffset is prefixed with a -, instead of a +. This places the window 20 pixels from the right edge of the screen. Likewise, a geometry specification of (as used on line 7) means to place the window 20 pixels from the right edge of the screen and 30 pixels from the bottom. In this way, the placement of windows is less dependent on the particular resolution you're using. The -fn option on lines 6 and 7 specifies that the font used by xterm should be 7x13bold. Using the command xlsfonts displays a complete list of fonts on your system; the X client xfontsel allows you to select fonts interactively more about fonts later. On line 10 we start an oclock client, which is a simple analog clock. Line 11 starts xload, which displays a graph of the system load average(number of running processes) that changes with time. Line 12 starts xbiff, which just lets you know when mail is waiting to be read. Finally, on line 13 we do away with the bland gray X background and replace it with a flashy darkslateblue. You'll notice that each X client started on lines 6-13 is executed in the background (the ampersand on the end of each line forces this). If you forget to put each client in the background, xinit executes the first xterm, waits for it to exit (usually after you log out), executes the next xterm, and so on. The ampersands cause each client to start up concurrently. What about line 16? Here, we start fvwm (Version 2), a window manager used on many Linux systems. As mentioned before, the window manager is responsible for decorating the windows, allowing you to place them with the mouse, and so forth. However, it is started with the command: exec fvwm2 This causes the fvwm2 process to replace the xinit process. This way, once you kill fvwm, the X server shuts down. This is equivalent to, but more succinct than, using the Ctrl-Alt-Backspace key combination. Whether you are returned to the command line after the X server has shut down or are presented with a new graphical login depends on your system configuration. If you have experimented with fvwm, you'll notice that pressing the first mouse button while the cursor is on the background causes a menu to pop up. Selecting the Quit fvwm option from this menu causes fvwm to exit. In general, you should put an ampersand after each X client started from.xinitrc, and exec the window manager at the end of the file. Of course, there are other ways of doing this, but many users employ this technique. The fvwm2 window manager was the default window manager on most Linux systems for a very long time. It is still around, but has mostly been superseded by either the very advanced kwin window manager shipped with KDE or one of the more modern freestanding window managers, such as blackbox or sawfish. Reference-

11 Chapter 3.5:customizing the fvwm window manager FVWM, the F Virtual Windows Manager, is a window manager for computers running the X Window System. fvwm is a virtual desktop window manager used by many Linux users. It is based partially on the code for twm, a classic window manager included with the MIT X11 distribution. However, fvwm has been trimmed down and requires about half the memory used by twm--welcome news for Linux systems with 8 MB or less of physical RAM. fvwm provides many features not available in other window managers. The default FVWM screen is very basic -- just a simple blue desktop. Clicking anywhere with the left mouse button brings up a menu with a couple of built-in options, including xterm. You can also move around the virtual desktop by moving mouse cursor off the edge of the screen (you'll find there are nine 'screens' in a 3x3 grid). Among the features offered by fvwm are: A simple virtual desktop, which provides a pager (an overall birds-eye view of the desktop) and automatic desktop scrolling when the pointer reaches the screen boundary. A keyboard equivalent for almost every mouse-based feature; this is helpful when using X on laptops without a mouse or trackball, or for people with RSI or other physical problems making use of the mouse difficult. Support for color icons using the XPM libraries. A programming interface for extensions, allowing you to add new features to fvwm. One extension included in the fvwm distribution is a button box that stays put on your root window. You can bind commands to each button, allowing you to point and click to start applications. Fully configurable desktop menus, which appear when you press the mouse buttons. A Motif-like 3D look and feel for window frames. In fact, fvwm includes options to make it compatible with the Motif window manager (mwm). Basic FVWM customization FVWM uses the file ~/.fvwm/.fvwm2rc to override its default configuration. Create this file with the following contents: Mouse 0 1 A Iconify Mouse 0 2 A Maximize Style "*" NoIcon EdgeResistance Style "FvwmTaskBar" NoTitle,BorderWidth 0,HandleWidth 0,Sticky AddToFunc InitFunction I Module FvwmTaskBar AddToFunc RestartFunction I Module FvwmTaskBar

12 In this file, the first two lines create a maximize and minimize button for all windows. The next line switches off the icons for minimised applications. Put a hash mark at the start of the line if you want to see what the icons look like; personally, I think they clutter up the screen too much. The EdgeResistance setting slows down the changing from one screen to another. A value of 1000 means 1 second; i.e. you must hold the mouse cursor at the edge of the screen for one second before the screen will switch. If you want only one screen then put this value very high (e.g ). Finally, the last three lines create a task bar at the bottom of the screen. In order to see your changes you must restart FVWM. Left-click on the main screen, then select Restart FVWM. Once the screen has refreshed itself you should see a task bar at the bottom of the screen, complete with a Start button. It has no functionality at the moment, but we can add some by adding the following to the file: AddToMenu "Internet" "Internet" Title + "Firefox%mini-x.xpm%" Exec firefox & + "Thunderbird%mini-x.xpm%" Exec thunderbird & AddToMenu "Main" "Main" Title + "xterm%mini-x.xpm%" Exec xterm & + "Internet%mini-x2.xpm%" Popup Internet + "Restart%mini-turn.xpm%" Restart + "Quit%mini-exclam.xpm%" Quit *FvwmTaskBarStartMenu Main This code includes a Main menu containing xterm, a sub-menu for Internet applications, the restart function, and an Exit button. If you now restart FVWM then you will find that the Start button has this new popup menu associated with it. You can build up your own set of menus to run the applications that you need. In addition to the Start menu we can also customize the default Builtin Menu that's accessible by clicking the left mouse anywhere on the main screen. We can also add some functionality to the right mouse button, which does nothing at the moment. Add the following code to ~/.fvwm/.fvwm2rc: Mouse 1 R A Menu Main Mouse 3 R A Menu Internet A left mouse click will now invoke the Main function instead of the Builtin Menu, whilst the right one will show

13 the Internet menu. In this way you can build up a Windows Manager that has all of the applications that you require. Interacting with the shell So for we have only looked at static menus -- that is, those that are hard-coded into the file. However, you can also build dynamic menus based on shell commands. To do this use the Piperead command: AddToMenu ListFiles ListFiles Title Piperead `for f in ~/*.html; do echo "+ $f Exec gedit $f"; done` This simple example builds a menu listing all of the HTML files in your home directory, and allows you to access them using gedit. Using FVWM within an organization We've seen how FVWM allows you to have all your key applications at your fingertips. Once you've done that for one system, you can easily deploy your changes across an organization. You can set up.fvwm2rc files according to a person's function with the organization -- a developer doesn't need to see the same menus as his manager. The manager doesn't need to see the same things as her directors. The directors just need to see the things that will keep them happy. This can be addressed in a few ways. The most obvious way would be to copy the customized.fvwm2rc file into each person's.fvwm directory according to what they need to see. This works well, but if you make any changes to the main.fvwm2rc files, you've then got the headache of remembering who has which file, and then rolling it out to them. A better way is to create a link from the user's.fvwm directory to a central file: ln -s /etc/fvwm/.fvwm2rc_user.fvwm2rc However, the best approach is to make use of Piperead, the Linux groups command, and the FVWM Read function. The Read command lets you include a second config file. Each user's.fvwm2rc needs to contain only the following line: Piperead "echo Read /etc/fvwm/.fvwm2rc_$(groups awk '{print $1}')" The.fvwm2rc file will look up a user's group and load the appropriate file. This, of course, assumes that you have created the directory /etc/fvwm and that it contains a set of files called.fvwm2rc_users,.fvwm2rc_root and so on -- one for each group. Reference-