Classic Shell Scripting - Arnold Robbins [201]
Besides process-specific data, /proc may contain other useful files:
$ ls /proc | egrep -v '^[0-9]+$' | fmt
List all but process directories
apm bus cmdline cpuinfo devices dma driver execdomains fb
filesystems fs ide interrupts iomem ioports irq isapnp kcore kmsg
ksyms loadavg locks mdstat meminfo misc modules mounts mtrr net
partitions pci scsi self slabinfo speakup stat swaps sys sysvipc
tty uptime version
Here's the start of just one of them:
$ head -n 5 /proc/meminfo
Show first 5 lines of memory information
total: used: free: shared: buffers: cached:
Mem: 129228800 116523008 12705792 0 2084864 59027456
Swap: 2146787328 28037120 2118750208
MemTotal: 126200 kB
MemFree: 12408 kB
Having process data available as files is convenient and makes the data easily available to programs written in any programming language, even those that lack a system-call interface. For example, a shell script could collect hardware details of CPU, memory, and storage devices from the /proc/*info files on all of the machines in your environment that have such files, producing reports somewhat like those from the fancy sysinfo [6] command. The lack of standardization of the contents of these files, however, makes the task of producing uniform reports more difficult than it ought to be.
* * *
[6] Available at http://www.magnicomp.com/sysinfo/.
Summary
In this chapter, we have shown how to create, list, control, schedule, and delete processes, how to send signals to them, and how to trace their system calls. Because processes run in private address spaces, they cannot interfere with one another, and no special effort needs to be made to write programs that can run at the same time.
Processes can catch all but two of several dozen signals, and either ignore them or respond to them with any desired action. The two uncatchable signals, KILL and STOP, ensure that even badly misbehaving processes can be killed or suspended. Programs that need to perform cleanup actions, such as saving active files, resetting terminal modes, or removing locks, generally catch common signals; otherwise, most uncaught signals cause process termination. The trap command makes it easy to add simple signal handling to shell scripts.
Finally, we examined several different mechanisms for delaying or controlling process execution. Of these, sleep is the most useful for shell scripting, although the others all have their uses.
Chapter 14. Shell Portability Issues and Extensions
The shell language as defined by POSIX is considerably larger than the original V7 Bourne shell. However, it is considerably smaller than the languages implemented by ksh93 and bash, the two most commonly used extended versions of the Bourne shell.
It is likely that if you'll be doing heavy-duty scripting that takes advantage of shell-language extensions, you'll be using one or the other or both of these two shells. Thus, it's worthwhile to be familiar with features that the shells have in common, as well as their differences.
Over time, bash has acquired many of the extensions in ksh93, but not all of them. Thus, there is considerable functional overlap, but there are also many differences. This chapter outlines areas where bash and ksh93 differ, as well as where they have common extensions above and beyond the features of the POSIX shell.
* * *
Tip
Many of the features described here are available only in recent versions of ksh93. Some commercial Unix systems have older versions of ksh93, particularly as a program called dtksh (the desktop Korn shell, /usr/dt/bin/dtksh), which won't have the newer features. Your best bet is to download the source for the current ksh93 and build it from scratch. For more information, see Section 14.4.
* * *
Gotchas
Here is a "laundry list" of things to watch out for:
Saving shell state
Example 14-1