The Xfce Desktop Environment started as a CDE clone using the XForms toolkit (hence the XF and ce in XFce). CDE was the Common Desktop Environment developed by HP, Sun, Digital and other big box players for their top notch workstations. Definitely cool. Definitely not for dummies.
CDE had a neat filemanager called dtfile, but this was not open source, so Xfce used a variation of Rasca's Xtree called Xftree as a filemanager.
Xffm history began when Xfce was running on the Gimp Toolkit (GTK) by extending Xftree's functionality with the glob search engine (now fgr), the samba network browser Xfsamba, the differences viewer Xfdiff and a set of dtfile icons, among other things.
Then came the migration to GTK-2. For this Xftree was rewritten as Xffm, retaining all the previous functionality and adding more. The dtfile icon set was replaced by Francois' Rodent icon theme. To distinguish Xffm as a part of Xfce, the first release was tagged 4.0.
Then came 4.2 and the love/hate story started. Those new to Xfce could not understand why Xffm had such a steep learning curve, while those familiar to Xftree expected the nerdy behaviour they had become used to.
Anyways, it was decided that Xfce would no longer distribute a filemanager: this way users could choose the new Thunar filemanager (which, as an independent software, would no longer follow the Xfce version numbers).
Cut loose of the xfce umbilical, xffm was adopted by foo-projects, hosted at Stockholm University. The xffm.org domain was assigned and the web page at http://xffm.org/ was put on the line. The next release of Xffm would no longer follow the current Xfce version numbers, but for consistency would not be rolled back.
Xffm-4.5.0, which featured a new user interface (although the old nerdy treeview was still available) was released on 2006-05-24. This remained stable until 2010, when 4.6.0 was releasedtypeset@protect @@footnote SF@gobble@opt Work on 4.6.0 began in early 2006, when Intel gave me a multicore laptop to start doing multicore software (thanks, Intel).. 4.5.0 had 13500 downloads according to sourceforge data, and the main user group was in Germany, followed by the United States, Russia, China and Poland.
4.6.0 was to ve a new thread-safe, thread-based design (code named Rodent, for Francois' icon theme) and required a rewrite of the Xffm code. To accomplish this, several goals were set forth:
The first release of Rodent Alpha, (aka xffm-4.6.0) was in November 2010, at a conference at the University of Sonora. The second release was stable enough to be tagged beta software. Rodent Beta (aka xffm-4.6.2) released in April 2011. The third release, Rodent Beta release 2 (aka xffm-4.6.4) was released in the last days of May. The first non beta release is Rodent Gamma.
Rodent Gamma is faster than Beta, has over 95% translation for the main non-English languages in the world, and boasts new features that make this filemanager capable of handling heavy loads. Visit the sourceforge sitetypeset@protect @@footnote SF@gobble@opt http://sourceforge.net/projects/xffm/ for download details.
The Rodent Filemanager source file is extremely simple, consisting of less than 500 lines of code. Yet this expands to more than 40,000 lines of code on a binary tree design modelled on Hegel's comprehensive philosophical frameworktypeset@protect @@footnote SF@gobble@opt Hegel's account of reality revolutionized European philosophy. In particular, he developed the concept that mind or spirit manifested itself in a set of contradictions and oppositions that ultimately integrated and united, without eliminating either pole or reducing one to the other (http://en.wikipedia.org/wiki/Georg_Wilhelm_Friedrich_Hegel). . If you are not familiar with this manner of thought, fret not, the overall method should become clear as you read on.
On the highest level, Rodent Filemanager is the synthesis of:
The Rodent filemanager physical layout is composed of the icon and lp-terminal areas.
The first may have icons or empty space. The popup menu is context sensitive, allowing for two basic menus. The icon area is meant to be as simple as possible, in the manner of the concept developed by the guys at Palo Alto. Simple uncluttered graphics (see figure 1). As such, toolbar and file menu functionality is fully handled by popup menus which are only visible when summoned. Display real estate is too valuable to waste on alternate methods to do the same thing.
The lp-terminal area is also simple: it is not a video terminal emulator, but a line printer terminal emulator (hence the lp-terminal nomenclature), such as those used as consoles in several robust computing systems of yore (see figure 2). The lp-terminal area will execute all command in background, and has two types of autocompletion, historytypeset@protect @@footnote SF@gobble@opt summoned with the CTRL+TAB key combination and bashtypeset@protect @@footnote SF@gobble@opt summoned with the TAB key, and two text areas, one for input and one for output. Thus it is handy to issue commands like ``make'' and follow the output which is streamed to stdout/stderrtypeset@protect @@footnote SF@gobble@opt Output to stderr will be colored red, while that to stdout will be black., but is not adequate to edit a file, for example. There are better graphic tools for the latter.
Rodent filemanager geometric layout can be summarized as follows:
To build from source, do a #./configure'' followed by a ``make'' and ``sudo make install''. Don't forget to do a ``sudo ldconfig'' after your first installation from source. The configure script has many options that allow you to customize your installation of Rodent Filemanager.
[Default ``yes''] This includes the Rodent icon theme in the installation. The Rodent icon theme is the xfce4-icontheme updated to XDG naming specification and enriched with icons from the freedesktop.org ``Roedor'' icon theme. Selecting this option to ``no'' will also select -with-gtk-icons to ``yes'' (seccion 3.1.2).
[Default ``no''] This option will make Rodent Filemanager default to the system gtk icontheme. This icontheme is commonly set by desktop environments such as Gnome or KDE. This option can be selected or unselected at any time by the user with the settings dialog.
[Default ``yes''] This enables the ``properties'' item of the popup menu.
[Default ``yes''] This enables the ``find'' item of the popup menu.
[Default ``yes''] This enables the mimetype resolver plugin. This plugin is needed for icon resolution and program association in the popup menu.
[Default ``yes''] This enables the icon theme plugin. It required the mime plugin to work. Without the icons plugin, Rodent will use only a limited set of the gtk default icons. Disable this option if you want maximum speed and do not care about a full bodied icon set.
[Default ``yes''] This enables the history autocompletion in the dialog combos. Rodent Filemanager will ``remember'' user's choices and form a dropdown combo to select from depending on what has been typed. The contents of this dropdown are shown at all times with a automatic tooltip. In Rodent < 4.7.0, autocompletion would work with this history. From Rodent 4.7.0 and latter, autocompletion is set to bash mode. History items may be selected from the combo popdown. See figure 3.
[Default ``yes''] This enables the settings plugin. With this setting the user may customize the behavior of Rodent Filemanager. All instances of Rodent Filemanager will listen to configuration changes and apply them on the fly. If this plugin is not installed, Rodent Filemanager will not be configurable by the user. Disable this option and set the appropriate environment variables to set a fixed configuration for Rodent Filemanager.
[Default ``yes''] This enables the ``Mount point'' plugin. This plugin detects partitions and allows the user to mount or unmount CDroms or usbdevices or any other item which is mountable. Items found in /etc/fstab and /etc/mtab are portrayed as icons. See section 4.4.
[Default ``yes''] This enables the system processes plugin. This plugin allows the user to monitor system processes and to send arbitrary signals to these processes. See section 4.5
[Default ``yes''] This enables the dot desktop plugin. This plugin is necessary to be aware of mimetype-application associations and to use dot desktop files as program launchers. See section 4.6.
Items are activated with a single click. This is a configurable option.
The default action for drag and drop is to move the items. This is a configurable option. Holding down the CONTROL key while releasing the mouse button will do a copy. Holding down the SHIFT key will do a move. Holding down both the CONTROL and SHIFT keys will do a symlink. Symlinks constructed in this manner will be done so in a relative file path, not an absolute path.
The Rodent pasteboard operates on the localhost. Windows from remote hosts will have a different pasteboard. This change of behavior from previous X-pasteboard in version <= 4.5.0 is required for compatibility with the threaded multicore nature of Rodent.
fgr is the command line search tool used by Rodent and Rodent-fgr. The command line tool may be used directly from a terminal or the lp-terminal input line. The GNU grep command (or similar BSD tool) must be installed for this application to search for file content. There is no need for the find command to be present.
To have Rodent associate an application to a particular file mimetype, use the ``Open with'' element of the popup menu. The selected application will be the default application until the ``Open with'' element is used again. Other applications associated to the particular mimetype will always appear in the popup menu as individual items.
To set the default application for a particular mimetype, do CONTROL-click on the associated menu item (see figure 4). This changes from 4.7.2 where the application selected in the open with dialog was set up as the default application. Now the application selected in the open with will appear in the item's popup menu (until the cache is regenerated) where it can be selected as a default application as well. Default selected applications will be conserved on cache regenerations.
Items may be selected by clicking with the mouse button while holding down the SHIFT or CONTROL key in the conventional manner. SHIFT will select all items between previously selected items, while CONTROL will select if unselected and unselect if previously selected. All other items will retain their selection status. A rubber band box may also be used for selecting multiple items by holding down the mouse button while moving the mouse.
Keyboard input is processed by the lpterminal. Bash autocompletion is available with the TAB key. History autocompletion is available with CONTROL+TAB key.
To access the command history of the lp-terminal you may use the following commands in the lp-terminal:
? Show help about options ! Show History !n Reference Number (Command Line) n. !STRING Complete Match STRING. !?STRING Anywhere STRING. STRING<CTRL+TAB> Completion mode: Command Line. STRING<TAB> Completion mode: bash. !! Clear History (Current) !!! Clear History (Disk)
All lp-terminal commands will show stdout output in black and stderr output in red in the lp-terminal area. For each command (executed in background) a ``exec'' button appears next to the lp-terminal input area and which is linked to rodent-ps. This allows the user to view the process in question and send arbitrary signals for control. If the ps-module plugin is not installed, then a dialog which allows for user termination of the process will appear.
For each folder, a small icon indicating the prevailing mimetype for the files contained in that folder will appear in the upper right hand corner.
For image, pdf, postscript and text files, placing the mouse on top of the icon will trigger a popup window which will show the content of the file in question in a size big enough to actually see what the file is about. This option is especially useful for sifting through files with non-descriptive names without having to open each one. To make this as fast as possible, move the mouse over several files before halting over each one. This will allow Rodent to do the preview work in the background while the user is examining the output produced. To disable the preview and to show a normal tip with file information, press mouse button 2 (the middle button) while moving the mouse on top of the icon. To disable previews for all files in the current directory, toggle the ``show previews'' value in the popup menu. To disable all popup windows for all directories, use the settings dialog configuration tool.
Rodent provides a graphic front end to GNU touch program. This can be launched from the popup menu on a single or multiple selected items.
Rodent also includes a front end to GNU diff command, allowing a side by side comparison of files and patch generation in a variety of formats.
Rodent includes the updated Rodent icon theme which may be installed as the default icon theme for desktop environments such as Gnome or Kde.
Rodent includes translations for 126 languagestypeset@protect @@footnote SF@gobble@opt af, am, an, ar, as, ast, az, be, be@latin, bg, bn, br, bs, ca, ca@valencia, crh, cs, csb, cy, da, de, dv, dz, el, en_CA, en_GB, eo, es, et, eu, fa, fi, fr, fur, fy, ga, gl, gn, gu, gv, ha, he, hi, hne, hr, hsb, hu, hy, ia, id, ig, io, is, it, ja, ka, kg, kk, km, kn, ko, ku, ky, la, lb, li, lt, lv, mai, mg, mi, mk, ml, mn, mr, ms, nb, nds, ne, nl, nn, no, nso, oc, or, pa, pl, ps, pt, pt_BR, pt_PT, ro, ru, rw, se, si, sk, sl, sq, sr, sr@ije, sr@ijekavian, sr@ijekavianlatin, sr@latin, sv, ta, te, tg, th, tk, tr, ug, uk, ur, uz, uz@cyrillic, vi, wa, xh, yi, yo, zh, zh_CN, zh_HK, zh_TW.Big5, zh_TW, zu..
The rodent filemanager has different modes depending on how it is summoned from the command line.
This is the same iconview filemanager as summoned by the rodent executable, but if the startup path is not specified on the command line, the program will default to the rodent root level (figure 9), where icons for the root file system, the user's home directory, and all installed root level plugins are displayed. Furthermore, the application will execute in background.
This is the fixed window on the root background. Desktop background color can be customized by the user, as well as the use of an image file in many different formats, such as jpg, gif, png. Only the icons which fit on the desktop will be displayed. As such, if the number of icons exceeds the fit capacity, some will not be shown. In figure we show the Rodent desktop. In this figure the selected icon theme is the default GTK desktop icons. If the icons plugin happens to be removed from the system, Rodent will fall back to a limited set of GTK stock icons, which may be a subset of the GTK desktop icons if the program is being executed within a desktop environment.
Other characteristics that can be defined for the deskview, shown in figure 8, are:
This executable will directly open the Mount Points plugin. From this plugin, mount points and devices defined in the system /etc/fstab file may be mounted or unmounted. Partitions detected in /proc/partitions will also be available for mount or unmount operations. Furthermore, any mount point detected in /etc/mtab will also be available (figure 9). Icons for mounted volumes are enhanced with a green ball emblem, while unmounted items have a red ball emblem.
When a usb device is inserted, the detected partition will automatically appear in this window, allowing the user to mount and unmount the device at will. If the fstab configuration do not allow users to mount or unmount a specified volume, Rodent will try to issue the command specified by the user with the sudo helper application (section 7.2.5).
When this module is installed, an additional menu element is available in the Rodent icon popup menu which allows the user to mount volumes listed in /etc/fstab or unmount volumes listed in /etc/mtab (figure 10). The menu element will appear automatically if the action is applicable.
The rodent-ps executable opens the System Processes plugin (figure 11). This plugin shows running processes in the system. The default is to show the parent-child relationship between processes in a file system manner. This behavior may be changed by means of the pop up menu in empty space (figure 12). The user may also select to view all sytem processes or only focus on own processes. Processes may be suspended, continued, terminated or killed by means of the icon area popup menu (figure 13). The complete set of signals that can be issued to any process are:
Furthermore, the window which appears when the mouse hovers over the icon shows further information about the process (figure 14). Whenever the stop button is pressed for any Rodent controlled background process, rodent-ps will open at the exact level where the process is running, allowing total control over the process. This is a feature available in versions greater than or equal to 4.6.6. The default behavior in previous versions was to send a TERM signal, and if that failed, a KILL signal. The old behavior for the stop button is now used only if the ps-module is not installed (see ./configure -help for build configuration options).
The Rodent backend helper program, GNU ps is a contribution of
The Rodent-dotdesktop executable summons the dotdesktop module in navigation mode.
This module will create a categories window (figure 15), where each category will contain dot desktop files (launchers) for installed programs which have classified themselves accordingly.
The categories considered by rodent-dotdesktop are all the categories present in installed dot desktop files.
If any of the categories is empty, then the category will not appear. Each launcher icon can execute the referred program in two ways. The simplest is a simple double click (or <return> on a selected icon). The second method applies for drag and drop. For instance, if the user desires to open several files with a dot desktop application, all that has to be done is select the icons to be opened and drag them and drop them on the launcher icon. Since each launcher is simply a file, the launcher itself may be dragged and dropped on any filesystem folder or even the desktop folder. The behavior of the icon will be the same as within the Rodent-dotdestop view with one exception. When dot desktop files are located outside the rodent-dotdesktop view, they are also recognized as text files so the user can view and modify them.
Furthermore, if the dotdesktop module is installed, the empty space popup menu in Rodent will have the extra submenu Applications with a small mouse icon. In this submenu the launchers may be executed directlytypeset@protect @@footnote SF@gobble@opt Categories Core, Qt, KDE, GTK and GNOME are not present in the popup submenu because these categories are too large. Nonetheless, they are always available in the icon navigation mode. as from a GNOME, KDE or XFCE panel menu (see figure 16). The advantage of having this Applications popup where you need it and when you need it is less stressful to the impatient mind.
The popup has the following fixed categories, following the Gnome layout, although this layout may vary in the future if such modifications are deemed convenient.
Non root plugins add extra functionality to Rodent filemanager, and are only loaded on a need to use basis. Furthermore, the operating system does not reserve memory for modules (in contrast to dynamic load libraries) until load time. This helps keep Rodent small. These plugins may be used by other applications. The API and programmer's guide will be available with Rodent Delta.
This plugin provides the properties dialog which is summoned from the popup menu. It is a front end for chown, chmod and chgrp. If the user is not authorized to apply such commands, then it will try to use sudo, allowing the privileged user to issue such commands without leaving the filemanager environment. See figure 17.
This plugin provides access to the Rodent icon theme and the xdg spec named icons. If this module is not installed, Rodent will fall back to a very basic GTK subset of icons. Use this if you do not care about looks but want a filemanager that is fast as a hurricane. The icons plugin requires the mime plugin (section ) to load.
This plugin is in charge of resolving mimetypes for files and associating applications. Eliminating this plugin will impede the icons plugin from loading. If the dotdesktop plugin is installed, this plugin will be enriched by the associations between mimetypes and applications harvested from installed applications.
The plugin uses both the freedesktop mimetype definition as well as those defined by the libmagic library (used by the file application). Other mimetypes defined by googlecode and /etc/mime.types is also used. The configuration file which installs the default applications on a system wide basis is located at rodent/libs/rfm/mime/mime-module.xml and is installed to $PREFIX/share/rfm-Gamma/.
Applications with are associated by the user by means of the ``Open with'' dialog are saved in a simple text format at $HOME/.config/rfm-Gamma/user-applications.
This module creates an extended combo box with historic and bash completion. If the module is not installed, dialogs which Rodent presents with input boxes will consist of simple entry boxes without historic or bash completion.
This module takes care of building and presenting the graphic front end to the fgr command. The module is used by Rodent filemanager as well as the standalone front end rodent-fgr. See figure 24.
This plugin takes care of managing the shared memory and comunicating configuration changes between applications. It also handles the settings dialog window.
The popup menu is context sensitive. There is a popup menu over void space and another over an icon space.
Figure 18 shows what the popup menu over void space looks like. The increase and decrease menu items are only shown in the rodent-desk version because the iconview has a dedicated scale widget to provide this functionality.
Figure 19 shows what the popup menu over void space looks like.
The popup menu is context sensitive. The contents of the menu depend on what is located beneath the pointer when the menu is summoned. If nothing is beneath the pointer, the general popup appears. The layout of the icon specific popup is as follows.
All configurable options are set through environment variables. The settings dialog allows for easy setting of these variables, as well as direct in line text setting and reviewing.
The settings dialog has the following options.
See figure 20.
See figure 21.
See figure 22. Some of these options may not be available under BSD.
See figure 23
Several commands and auxiliary applications or artwork are distributed with the Rodent Filemanager package. These are the internal helper applications, and may be used independently or by other applications.
rodent-fgr is a graphic frontend for fgr. See figure 24.
Graphic front end to the GNU diff command. See figure 25.
This is the application used to customize the icons used by Rodent. All icons in the Rodent filemanager are customizable. In order to customize, drag and drop the icons from the treeview on the right to the treeview on the left. When you press the save button, a custom will be saved in your configuration directory and the full path will be listed in a dialog after a successful write.
If by any chance you want to make your custom icon layout the system wide default, move it to $PREFIX/rfm-Gamma/icons.mime.xml. The default configuration file in the tarball distribution is located at rodent/libs/icons/mime.
If you change icon themes, since the Rodent icon theme follows the xdg naming specification, the respective icons should be found in the new icon theme. If the new icon theme does not have an icon for a standard named icon, then Rodent falls back to the original Rodent icon theme.
The rodent-mime application is shown in figure 26. This application may be executed either from the lp-terminal command line or by pressing the ``icons'' button in the ``Personal preferences'' dialog.
Rodent-root is the application which sets the background image for the desktop. It will set the default X root window to use the image, as well as the background for the rodent-desk application. When the background is changed by means of the ``Personal preferences'' dialog, this is the application which is called. It may also be called by selecting the popup menu over any supported image type. Once rodent-root selects a background image, this choice becomes the user's default background.
The Rodent icon theme is a native Xfce development. It was created by Francois Le Clainche and has been enriched by Lonerocker's contributions at freedesktop.org. The icon theme is now distributed and maintained by the Rodent filemanager project. The name of the Rodent filemanager is derived from this icon theme, although you can choose any desktop icon theme you may fancy.
Reinvent the wheel? No thanks. Bug free code exists for copying, moving, linking, touching and many other fundamental file operations in GNU and BSD versions. Reusability is one of the strengths of free software which should not be ignored.
In the initial years, one of the defining points of Xfce in the early years was to keep applications small. So if time proven versions for the same operations is already available and installed, why duplicate code?
What follows is a description of external programs developed by world class programmers which comprise the core set of operations used by the Rodent filemanager. Currently the full power of these commands is not harnessed by Rodent, but functionality will be extended in future releases.
`cp' copies files (or, optionally, directories). The copy is completely independent of the original. You can either copy one file to another, or copy arbitrarily many files to a destination directory.
cp [OPTION]... [-T] SOURCE DEST cp [OPTION]... SOURCE... DIRECTORY cp [OPTION]... -t DIRECTORY SOURCE...
By default, `cp' does not copy directories. However, the `-R', `-a', and `-r' options cause `cp' to copy recursively by descending into source directories and copying files to corresponding destination directories.
When copying from a symbolic link, `cp' normally follows the link only when not copying recursively. This default can be overridden with the `-archive' (`-a'), `-d', `-dereference' (`-L'), `-no-dereference' (`-P'), and `-H' options. If more than one of these options is specified, the last one silently overrides the others.
When copying to a symbolic link, `cp' follows the link only when it refers to an existing regular file. However, when copying to a dangling symbolic link, `cp' refuses by default, and fails with a diagnostic, since the operation is inherently dangerous. This behavior is contrary to historical practice and to POSIX. Set `POSIXLY_CORRECT' to make `cp' attempt to create the target of a dangling destination symlink, in spite of the possible risk. Also, when an option like `-backup' or `-link' acts to rename or remove the destination before copying, `cp' renames or removes the symbolic link rather than the file it points to.
By default, `cp' copies the contents of special files only when not copying recursively. This default can be overridden with the `-copy-contents' option.
`cp' generally refuses to copy a file onto itself, with the following exception: if `-force -backup' is specified with SOURCE and DEST identical, and referring to a regular file, `cp' will make a backup file, either regular or numbered, as specified in the usual ways (*note Backup options::). This is useful when you simply want to make a backup of an existing file before changing it.
The program accepts the following options. Also see *note Common options::.
#!/bin/sh # Usage: backup FILE... # Create a GNU-style backup of each listed FILE. for i; do cp --backup --force -- "$i" "$i" done
This option is independent of the `-interactive' or `-i' option: neither cancels the effect of the other.
This option is redundant if the `-no-clobber' or `-n' option is used.
$ mkdir c; : > a; ln -s a b; cp -aH a b c; ls -i1 c 74161745 a 74161745 b
Note the inputs: `b' is a symlink to regular file `a', yet the files in destination directory, `c/', are hard-linked. Since `-a' implies `-preserve=links', and since `-H' tells `cp' to dereference command line arguments, it sees two files with the same inode number, and preserves the perceived hard link.
Here is a similar example that exercises `cp''s `-L' option:
$ mkdir b c; (cd b; : > a; ln -s a b) $ cp -aL b c; ls -i1 c/b 74163295 a 74163295 b
In the absence of this option, each destination file is created with the mode bits of the corresponding source file, minus the bits set in the umask and minus the set-user-ID and set-group-ID bits (see section 7.3.2).
cp --parents a/b/c existing_dir
copies the file `a/b/c' to `existing_dir/a/b/c', creating any missing intermediate directories.
The WHEN value can be one of the following:
The WHEN value can be one of the following:
`rm' removes each given FILE. By default, it does not remove directories.
rm [OPTION]... [FILE]...
If the `-I' or `-interactive=once' option is given, and there are more than three files or the `-r', `-R', or `-recursive' are given, then `rm' prompts the user for whether to proceed with the entire operation. If the response is not affirmative, the entire command is aborted.
Otherwise, if a file is unwritable, standard input is a terminal, and the `-f' or `-force' option is not given, or the `-i' or `-interactive=always' option is given, `rm' prompts the user for whether to remove the file. If the response is not affirmative, the file is skipped.
Any attempt to remove a file whose last file name component is `.' or `..' is rejected without any prompting.
Warning: If you use `rm' to remove a file, it is usually possible to recover the contents of that file. If you want more assurance that the contents are truly unrecoverable, consider using `shred' (section 7.2.10).
The program accepts the following options. Also see *note Common options::.
This option is useful when removing a build chroot hierarchy, which normally contains no valuable data. However, it is not uncommon to bind-mount `/home' into such a hierarchy, to make it easier to use one's start-up file. The catch is that it's easy to forget to unmount `/home'. Then, when you use `rm -rf' to remove your normally throw-away chroot, that command will remove everything under `/home', too. Use the `-one-file-system' option, and it will warn about and skip directories on other file systems. Of course, this will not save your `/home' if it and your chroot happen to be on the same file system.
rm - -f
The Unix `rm' program's use of a single `-' for this purpose predates the development of the getopt standard syntax.
An exit status of zero indicates success, and a nonzero value indicates failure.
`ln' makes links between files. By default, it makes hard links; with the `-s' option, it makes symbolic (or soft) links.
ln [OPTION]... [-T] TARGET LINKNAME ln [OPTION]... TARGET
ln [OPTION]... TARGET... DIRECTORY ln [OPTION]... -t DIRECTORY TARGET...
A hard link is another name for an existing file; the link and the original are indistinguishable. Technically speaking, they share the same inode, and the inode contains all the information about a file --indeed, it is not incorrect to say that the inode is the file. Most systems prohibit making a hard link to a directory; on those where it is allowed, only the super-user can do so (and with caution, since creating a cycle will cause problems to many other utilities). Hard links cannot cross file system boundaries. (These restrictions are not mandated by POSIX, however.)
Symbolic links (symlinks for short), on the other hand, are a special file type (which not all kernels support: System V release 3 (and older) systems lack symlinks) in which the link file actually refers to a different file, by name. When most operations (opening, reading, writing, and so on) are passed the symbolic link file, the kernel automatically dereferences the link and operates on the target of the link. But some operations (e.g., removing) work on the link file itself, rather than on its target. The owner and group of a symlink are not significant to file access performed through the link, but do have implications on deleting a symbolic link from a directory with the restricted deletion bit set. On the GNU system, the mode of a symlink has no significance and cannot be changed, but on some BSD systems, the mode can be changed and will affect whether the symlink will be traversed in file name resolution. More on symbolic links in section 7.3.7.
Symbolic links can contain arbitrary strings; a dangling symlink occurs when the string in the symlink does not resolve to a file. There are no restrictions against creating dangling symbolic links. There are trade-offs to using absolute or relative symlinks. An absolute symlink always points to the same file, even if the directory containing the link is moved. However, if the symlink is visible from more than one machine (such as on a networked file system), the file pointed to might not always be the same. A relative symbolic link is resolved in relation to the directory that contains the link, and is often useful in referring to files on the same device without regards to what name that device is mounted on when accessed via networked machines.
When creating a relative symlink in a different location than the current directory, the resolution of the symlink will be different than the resolution of the same string from the current directory. Therefore, many users prefer to first change directories to the location where the relative symlink will be created, so that tab-completion or other file resolution will find the same target as what will be placed in the symlink.
The program accepts the following options. Also see section 7.3.8.
This option is weaker than the `-no-target-directory' (`-T') option, so it has no effect if both options are given.
An exit status of zero indicates success, and a nonzero value indicates failure.
# Create link ../a pointing to a in that directory.
# Not really useful because it points to itself.
ln -s a ..
# Change to the target before creating symlinks to avoid being confused. cd .. ln -s adir/a .
# Hard coded file names don't move well.
ln -s $(pwd)/a /some/dir/
# Relative file names survive directory moves and also
# work across networked file systems.
ln -s afile anotherfile
ln -s ../adir/afile yetanotherfile
`touch' changes the access and/or modification times of the specified files. Synopsis:
touch [OPTION]... FILE...
Any FILE argument that does not exist is created empty, unless option `-no-create' (`-c') or `-no-dereference' (`-h') was in effect.
A FILE argument string of `-' is handled specially and causes `touch' to change the times of the file associated with standard output.
If changing both the access and modification times to the current time, `touch' can change the timestamps for files that the user running it does not own but has write permission for. Otherwise, the user must own the files.
Although `touch' provides options for changing two of the times --the times of last access and modification-- of a file, there is actually a standard third one as well: the inode change time. This is often referred to as a file's `ctime'. The inode change time represents the time when the file's meta-information last changed. One common example of this is when the permissions of a file change. Changing the permissions doesn't access the file, so the atime doesn't change, nor does it modify the file, so the mtime doesn't change. Yet, something about the file itself has changed, and this must be noted somewhere. This is the job of the ctime field. This is necessary, so that, for example, a backup program can make a fresh copy of the file, including the new permissions value. Another operation that modifies a file's ctime without affecting the others is renaming. In any case, it is not possible, in normal operations, for a user to change the ctime field to a user-specified value. Some operating systems and file systems support a fourth time: the birth time, when the file was first created; by definition, this timestamp never changes.
Time stamps assume the time zone rules specified by the `TZ' environment variable, or by the system default rules if `TZ' is not set (see section 7.3.12). You can avoid ambiguities during daylight saving transitions by using UTC time stamps.
The program accepts the following options. Also see section_7.3.8.
An exit status of zero indicates success, and a nonzero value indicates failure.
sudo allows a permitted user to execute a command as the superuser or another user, as specified in the sudoers file. The real and effective uid and gid are set to match those of the target user as specified in the passwd file and the group vector is initialized based on the group file (unless the -P option was specified). If the invoking user is root or if the target user is the same as the invoking user, no password is required. Otherwise, sudo requires that users authenticate themselves with a password by default (NOTE: in the default configuration this is the user's password, not the root password). Once a user has been authenticated, a time stamp is updated and the user may then use sudo without a password for a short period of time (5 minutes unless overridden in sudoers).
When invoked as sudoedit, the -e option (described below), is implied.
sudo determines who is an authorized user by consulting the file /etc/sudoers. By running sudo with the -v option, a user can update the time stamp without running a command. If a password is required, sudo will exit if the user's password is not entered within a configurable time limit. The default password prompt timeout is 5 minutes.
If a user who is not listed in the sudoers file tries to run a command via sudo, mail is sent to the proper authorities, as defined at configure time or in the sudoers file (defaults to root). Note that the mail will not be sent if an unauthorized user tries to run sudo with the -l or -v option. This allows users to determine for themselves whether or not they are allowed to use sudo.
If sudo is run by root and the SUDO_USER environment variable is set, sudo will use this value to determine who the actual user is. This can be used by a user to log commands through sudo even when a root shell has been invoked. It also allows the -e option to remain useful even when being run via a sudo-run script or program. Note however, that the sudoers lookup is still done for root, not the user specified by SUDO_USER.
sudo can log both successful and unsuccessful attempts (as well as errors) to syslog(3), a log file, or both. By default sudo will log via syslog(3) but this is changeable at configure time or via the sudoers file.
sudo accepts the following command line options:
sudo tries to be safe when executing external commands.
There are two distinct ways to deal with environment variables. By default, the env_reset sudoers option is enabled. This causes commands to be executed with a minimal environment containing TERM, PATH, HOME, SHELL, LOGNAME, USER and USERNAME in addition to variables from the invoking process permitted by the env_check and env_keep sudoers options. There is effectively a whitelist for environment variables.
If, however, the env_reset option is disabled in sudoers, any variables not explicitly denied by the env_check and env_delete options are inherited from the invoking process. In this case, env_check and env_delete behave like a blacklist. Since it is not possible to blacklist all potentially dangerous environment variables, use of the default env_reset behavior is encouraged.
In all cases, environment variables with a value beginning with () are removed as they could be interpreted as bash functions. The list of environment variables that sudo allows or denies is contained in the output of sudo -V when run as root.
Please note that sudo will normally only log the command it explicitly runs. If a user runs a command such as sudo su or sudo sh, subsequent commands run from that shell will not be logged, nor will sudo's access control affect them. The same is true for commands that offer shell escapes (including most editors). Because of this, care must be taken when giving users access to commands via sudo to verify that the command does not inadvertently give the user an effective root shell.
file is a standard Unix program for recognizing the type of data contained in a computer file using magic number. Libmagic is the library which file uses, made available for Rodent to use directly.
The original version of file originated in Unix Research Version 4 in 1973. System V saw a major update with several important changes, most notably moving the file type information into an external text file rather than compiling it into the binary itself.
All major BSD and Linux distributions use a free, open-source reimplementation which was written in 1986-87 by Ian Darwin from scratch. It was expanded by Geoff Collyer in 1989 and since then has had input from many others, including Guy Harris, Chris Lowth and Eric Fischer; from late 1993 onward its maintenance has been organized by Christos Zoulas.
ps displays information about a selection of the active processes. If you want a repetitive update of the selection and the displayed information, use top(1) instead.
This version of ps accepts several kinds of options:
Note that ps -aux is distinct from ps aux. The POSIX and UNIX standards require that ps -aux print all processes owned by a user named x, as well as printing all processes that would be selected by the -a option. If the user named x does not exist, this ps may interpret the command as ps aux instead and print a warning. This behavior is intended to aid in transitioning old scripts and habits. It is fragile, subject to change, and thus should not be relied upon.
By default, ps selects all processes with the same effective user ID (euid=EUID) as the current user and associated with the same terminal as the invoker. It displays the process ID (pid=PID), the terminal associated with the process (tname=TTY), the cumulated CPU time in [dd-]hh:mm:ss format (time=TIME), and the executable name (ucmd=CMD). Output is unsorted by default.
The use of BSD-style options will add process state (stat=STAT) to the default display and show the command args (args=COMMAND) instead of the executable name. You can override this with the PS_FORMAT environment variable. The use of BSD-style options will also change the process selection to include processes on other terminals (TTYs) that are owned by you; alternately, this may be described as setting the selection to be the set of all processes filtered to exclude processes owned by other users or not on a terminal. These effects are not considered when options are described as being identical below, so -M will be considered identical to Z and so on.
Except as described below, process selection options are additive. The default selection is discarded, and then the selected processes are added to the set of processes to be displayed. A process will thus be shown if it meets any of the given selection criteria.
diff OPTIONS... FILES...
In the simplest case, two file names FROM-FILE and TO-FILE are given, and `diff' compares the contents of FROM-FILE and TO-FILE. A file name of `-' stands for text read from the standard input. As a special case, `diff - -' compares a copy of standard input to itself.
If one file is a directory and the other is not, `diff' compares the file in the directory whose name is that of the non-directory. The non-directory file must not be `-'.
If two file names are given and both are directories, `diff' compares corresponding files in both directories, in alphabetical order; this comparison is not recursive unless the `-r' or `-recursive' option is given. `diff' never compares the actual contents of a directory as if it were a file. The file that is fully specified may not be standard input, because standard input is nameless and the notion of file with the same name does not apply.
If the `-from-file=FILE' option is given, the number of file names is arbitrary, and FILE is compared to each named file. Similarly, if the `-to-file=FILE' option is given, each named file is compared to FILE.
`diff' options begin with `-', so normally file names may not begin `diff' options begin with `-', so normally file names may not begin with `-'. However, `-' as an argument by itself treats the remaining arguments as file names even if they begin with `-'.
An exit status of 0 means no differences were found, 1 means some differences were found, and 2 means trouble. Normally, differing binary files count as trouble, but this can be altered by using the `-a' or `-text' option, or the `-q' or `-brief' option.
bash [options] [file]
Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh).
Bash is intended to be a conformant implementation of the Shell and Utilities portion of the IEEE POSIX specification (IEEE Standard 1003.1). Bash can be configured to be POSIX-conformant by default.
`shred' overwrites devices or files, to help prevent even very expensive hardware from recovering the data.
Ordinarily when you remove a file (see section 7.2.2, the data is not actually destroyed. Only the index listing where the file is stored is destroyed, and the storage is made available for reuse. There are undelete utilities that will attempt to reconstruct the index and can bring the file back if the parts were not reused.
On a busy system with a nearly-full drive, space can get reused in a few seconds. But there is no way to know for sure. If you have sensitive data, you may want to be sure that recovery is not possible by actually overwriting the file with non-sensitive data.
However, even after doing that, it is possible to take the disk back to a laboratory and use a lot of sensitive (and expensive) equipment to look for the faint echoes of the original data underneath the overwritten data. If the data has only been overwritten once, it's not even that hard.
The best way to remove something irretrievably is to destroy the media it's on with acid, melt it down, or the like. For cheap removable media like floppy disks, this is the preferred method. However, hard drives are expensive and hard to melt, so the `shred' utility tries to achieve a similar effect non-destructively.
This uses many overwrite passes, with the data patterns chosen to maximize the damage they do to the old data. While this will work on floppies, the patterns are designed for best effect on hard drives. For more details, see the source code and Peter Gutmann's paper Secure Deletion of Data from Magnetic and Solid-State Memory (http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html), from the proceedings of the Sixth USENIX Security Symposium (San Jose, California, July 22-25, 1996).
Please note that `shred' relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. Exceptions include:
If you are not sure how your file system operates, then you should assume that it does not overwrite data in place, which means that shred cannot reliably operate on regular files in your file system.
Generally speaking, it is more reliable to shred a device than a file, since this bypasses the problem of file system design mentioned above. However, even shredding devices is not always completely reliable. For example, most disks map out bad sectors invisibly to the application; if the bad sectors contain sensitive data, `shred' won't be able to destroy it.
`shred' makes no attempt to detect or report this problem, just as it makes no attempt to do anything about backups. However, since it is more reliable to shred devices than files, `shred' by default does not truncate or remove the output file. This default is more suitable for devices, which typically cannot be truncated and should not be removed.
Finally, consider the risk of backups and mirrors. File system backups and remote mirrors may contain copies of the file that cannot be removed, and that will allow a shredded file to be recovered later. So if you keep any data you may later want to destroy using `shred', be sure that it is not backed up or mirrored.
shred [OPTION]... FILE[...]
shred [OPTION]... FILE[...]
The program accepts the following options. Also see section 7.3.8.
`-f' `-force' Override file permissions if necessary to allow overwriting.
shred -verbose /dev/fd0
Similarly, to erase all data on a selected partition of your hard disk, you could give a command like this:
shred -verbose /dev/sda5
A FILE of `-' denotes standard output. The intended use of this is to shred a removed temporary file. For example:
i=`mktemp` exec 3<>$i rm - $i echo Hello, world >&3 shred - >&3 exec 3>-
However, the command `shred - >file' does not shred the contents of FILE, since the shell truncates FILE before invoking `shred'. Use the command `shred file' or (if using a Bourne-compatible shell) the command `shred - 1<>file' instead.
An exit status of zero indicates success, and a nonzero value indicates failure.
The gs command invokes Ghostscript, an interpreter of Adobe Systems' PostScript(tm) and Portable Document Format (PDF) languages. gs reads files in sequence and executes them as Ghostscript programs. After doing this, it reads further input from the standard input stream (normally the keyboard), interpreting each line separately. The interpreter exits gracefully when it encounters the quit command (either in a file or from the keyboard), at end-of-file, or at an interrupt signal (such as Control-C at the keyboard).
The interpreter recognizes many option switches, some of which are described below. Please see the usage documentation for complete information. Switches may appear anywhere in the command line and apply to all files thereafter. Invoking Ghostscript with the -h or -? switch produces a message which shows several useful switches, all the devices known to that executable, and the search path for fonts; on Unix it also shows the location of detailed documentation.
Ghostscript may be built to use many different output devices. To see which devices your executable includes, run gs -h. Unless you specify a particular device, Ghostscript normally opens the first one of those and directs output to it, so if the first one in the list is the one you want to use, just issue the command
On Unix and MS Windows systems you can also send output to a pipe. For example, to pipe output to the lpr command (which, on many Unix systems, directs it to a printer), use the option
Some GNU programs (at least `cp', `install', `ln', and `mv') optionally make backups of files before writing new versions. These options control the details of these backups. The options are also briefly mentioned in the descriptions of the particular programs.
This option corresponds to the Emacs variable `version-control'; the values for METHOD are the same as those used in Emacs. This option also accepts more descriptive names. The valid METHODs are (unique abbreviations are accepted):
Each file has a set of file mode bits that control the kinds of access that users have to that file. They can be represented either in symbolic form or as an octal number.
The file mode bits have two parts: the file permission bits, which control ordinary access to the file, and special mode bits, which affect only some files.
There are three kinds of permissions that a user can have for a file:
In addition to the three sets of three permissions listed above, the file mode bits have three special components, which affect only executable files (programs) and, on most systems, directories:
In addition to the file mode bits listed above, there may be file attributes specific to the file system, e.g., access control lists (ACLs), whether a file is compressed, whether a file can be modified (immutability), and whether a file can be dumped. These are usually set using programs specific to the file system. For example:
Symbolic modes represent changes to files' mode bits as operations on single-character symbols. They allow you to modify either all or selected parts of files' mode bits, optionally based on their previous values, and perhaps on the current `umask' as well (see section 7.3.3).
The format of symbolic modes is:
where PERMS is either zero or more letters from the set `rwxXst', or a single letter from the set `ugo'.
The following sections describe the operators and other details of symbolic modes.
As an alternative to giving a symbolic mode, you can give an octal (base 8) number that represents the mode. This number is always interpreted in octal; you do not have to add a leading `0', as you do in C. Mode `0055' is the same as mode `55'.
A numeric mode is usually shorter than the corresponding symbolic mode, but it is limited in that normally it cannot take into account the previous file mode bits; it can only set them absolutely. (As discussed in the next section, the set-user-ID and set-group-ID bits of directories are an exception to this general limitation.)
The permissions granted to the user, to other users in the file's group, and to other users not in the file's group each require three bits, which are represented as one octal digit. The three special mode bits also require one bit each, and they are as a group represented as another octal digit. Here is how the bits are arranged, starting with the lowest valued bit:
|Value Mode||Corresponding Mode Bit|
|Other users not in the file's group:|
|Other users in the file's group|
|The file's owner:|
|Special mode bits:|
|1000||Restricted deletion flag or sticky bit|
|2000||Set group ID on execution|
|4000||Set user ID on execution|
For example, numeric mode `4755' corresponds to symbolic mode `u=rwxs,go=rx', and numeric mode `664' corresponds to symbolic mode `ug=rw,o=r'. Numeric mode `0' corresponds to symbolic mode `a='.
On most systems, if a directory's set-group-ID bit is set, newly created subfiles inherit the same group as the directory, and newly created subdirectories inherit the set-group-ID bit of the parent directory. On a few systems, a directory's set-user-ID bit has a similar effect on the ownership of new subfiles and the set-user-ID bits of new subdirectories. These mechanisms let users share files more easily, by lessening the need to use `chmod' or `chown' to share new files.
These convenience mechanisms rely on the set-user-ID and set-group-ID bits of directories. If commands like `chmod' and `mkdir' routinely cleared these bits on directories, the mechanisms would be less convenient and it would be harder to share files. Therefore, a command like `chmod' does not affect the set-user-ID or set-group-ID bits of a directory unless the user specifically mentions them in a symbolic mode, or sets them in a numeric mode. For example, on systems that support set-group-ID inheritance:
# These commands leave the set-user-ID and
# set-group-ID bits of the subdirectories alone,
# so that they retain their default values.
mkdir A B C
chmod 755 A
chmod 0755 B
chmod u=rwx,go=rx C
mkdir -m 755 D
mkdir -m 0755 E
mkdir -m u=rwx,go=rx F
If you want to try to set these bits, you must mention them explicitly in the symbolic or numeric modes, e.g.:
# These commands try to set the set-user-ID
# and set-group-ID bits of the subdirectories.
mkdir G H
chmod 6755 G
chmod u=rwx,go=rx,a+s H
mkdir -m 6755 I
mkdir -m u=rwx,go=rx,a+s J
If you want to try to clear these bits, you must mention them explicitly in a symbolic mode, e.g.:
# This command tries to clear the set-user-ID
# and set-group-ID bits of the directory D.
chmod a-s D
This behavior is a GNU extension. Portable scripts should not rely on requests to set or clear these bits on directories, as POSIX allows implementations to ignore these requests.
If the USERS part of a symbolic mode is omitted, it defaults to `a' (affect all users), except that any permissions that are set in the system variable `umask' are not affected. The value of `umask' can be set using the `umask' command. Its default value varies from system to system.
Omitting the USERS part of a symbolic mode is generally not useful with operations other than `+'. It is useful with `+' because it allows you to use `umask' as an easily customizable protection against giving away more permission to files than you intended to.
As an example, if `umask' has the value 2, which removes write permission for users who are not in the file's group, then the mode:
adds permission to write to the file to its owner and to other users who are in the file's group, but not to other users. In contrast, the mode:
ignores `umask', and does give write permission for the file to all users.
There is one more special type of symbolic permission: if you use `X' instead of `x', execute/search permission is affected only if the file is a directory or already had execute permission.
For example, this mode:
gives all users permission to search directories, or to execute files if anyone could execute them before.
The format of symbolic modes is actually more complex than described above (*note Setting Permissions::). It provides two ways to make multiple changes to files' mode bits.
The first way is to specify multiple OPERATION and PERMISSIONS parts after a USERS part in the symbolic mode.
For example, the mode:
gives users other than the owner of the file read permission and, if it is a directory or if someone already had execute permission to it, gives them execute/search permission; and it also denies them write permission to the file. It does not affect the permission that the owner of the file has for it. The above mode is equivalent to the two modes:
The second way to make multiple changes is to specify more than one simple symbolic mode, separated by commas. For example, the mode:
gives everyone permission to read the file and removes write permission on it for all users except its owner. Another example:
sets all of the permission bits for the file explicitly. (It gives users who are not in the file's group no permission at all for it.)
The two methods can be combined. The mode:
gives all users permission to read the file, and gives users who are in the file's group permission to execute/search it as well, but not permission to write to it. The above mode could be written in several different ways; another is:
The basic symbolic operations on a file's permissions are adding, removing, and setting the permission that certain users have to read, write, and execute or search the file. These operations have the following format:
USERS OPERATION PERMISSIONS
The spaces between the three parts above are shown for readability only; symbolic modes cannot contain spaces.
The USERS part tells which users' access to the file is changed. It consists of one or more of the following letters (or it can be empty; see section 7.3.3 for a description of what happens then). When more than one of these letters is given, the order that they are in does not matter.
`u' the user who owns the file;
`g' other users who are in the file's group;
`o' all other users;
`a' all users; the same as `ugo'.
The OPERATION part tells how to change the affected users' access to the file, and is one of the following symbols:
`+' to add the PERMISSIONS to whatever permissions the USERS already have for the file;
`-' to remove the PERMISSIONS from whatever permissions the USERS already have for the file;
`=' to make the PERMISSIONS the only permissions that the USERS have for the file.
The PERMISSIONS part tells what kind of access to the file should be changed; it is normally zero or more of the following letters. As with the USERS part, the order does not matter when more than one letter is given. Omitting the PERMISSIONS part is useful only with the `=' operation, where it gives the specified USERS no access at all to the file.
`r' the permission the USERS have to read the file;
`w' the permission the USERS have to write to the file;
`x' the permission the USERS have to execute the file, or search it if it is a directory.
For example, to give everyone permission to read and write a regular file, but not to execute it, use:
To remove write permission for all users other than the file's owner, use:
The above command does not affect the access that the owner of the file has to it, nor does it affect whether other users can read or execute the file.
To give everyone except a file's owner no permission to do anything with that file, use the mode below. Other users could still remove the file, if they have write permission on the directory it is in.
Another way to specify the same thing is:
The GNU system supports soft links or symbolic links. This is a kind of file that is essentially a pointer to another file name. Unlike hard links, symbolic links can be made to directories or across file systems with no restrictions. You can also make a symbolic link to a name which is not the name of any file. (Opening this link will fail until a file by that name is created.) Likewise, if the symbolic link points to an existing file which is later deleted, the symbolic link continues to point to the same file name even though the name no longer names any file.
The reason symbolic links work the way they do is that special things happen when you try to open the link. The `open' function realizes you have specified the name of a link, reads the file name contained in the link, and opens that file name instead. The `stat' function likewise operates on the file that the symbolic link points to, instead of on the link itself.
By contrast, other operations such as deleting or renaming the file operate on the link itself. The functions `readlink' and `lstat' also refrain from following symbolic links, because their purpose is to obtain information about the link. `link', the function that makes a hard link, does too. It makes a hard link to the symbolic link, which one rarely wants.
Some systems have for some functions operating on files have a limit on how many symbolic links are followed when resolving a path name. The limit if it exists is published in the `sys/param.h' header file.
Certain options are available in all of these programs. Rather than writing identical descriptions for each of the programs, they are described here. (In fact, every GNU program accepts (or should accept) these options.)
Normally options and operands can appear in any order, and programs act as if all the options appear before any operands. For example, `sort -r passwd -t :' acts like `sort -r -t : passwd', since `:' is an option-argument of `-t'. However, if the `POSIXLY_CORRECT' environment variable is set, options must appear before operands, unless otherwise specified for a particular command.
A few programs can usefully have trailing operands with leading `-'. With such a program, options must precede operands even if `POSIXLY_CORRECT' is not set, and this fact is noted in the program description. For example, the `env' command's options must appear before its operands, since in some cases the operands specify a command that itself contains options.
Most programs that accept long options recognize unambiguous abbreviations of those options. For example, `rmdir -ignore-fail-on-non-empty' can be invoked as `rmdir -ignore-fail' or even `rmdir -i'. Ambiguous options, such as `ls -h', are identified as such.
Some of these programs recognize the `-help' and `-version' options only when one of them is the sole command line argument. For these programs, abbreviations of the long options are not always recognized.
The `cp', `install', `ln', and `mv' commands normally treat the last operand specially when it is a directory or a symbolic link to a directory. For example, `cp source dest' is equivalent to `cp source dest/source' if `dest' is a directory. Sometimes this behavior is not exactly what is wanted, so these commands support the following options to allow more fine-grained control:
The commands in the `mv'-family are unusual in that they take a variable number of arguments with a special case at the end (namely, the target directory). This makes it nontrivial to perform some operations, e.g., move all files from here to ../d/, because `mv * ../d/' might exhaust the argument space, and `ls | xargs ...' doesn't have a clean way to specify an extra final argument for each invocation of the subject command. (It can be done by going through a shell command, but that requires more human labor and brain power than it should.)
The `-target-directory' (`-t') option allows the `cp', `install', `ln', and `mv' programs to be used conveniently with `xargs'. For example, you can move the files from the current directory to a sibling directory, `d' like this:
ls | xargs mv -t ../d -
However, this doesn't move files whose names begin with `.'. If you use the GNU `find' program, you can move those files too, with this command:
find . -mindepth 1 -maxdepth 1 \ | xargs mv -t ../d
But both of the above approaches fail if there are no files in the current directory, or if any file has a name containing a blank or some other special characters. The following example removes those limitations and requires both GNU `find' and GNU `xargs':
find . -mindepth 1 -maxdepth 1 -print0 \ | xargs -null -no-run-if-empty \ mv -t ../dtypeset@protect @@footnote SF@gobble@opt Now isn't that nerdy?
The `-target-directory' (`-t') and `-no-target-directory' (`-T') options cannot be combined.
Some GNU programs (at least `cp' and `mv') allow you to remove any trailing slashes from each SOURCE argument before operating on it. The `-strip-trailing-slashes' option enables this behavior.
This is useful when a SOURCE argument may have a trailing slash and specify a symbolic link to a directory. This scenario is in fact rather common because some shells can automatically append a trailing slash when performing file name completion on such symbolic links. Without this option, `mv', for example, (via the system's rename function) must interpret a trailing slash as a request to dereference the symbolic link and so must rename the indirectly referenced directory and not the symbolic link. Although it may seem surprising that such behavior be the default, it is required by POSIX and is consistent with other parts of that standard.
Certain commands can operate destructively on entire hierarchies. For example, if a user with appropriate privileges mistakenly runs `rm -rf / tmp/junk', that may remove all files on the entire system. Since there are so few legitimate uses for such a command, GNU `rm' normally declines to operate on any directory that resolves to `/'. If you really want to try to remove all the files on your system, you can use the `-no-preserve-root' option, but the default behavior, specified by the `-preserve-option', is safer for most purposes.
The commands `chgrp', `chmod' and `chown' can also operate destructively on entire hierarchies, so they too support these options. Although, unlike `rm', they don't actually unlink files, these commands are arguably more dangerous when operating recursively on `/', since they often work much more quickly, and hence damage more files before an alert user can interrupt them. Tradition and POSIX require these commands to operate recursively on `/', so they default to `-no-preserve-root', but using the `-preserve-root' option makes them safer for most purposes. For convenience you can specify `-preserve-root' in an alias or in a shell function.
Note that the `-preserve-root' option also ensures that `chgrp' and `chown' do not modify `/' even when dereferencing a symlink pointing to `/'.
In POSIX systems, a user can specify the time zone by means of the `TZ' environment variable. For information about how to set environment variables, see section 7.3.13. The functions for accessing the time zone are declared in `time.h'.
You should not normally need to set `TZ'. If the system is configured properly, the default time zone will be correct. You might set `TZ' if you are using a computer over a network from a different time zone, and would like times reported to you in the time zone local to you, rather than what is local to the computer.
In POSIX.1 systems the value of the `TZ' variable can be in one of three formats. With the GNU C library, the most common format is the last one, which can specify a selection from a large database of time zone information for many regions of the world. The first two formats are used to describe the time zone information directly, which is both more cumbersome and less precise. But the POSIX.1 standard only specifies the details of the first two formats, so it is good to be familiar with them in case you come across a POSIX.1 system that doesn't support a time zone information database.
The first format is used when there is no Daylight Saving Time (or summer time) in the local time zone:
The STD string specifies the name of the time zone. It must be three or more characters long and must not contain a leading colon, embedded digits, commas, nor plus and minus signs. There is no space character separating the time zone name from the OFFSET, so these restrictions are necessary to parse the specification correctly.
The OFFSET specifies the time value you must add to the local time to get a Coordinated Universal Time value. It has syntax like [`+'|`-']HH[`:'MM[`:'SS]]. This is positive if the local time zone is west of the Prime Meridian and negative if it is east. The hour must be between `0' and `23', and the minute and seconds between `0' and `59'.
For example, here is how we would specify Eastern Standard Time, but without any Daylight Saving Time alternative:
The second format is used when there is Daylight Saving Time:
STD OFFSET DST [OFFSET]`,'START[`/'TIME]`,'END[`/'TIME]
The initial STD and OFFSET specify the standard time zone, as described above. The DST string and OFFSET specify the name and offset for the corresponding Daylight Saving Time zone; if the OFFSET is omitted, it defaults to one hour ahead of standard time.
The remainder of the specification describes when Daylight Saving Time is in effect. The START field is when Daylight Saving Time goes into effect and the END field is when the change is made back to standard time. The following formats are recognized for these fields:
`JN' This specifies the Julian day, with N between `1' and `365'. February 29 is never counted, even in leap years.
`N' This specifies the Julian day, with N between `0' and `365'. February 29 is counted in leap years.
`MM.W.D' This specifies day D of week W of month M. The day D must be between `0' (Sunday) and `6'. The week W must be between `1' and `5'; week `1' is the first week in which day D occurs, and week `5' specifies the last D day in the month. The month M should be between `1' and `12'.
The TIME fields specify when, in the local time currently in effect, the change to the other time occurs. If omitted, the default is `02:00:00'.
For example, here is how you would specify the Eastern time zone in the United States, including the appropriate Daylight Saving Time and its dates of applicability. The normal offset from UTC is 5 hours; since this is west of the prime meridian, the sign is positive. Summer time begins on the first Sunday in April at 2:00am, and ends on the last Sunday in October at 2:00am.
The schedule of Daylight Saving Time in any particular jurisdiction has changed over the years. To be strictly correct, the conversion of dates and times in the past should be based on the schedule that was in effect then. However, this format has no facilities to let you specify how the schedule has changed from year to year. The most you can do is specify one particular schedule --usually the present day schedule-- and this is used to convert any date, no matter when. For precise time zone specifications, it is best to use the time zone information database (see below).
The third format looks like this:
Each operating system interprets this format differently; in the GNU C library, CHARACTERS is the name of a file which describes the time zone.
If the `TZ' environment variable does not have a value, the operation chooses a time zone by default. In the GNU C library, the default time zone is like the specification `TZ=:/etc/localtime' (or `TZ=:/usr/local/etc/localtime', depending on how GNU C library was configured. Other C libraries use their own rule for choosing the default time zone, so there is little we can say about them.
If CHARACTERS begins with a slash, it is an absolute file
name; otherwise the library looks for the file `/share/lib/zoneinfo/CHARACTERS'.
The `zoneinfo' directory contains data files describing local
time zones in many different parts of the world. The names represent
major cities, with subdirectories for geographical areas; for example,
`Asia/Hong_Kong'. These data files are installed by the system administrator, who also sets `/etc/localtime' to point to the data file for the local time zone. The GNU C library comes with a large database of time zone information for most regions of the world, which is maintained by a community of volunteers and put in the public domain.
When a program is executed, it receives information about the context in which it was invoked in two ways. The first mechanism uses the ARGV and ARGC arguments to its `main' function. The second mechanism uses environment variables and is discussed in this section.
The ARGV mechanism is typically used to pass command-line arguments specific to the particular program being invoked. The environment, on the other hand, keeps track of information that is shared by many programs, changes infrequently, and that is less frequently used.
The environment variables discussed in this section are the same environment variables that you set using assignments and the `export' command in the shell. Programs executed from the shell inherit all of the environment variables from the shell.
Standard environment variables are used for information about the user's home directory, terminal type, current locale, and so on; you can define additional variables for other purposes. The set of all environment variables that have values is collectively known as the environment.
Names of environment variables are case-sensitive and must not contain the character `='. System-defined environment variables are invariably uppercase.
The values of environment variables can be anything that can be represented as a string. A value must not contain an embedded null character, since this is assumed to terminate the string.
This section contains information about structural module design of interest only to programmers, so you may skip this section if you are not interested in looking under the hood and examining how the cables are wired up.
Modules are divided into two types, root modules and functional modules. The functionality of both type of modules is defined in terms of four basic types of functions which generate a functional space isomorphic to the set of complex numbers with rational real component and integer imaginary component. That might sound like a bunch of hogwash to someone without a graduate mathematics degree, but it works and is very flexible (both in practice and in theory).
Plugin functions may be specified as one of the following types.
This document was generated using the LaTeX2HTML translator Version 2008 (1.71)
Copyright © 1993, 1994, 1995, 1996,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -no_subdir -split 0 -show_section_numbers RTFM.tex
The translation was initiated by on 2011-10-18