XFM(1)
NAME
xfm - X file and applications manager
SYNOPSIS
xfm [options ...]
DESCRIPTION
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 applica-
tions, as well as the files and directories you are cur-
rently working with. It also allows you to access differ-
ent groups of applications and files. User-definable file
types let you specify a command to be executed when dou-
ble-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).
OPTIONS
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 dis-
played, which is also the default. If only -filemgr is
specified, the application manager will not be available
in this session.
RUNNING XFM FOR THE FIRST TIME
There are a number of configuration files which need to be
placed in your home directory in order to run xfm. To
install the default configuration files, run the program
xfm.install which will create a directory ~/.xfm and
install some files in there. These are your personal con-
figuration files, and may be edited to customise Xfm to
your own tastes.
USAGE
Most of it should be fairly obvious. There is one applica-
tion window and zero or more file windows in which direc-
tories (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, edit-
ing a file, or changing directories), and press the right
menu button on an item to bring up a menu containing oper-
ations 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.
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 but-
ton 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 win-
dow. 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 dis-
played 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 CONFIGURA-
TION below).
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.
MENU COMMANDS
FILE MENU
File manipulation operations.
New...
Create a new (and empty) file.
Move...
Rename a single item (directory or file) or move
selected items to another directory.
Copy...
Create a copy of a single item under a new name or
copy selected items to another directory.
Link...
Like Copy, but creates symbolic links rather than
copying the selected items.
Delete
Delete the selected items.
Select...
Select items by pattern. The usual metacharacters are
recognized (*, ?, [ ]). (Currently there is no provi-
sion for escaping these.)
Select all
Select all items in the current directory (except the
parent directory).
Deselect
Deselect all items.
Quit
Terminate xfm.
FOLDER MENU
Operations dealing with directories and the file window.
New...
Create a new directory.
Go to...
Display the specified directory.
Home
Display your home directory.
Up
Display the parent directory.
Empty
Delete all items in the current directory.
Close
Close this file window.
VIEW MENU
Options for the directory display.
Tree
Select the tree form display.
Icons
Select the icons form display.
Text
Select the text form display.
Sort by name
Sort directory by name.
Sort by size
Sort directory by size.
Sort by date
Sort directory by date.
Filter...
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 fil-
tered. The Clear button in the Filter dialog form
reverts to the full display.)
Hide folders
Suppress directory items.
Mix folders/files
Mix directories and other files.
Show hidden files
Show hidden files (files starting with a dot).
FILE POPUP MENU
Operations on a single file. This menu pops up when press-
ing 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).
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 applica-
tion window.
Delete
Delete the selected items from the application window.
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.
RESOURCES
Various aspects of xfm can be configured by changing
corresponding resource settings in the application
defaults file. Some important resources are listed below:
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 per-
form automatic folder updates. Default: 10000.
confirmXXX
Resources to request confirmation for various opera-
tions. 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 edi-
tor.
defaultViewer
The command with which xfm invokes your favorite
viewer.
BourneShells
xfm calls other programs by executing your shell (as
taken from the environment variable 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 spe-
cial string AUTO, a quick-and-dirty test is done at
startup. This test will fail if the shell's initiali-
sation 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.
CONFIGURATION
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 appli-
cation 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 com-
ment; empty lines are ignored.
FILE TYPE CONFIGURATION
The xfmrc file specifies the types of ordinary (non-exe-
cutable, 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 avail-
able 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 com-
mand 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 sys-
tems.)
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 (spe-
cific 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 use-
ful with application entries than with file actions, and
will therefore be described in the context of application
configuration, see PARAMETER DIALOGS below.
MAGIC HEADERS
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 match-
ing. (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 spe-
cial 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::
DEVICE CONFIGURATION
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 cor-
responding 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 correspond-
ing 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 corre-
sponding 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 sys-
tem may vary from system to system, and you might have to
take special actions if you want to use mount as an ordi-
nary user. See mount(8) for details.
APPLICATION FILES
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 understand-
ing 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 applica-
tion 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 dif-
ferent 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 manipu-
late 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 applica-
tion 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, respec-
tively:
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.
PARAMETER DIALOGS
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. Cur-
rently, no checking is done on the supplied parameters; in
fact, the user can simply leave all fields empty. Parame-
ters 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 possi-
ble 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% $*
CONSOLE OUTPUT
Programs started by xfm inherit their standard output and
error streams from xfm. Therefore, if you start xfm from
your session or window manager instead of an xterm, you
should redirect xfm's standard output and error to some-
thing which you can read while xfm is running, if the win-
dow manager does not already do that for you. Usually, you
will reassign both stdout and stderr to /dev/console,
using the command:
xfm >/dev/console 2>&1
Then you can read error messages and other output produced
by launched applications in the console window on your
desktop (such as xconsole, or xterm -C).
ICONS
Xfm supports icons in both the X bitmap and Arnaud Le
Hors' XPM format. A collection of useful icons is
included in the distribution.
FILES
~/.xfm
Standard location for xfm configuration and applica-
tion files (see CONFIGURATION above).
SEE ALSO
xfmtype(1) X(1) xconsole(1) xterm(1) magic(5)
mount(8) Arnaud Le Hors: XPM Manual. The X PixMap Format,
Groupe Bull, 1993.
CAVEATS AND BUGS
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 nec-
essary to explicitly quit xfm or manually close file win-
dows 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.
COPYRIGHT
Copyright (c) 1990-1993 by Simon Marlow
Copyright (c) 1994, 1995 by Albert Graef
AUTHORS
The original version of this program was written by Simon
Marlow simonm@dcs.glasgow.ac.uk at the University of
Glasgow. Albert Graef (ag@muwiinfa.geschichte.uni-
mainz.de) at the University of Mainz is the author and
maintainer of the present (1.3) version which contains
many bug fixes and enhancements. Other people have con-
tributed additional features: Dave Safford (dave.saf-
ford@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).