Table of Contents
xfm - X file and applications manager
xfm [options ...]
Xfm
is a file and applications manager program for the X window system. It provides
virtually all of the features that you would expect in a file manager -
move around your directory tree in multiple windows, move, copy or delete
files, and launch programs with simple mouse operations. Directory displays
are updated automatically in regular intervals when the contents of the
directory changes. The integrated application manager provides a kind of
``shelf'' onto which you can place your favorite applications, as well as the
files and directories you are currently working with. It also allows you
to access different groups of applications and files. User-definable file
types let you specify a command to be executed when double-clicking on a
file or dropping other files onto it. Last not least, xfm can automatically
mount and unmount special devices like floppies as you open and close the
corresponding directories (mount points).
Xfm accepts all the usual
toolkit options. Furthermore, the following options let you print xfm's version
number and control which windows should be displayed at startup.
- -version
- Print the version number and exit.
- -appmgr
- Only display the application manager
window.
- -filemgr
- Only display the file manager window.
If both -appmgr and
-filemgr are specified, then the applications and one file manager window
will be displayed, which is also the default. If only -filemgr is specified,
the application manager will not be available in this session.
When the user starts up xfm for the first time (more
precisely, when the user does not yet have a .xfm directory), a dialog pops
up which asks whether she wants to run the xfm.install script. This script
usually creates a .xfm directory in the user's home directory and places
some default configuration files in there. These are your personal configuration
files, and may be edited to customise xfm to your own tastes.
The initial
setup dialog gives you the options to either Continue (go ahead and install
the default setup), Cancel (go ahead, but don't run xfm.install) or Abort
(immediately exit xfm). It is recommended that you press Continue here. The
output of the install script can then be read in the log window (see below).
Note that if you choose Cancel, then xfm will only provide a rudimentary
setup without any special file types or application groups. This can be
used to quickly check whether xfm is running properly, but it will not
be very useful for the average user.
Most of it should be fairly obvious.
There is one application window and zero or more file windows in which
directories (also termed folders) are displayed. In order to perform an
action, you either select items and then invoke a menu operation, or you
drag items from a file window to a second (maybe the same) file window
or the application window. You can also double-click on an item to start
a corresponding action (like launching an application, editing a file,
or changing directories), and press the right menu button on an item to
bring up a menu containing operations for a single file or application.
Pressing the right button on the background of the application window
displays the application menu. File operations are accessed from the file
window menu bar as usual.
The left-hand mouse button selects an item (and
deselects all others in the same window). The second button toggles the
selected state of an item.
A string containing the paths of the selected
file items can be requested by other applications using the standard selection
mechanism (PRIMARY selection). To provide visual feedback, the file window
that owns the selection paints its status line using a special highlight
color. You can then paste the list of selected files in some other window
such as an xterm.
You can drag with the left-hand button to another window
(or another icon, in general a valid destination will be highlighted with
a border when the cursor is over it) to move files from one directory to
another. The second button used in the same way will copy files. You can
also drag around items in the application window; again, the left mouse
button moves, and the second button copies the selected items to a new
position. Applications can be launched by dropping files on them; and installing
files and programs in the application manager can be done by dropping files
on the background of the application window. Finally, new file windows
can be opened by simply dragging a directory icon to the root window.
The
action taken when double-clicking on a file depends on the type of the file.
If it is a directory, it is displayed in the file window. If it is an executable,
the program is started. Other files are opened in the default editor (specified
by the defaultEditor resource), unless another action is given in the xfmrc
file (see CONFIGURATION below).
The output of child processes invoked by
xfm is captured in a special log window. This window provides buttons for
clearing the window contents and for hiding the window. You can also specify
whether you want the window to pop up automagically when new output is
available (Auto Popup option, enabled by default), and explicitly show
the window using the Show log option of the View menu.
Directories can be
displayed in three different forms: tree (display subdirectories in tree-like
form), icon (display directories and files as icons) and text (similar
to ls -l). These options are selected from the View menu. In the tree form,
clicking on the arrows takes you up or down one level.
Directory displays
are updated automatically in regular intervals when the contents of the
directory changes. You can also explicitly request a folder update by double-clicking
on the directory name field of the corresponding file window.
A menu of
recently visited directories can be popped up by pressing the right mouse
button on the directory name field of the file window.
Many
menu operations can also be invoked with corresponding keyboard shortcuts
which can be changed by configuring the translations in the applications
defaults file accordingly. The default shortcuts, as defined in the distributed
application defaults file, are given in parentheses below.
FILE MENU
File
manipulation operations.
- New... (n)
Create a new (and empty) file.
- Move... (m)
Rename a single item (directory or file) or move selected items to another
directory.
- Copy... (c)
Create a copy of a single item under a new name or copy selected items
to another directory.
- Link... (l)
Like Copy, but creates symbolic links rather than copying the selected
items.
- Delete (d, Del, Backspace)
Delete the selected items.
- Select... (s)
Select items by pattern. The usual metacharacters are recognized (*, ?,
[ ]). (Currently there is no provision for escaping these.)
- Select all (a)
Select all items in the current directory (except the parent directory).
- Deselect all (u)
Deselect all items.
- Own Selection (o)
Request ownership of the PRIMARY selection. This is useful if some files
had been selected before but the ownership of the X-selection was lost and
the user later wants to get the ownership back.
- Xterm (x)
Invokes an xterm(1)
in the current directory (using the command specified
with the defaultXterm resource).
- About xfm...
Display a box with some information about xfm.
- Quit (q)
Terminate xfm.
FOLDER MENU
Operations dealing with directories and the file
window.
- New... (Shift+n)
Create a new directory.
- Go to... (Shift+g)
Display the specified directory.
- Home (Shift+h)
Display your home directory.
- Up (Shift+u)
Display the parent directory.
- Empty
Delete all items in the current directory.
- Clone (Shift+c)
Clone this file window (open another file window on the same directory).
- Close (Shift+q)
Close this file window.
VIEW MENU
Options for the directory display and
the log window.
- Tree (Ctrl+r)
Select the tree form display.
- Icons (Ctrl+i)
Select the icons form display.
- Text (Ctrl+t)
Select the text form display. An additional Option menu appears which allows
you to select the information to be shown in the text view.
- Sort by name
(Ctrl+n)
Sort directory by name.
- Sort by size (Ctrl+s)
Sort directory by size.
- Sort by date (Ctrl+d)
Sort directory by date.
- Filter... (Ctrl+f)
Specify a pattern to determine the files which should be displayed in the
file window. (This only affects normal files, i.e. directory items will not
be filtered. The Clear button in the Filter dialog form reverts to the full
display.)
- Hide folders (Ctrl+h)
Suppress directory items.
- Mix folders/files (Ctrl+m)
Mix directories and other files.
- Show hidden files (Ctrl+u)
Show hidden files (files starting with a dot).
- Show log
Redisplay the log window.
FILE POPUP MENU
Operations on a single file. This
menu pops up when pressing the right mouse button on a directory or file
icon.
- Open
- Open a file window on the selected item. This option is only available
if the selected item is a directory.
- Edit
Edit the selected item using the program specified in the defaultEditor
resource (only available if the selected item is not a directory).
- View
Same as Edit, but invokes a program for viewing the file (defaultViewer
resource).
- Rename...
Rename the selected item (same as Move, but shows the current filename
as the default).
- Move...
Move the selected item.
- Copy...
Copy the selected item.
- Link...
Create a symbolic link.
- Delete
Delete the selected item.
- Information...
Display information about the selected item (file size, permissions and
such).
- Permissions...
Change the permissions of the selected item.
APPLICATION MENU
Operations
for managing the application window.
- Install...
Install a new application in the application window. Pops up a dialog form
into which you can enter the necessary information (see APPLICATION FILES
for a discussion of the fields in this form).
- Install group...
Simplified install dialog form for creating a new application group (see
APPLICATION FILES).
- Cut
Move the selected application items into a ``clip'' file (specified by the
applicationDataClip resource). Together with the Paste option, this allows
you to move application items between different application groups.
- Copy
Like Move, but simply copies the selected items instead of removing them
from the application window.
- Paste
Insert the contents of the clip file into the application window.
- Delete
Delete the selected items from the application window.
- About xfm...
Display a box with some information about xfm.
- Quit
Terminate xfm.
APPLICATION POPUP MENU
Operations on a single application
item. This menu pops up when pressing the right mouse button on an icon
in the application window.
- Edit...
Edit an application item. Pops up a dialog form which allows you to change
the configuration information associated with the selected item (see CONFIGURATION
for a discussion of the fields in this form).
- Cut
Move the selected item to the clip file.
- Copy
Copy the selected item to the clip file.
- Delete
Delete the selected item from the application window.
APPLICATION WINDOW
BUTTONS
These buttons at the bottom of the application window allow you
to navigate in the application group tree and open new file windows.
- Back
Return to the previous application group.
- Main
Return to the main application group (the one loaded at startup time).
- Reload
Reload the current application file. This option is useful to update the
contents of an application window after manual editing of the application
file.
- File window
Open a new file window on the user's home directory.
Various aspects
of xfm can be configured by changing corresponding resource settings in
the application defaults file. Some important resources are listed below:
- highlightColor
The color used for highlighting selected items, as well as the status line
of the file window which owns the primary selection (if any).
- bitmapPath
- pixmapPath
The path on which to search for bitmap and pixmap icons, respectively.
- applicationDataFile
- configFile
- devFile
- magicFile
The names of the application and configuration files used by xfm (see CONFIGURATION).
Normally, these files will be located in ~/.xfm. You may wish to change this,
e.g., if you want to provide a system-wide xfmrc file. (The application files
should always be kept in the user's home directory, such that each user
can save his/her private application settings.)
- applicationDataDir
The directory in which the application files for new application groups
are located (see the Install group option of the application menu), usually
~/.xfm.
- applicationDataClip
The ``clip'' file used in Cut/Copy/Paste operations in the aplication window,
usually ~/.xfm/.XfmClip.
- doubleClickTime
Set the time interval in milliseconds for which a sequence of two mouse
clicks should be interpreted as a double click. Default: 300.
- updateInterval
Set the time interval in milliseconds in which to perform automatic folder
updates. Default: 10000.
- confirmXXX
Resources to request confirmation for various operations. XXX can be any
one of Deletes, DeleteFolder, Copies, Moves, Overwrite and Quit. By default
these are all enabled.
- defaultEditor
The command with which xfm invokes your favorite editor.
- defaultViewer
The command with which xfm invokes your favorite viewer.
- defaultXterm
The command with which xfm runs an xterm.
- shellCommand
Specifies the shell to use for running commands.
- BourneShells
xfm calls other programs by executing your shell. Since Bourne compatible
shells need one extra parameter, xfm needs to know about the type of the
shell. If this resource is not set (default), or is equal to the special
string AUTO, a quick-and-dirty test is done at startup. This test will fail
if the shell's initialisation files cause some output. If this happens, change
these files, or set the BourneShells resource to a comma separated list
of full path names of Bourne compatible shells. If your shell matches an
entry in this list, xfm will assume it is a Bourne shell.
There are way
too many available resources to list them all in this manual page, so please
take a look at the application defaults file for more information.
Besides
the application resources, xfm can be configured by means of three different
files, which are usually named xfmrc, xfmdev and magic, and are located
in the ~/.xfm directory. Moreover, there is a number of so-called application
files, from which xfm determines the contents of the application window,
like the Apps file which usually describes the contents of the main application
group. All these files are plain ASCII files which can be edited using any
text editor. (Note that application files are also written by xfm itself
whenever the contents of the application window changes.) Any line in these
files which starts with a hash sign (#) is interpreted as a comment; empty
lines are ignored.
The xfmrc file specifies the types
of ordinary (non-executable, non-directory) files which xfm should recognize.
Each file type associates a pattern with an icon and two different kinds
of actions (commands to be executed on the file). If xfm has been compiled
with the MAGIC_HEADERS option then it is possible to specify icons (but
not actions) for directories and executables as well. Each line has the
following format:
pattern:icon:push-action:drop-action
As indicated, the different fields are separated by a colon (use \: to escape
the : character, and \\ to escape the backslash character itself). The meaning
of these fields is explained below.
- pattern
- This field allows you to specify
which files belong to the type. File types can either be specified by a
filename pattern, which refers to the name of a file, or a magic header,
which refers to the contents of the file, or both.
There are three types
of filename patterns: Literal patterns specify a literal filename such
as ``core.'' Suffix patterns specify a suffix the filename must match, and are
indicated by a leading asterisk, as in ``*.c.'' (All characters following the
initial * are interpreted as literals; there is no expansion of embedded
wildcards.) Finally, prefix patterns specify a prefix to be matched against
the filename. They are denoted by a trailing asterisk, as in ``README*.''
Magic
headers are specified by a symbolic name given in the magic file, enclosed
in angle brackets. Entries referring to a magic header cause the contents
of the file to be checked against the magic numbers in the magic file. The
format of these entries is described in Section MAGIC HEADERS below.
- icon
- The name of the bitmap or pixmap file containing the icon to be displayed
for this file type.
- push-action
- The command to be executed when the user
double-clicks on a file of this type. This command is passed to the shell
(via -c), together with the name of the selected file. The command is executed
in the directory where the selected file is located. The filename is available
in the command as the positional parameter number one, such that an action
of the form xyz $1 invokes the command xyz on the selected file. There are
also three special kinds of push actions built into xfm, EDIT and VIEW
which invoke the default editor and default viewer on the selected file,
respectively, and LOAD which loads the selected file as an application
file (discussed in Section APPLICATION FILES).
- drop-action
- Similar to the
push action, this field denotes a command to be executed when a collection
of selected files is dropped onto the file. The absolute target filename
itself is available as positional parameter $1, the remaining arguments
denote the names of the files dropped onto the target file. The command
is executed in the directory which contains the selected files. No special
built-in commands are available for this type of action.
If an action field
is empty, the corresponding action defaults to ``do nothing.''
For instance,
the following entry defines an icon and an EDIT push action for .c files:
*.c:xfm_c.xpm:EDIT:
As another example, here is an entry for compressed (i.e. gzipped) tar files.
The push action causes the archive to be extracted, while the drop action
replaces the contents of the archive with the files which have been dragged
onto the archive:
*.tar.gz:xfm_taz.xpm:exec tar xfvz $1:exec tar cfvz $*
(Note the use of the shell's exec command. Since actions are invoked through
the shell, it is often useful to replace the shell with the actual command
which is to be executed, in order to conserve memory space on small systems.)
It is possible that different patterns given in the xfmrc file overlap.
In this case xfm uses the first pattern which matches. Therefore you should
always list the more specific patterns first. For instance, the following
two entries specify what to do with compressed tar files (specific case)
and other .gz files (default case):
*.tar.gz:xfm_taz.xpm:exec tar xfvz $1:exec tar cfvz $*
*.gz:xfm_z.xpm:exec gunzip $1:
Xfm also enables you to prompt for additional parameters before an action
is executed. This is generally more useful with application entries than
with file actions, and will therefore be described in the context of application
configuration, see PARAMETER DIALOGS below.
When compiled with
the MAGIC_HEADERS option, xfm can determine file types using the magic
numbers contained in the files.
The magic numbers are described in a configuration
file whose path is obtained from the magicFile resource. The format of the
file is the same as that of the magic(5)
file, with some extensions like
regular expression matching. (See xfmtype(1)
.)
There are five built-in types
which are used if all the patterns in the magic file fail:
- unreadable
- Read
failed.
- empty
- File size is zero.
- special
- Not a regular file.
- ascii
- Could be
read and looks like ASCII.
- data
- Could be read but all tests failed and doesn't
look like ASCII.
To specify a magic file type you include it between angle
brackets at the beginning of the pattern field:
<GIF>:xfm_gif.xpm:exec xpaint $1:
or combined with a filename pattern:
<ascii>*.cc:xfm_cc.xpm:EDIT:
In the latter case, the file must meet both conditions, i.e. be an ASCII
file and have a .cc suffix.
To include angle brackets in the type or the
pattern you must escape them using backslashes.
If xfm is compiled with
the MAGIC_HEADERS option, it is also possible to specify custom icons for
directories and executables. For this purpose, the magic file distributed
with xfm provides magic file types named <DIR>, <EXEC>, etc. For instance, here
is an entry which specifies a special icon for hidden directories:
<DIR>.*:hidden_dir.xpm::
In the same way you can also override the built-in icons for displaying
arbitrary directories and executables:
<DIR>..:parent_dir.xpm::
<DIR>:plain_dir.xpm::
<DIR LNK>:link_dir.xpm::
The device configuration file, xfmdev, lets you specify
which mount points xfm should keep track of, and which actions to perform
in order to mount and unmount the corresponding file systems. This allows
you to access file systems on special devices such as floppies, CD-Roms,
etc. in a transparent way. All you have to do is to enter a directory named
in xfmdev (e.g. by opening a file window on it), and xfm will automatically
perform the corresponding mount action for you. Likewise, if you leave such
a directory, xfm invokes the corresponding unmount action. (CAUTION: You
still have to take care that you unmount a file system, e.g. by closing every
file window which has been opened on it, before you physically remove the
corresponding medium.)
An entry of the xfmdev file has the following format:
directory:mount-action:umount-action
The directory field denotes the mount point of the file system, mount-action
the command to be executed in order to mount the file system, and umount-action
the command for unmounting the file system. Here is a ``typical'' entry from
my xfmdev file:
/disk/a:mount /disk/a:umount /disk/a
Of course, the details of how to mount a floppy file system may vary from
system to system, and you might have to take special actions if you want
to use mount as an ordinary user. See mount(8)
for details.
Application
files are used to specify the contents of the application window. Normally,
these files are not altered with a text editor, but are updated by xfm
whenever the contents of the application window changes. An understanding
of the application data is necessary, however, if you want to edit an existing
or create a new entry using the Install, Install group and Edit options
of the application menu. Each entry has the following form:
name:directory:filename:icon:push-action:drop-action
The name and icon fields specify the name of the application and a corresponding
icon which should be displayed in the application window. The push-action
and drop-action fields have the same meaning as in the xfmrc file: they
indicate the commands to be passed to the shell when the user double-clicks
on the icon or drops files onto it, respectively. The directory and filename
fields let you specify a file to be passed to the application. These fields
are filled in by xfm when the user drags a file or directory onto the application
window. Xfm also properly sets up the action fields when installing a file
which has a matching entry in the xfmrc file.
As usual, the target file
(if specified) and any dropped files are passed to the push and drop actions
as the first and the remaining parameters, respectively, see FILE TYPE
CONFIGURATION for details. The drop action is executed in the directory
containing the selected files, while the push action starts in the directory
specified by the directory field, if it is nonempty, and in the user's home
directory otherwise.
In an application file, xfm recognizes four special
types of built-in push actions. The EDIT and VIEW actions, as in xfmrc, invoke
the default editor and viewer, respectively. The OPEN action indicates that
the target file actually is a directory onto which xfm should open a new
file window when the user double-clicks on the corresponding icon. Finally,
the LOAD action tells xfm that the target is an application file whose
contents are to be loaded into the application window. This action allows
you to manage different groups of applications. Note that application files
can also be loaded by a corresponding file type entry, since the LOAD action
is also supported in the xfmrc file. (The OPEN action is not supported there,
however, as it wouldn't make sense anyhow. Note that you can only specify
actions for regular files.)
Xfm provides a number of operations which let
you manipulate application groups in a convenient manner. The items in the
application window can be moved and copied using drag and drop as usual.
The Cut, Copy and Paste options of the application menu provide a means
to move and copy application items between different application files.
Moreover, xfm keeps a stack of application files loaded from a file or
the application window via a LOAD action. The Back button at the bottom
of the application window lets you return to the previous group of applications,
and the Main button reloads your startup application file (and empties
the stack). Finally, the Install group option of the application menu allows
you to create entries for new application groups easily. You only have to
specify the name of the group, the name of the corresponding application
file, and the name of the icon file. The remaining fields of the entry
are filled in by xfm automatically.
It is time for some examples. Here are
three useful entries from my Apps file which I use to start an xterm, my
favorite editor, and print a file using lpr, respectively:
Terminal:::xterm.xpm:exec xterm:
Editor:::editor.xpm:exec emacs:exec emacs $*
Printer:::printer.xpm::exec lpr $*
Xfm gives you great flexibility in configuring special types of actions.
For instance, the following entries can be used to implement a simple trashcan
feature and an action to open a window on a floppy disk:
Trash::.trash:trash.xpm:OPEN:shift; mv $* ~/.trash
A\::/disk:a:disk.xpm:OPEN:
A typical entry for an application group looks as follows:
Toolbox:~/.xfm:Toolbox:apps.xpm:LOAD:
It is also instructive to take a look at how xfm sets up the entries when
you drag files or directories to the application window. Play around with
these features. It is fun! Many things can be done, if not with a single
command then maybe with a tiny shell script.
Xfm lets you
prompt the user for additional parameters when a push or drop action is
invoked. In such a case, a dialog form appears, with one field for each
parameter, into which the user can enter the required arguments. Currently,
no checking is done on the supplied parameters; in fact, the user can simply
leave all fields empty. Parameters are specified in an action using the
form
%parameter-name%
where parameter-name is an arbitrary string not containing the % character,
which will be displayed in the dialog form. (As usual, a literal % character
can be escaped with the backslash.) Xfm replaces each such %...% construct
with the corresponding value entered by the user. For instance, here is
an entry which allows you to execute a program with parameters:
exec:::app.xpm:exec %Program\:% %Parameters\:%:
exec $1 %Parameters\:%
As the push action in the example indicates, it is possible to specify
more than one parameter field. A default value for a parameter can be specified
using the notation
%parameter-name--default-value%
For instance:
transfig:::app.xpm::transfig -L %Language\:--eepic% $*
Xfm supports icons in both the X bitmap and Arnaud Le Hors' XPM format.
A collection of useful icons is included in the distribution.
- ~/.xfm
- Standard location for xfm configuration and application files (see CONFIGURATION
above).
xfmtype(1)
, X(1)
, xconsole(1)
, xterm(1)
, magic(5)
, mount(8)
,
Arnaud Le Hors: XPM Manual. The X PixMap Format, Groupe Bull, 1993.
Xfm catches the TERM signal to gracefully terminate the program,
unmounting all open file systems which have been mounted by xfm. However,
some window and session managers may not send TERM signals to their client
applications when terminating an X session. Therefore it might be necessary
to explicitly quit xfm or manually close file windows mounted by xfm before
exiting X.
Do not specify a relative path in the directory field of an application
item, because when you execute a push action on the application the current
directory might not always be what you expect. This will probably be fixed
in a future release. ;-)
Xfm depends on your shell - see resource BourneShells.
Simon Marlow (simonm@dcs.glasgow.ac.uk) from the University of Glasgow,
Albert Graef (ag@muwiinfa.geschichte.uni-mainz.de) from the University of Mainz,
and Till Straumann (strauman@sun6hft.ee.tu-berlin.de) from the Technical University
of Berlin, with help from many other people: Dave Safford (dave.safford@edu.tamu.sc;
automatic folder updates); Robert Vogelgesang (vogelges@rhrk.uni-kl.de; shell
detection code); Juan D. Martin (juando@cnm.us.es; magic headers); Kevin Rodgers
(rodgers@lvs-emh.lvs.loral.com; Filter option); Scott Heavner (sdh@falstaff.MAE.cwru.edu;
View option); Brian King (ender@ee.WPI.EDU; default values in parameter dialogs).
Table of Contents