This is Info file git.info, produced by Makeinfo version 1.67 from the
input file ./git.texinfo.

START-INFO-DIR-ENTRY
* GIT: (git).         GNU Interactive Tools
END-INFO-DIR-ENTRY

   GIT: A set of interactive tools, by Tudor Hulubei and Andrei Pitis.

   This file documents the GNU Interactive Tools package.

   Copyright (C) 1993-1998 Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that this permission notice may be stated in a
translation approved by the Foundation.


File: git.info,  Node: Refreshing,  Next: Reseting,  Prev: Locking,  Up: git

Refreshing the screen contents
------------------------------

   Sometimes your screen needs to be refreshed.  Just think about what
happens when somebody wants to talk with you and the talk daemon writes
something like this

     Message from Talk_Daemon@galei.cs.vu.nl at 12:15 ...
     talk: connection requested by andrei@galei.cs.vu.nl.
     talk: respond with:  talk andrei@galei.cs.vu.nl

on your screen.  And sometimes you might also want to re-read the
current directories.  `git' provides some built-in commands for
refreshing the screen contents.

`^L'
     Re-read the directories contents and refresh the screen (`refresh').


File: git.info,  Node: Reseting,  Next: Mounting,  Prev: Refreshing,  Up: git

Reseting your terminal
----------------------

`^X ^L'
     Call `reset' in order to reset the terminal to its default
     settings (`TTY-RESET').


File: git.info,  Node: Mounting,  Next: Sysinfo,  Prev: Reseting,  Up: git

Mounting/unmounting file systems
--------------------------------

   People dealing with lots of files usually need to save/restore/copy
files from/to other file systems.  In order to be more efficient, `git'
provides a set of key bindings for mounting and unmounting file
systems.  *Note gitmount::, for more information.

   The default key bindings set has been designed to work under
`Linux', but it can be easily changed for other `UNIX' systems with
different device names.  Reading the configuration file `.gitrc.common'
should be enough.  *Note Hot Keys::, for more information.

   As a convention, the `/mnt' directory is used to store an empty
subdirectory for each mountable file system.  Each file system is
actually mounted in its counterpart `/mnt' subdirectory. Try to follow
this convention since the `gitmount' script is heavily based on it.
*Note Customization::, for more information.

`ESC m a'
     Call `mount'(1) in order to mount the first floppy
     (`/dev/fd0') in the `/mnt/fd0' directory (`MOUNT-A').

`ESC m b'
     Call `mount'(1) in order to mount the second floppy
     (`/dev/fd1') in the `/mnt/fd1' directory (`MOUNT-B').

`ESC m c'
     Call `mount'(1) in order to mount the cdrom
     (`/dev/cdrom') in the `/mnt/cdrom' directory (`MOUNT-CDROM').

`ESC m z'
     Call `mount'(1) in order to mount the zip drive
     (`/dev/zip') in the `/mnt/zip' directory (`MOUNT-ZIP').

`ESC m j'
     Call `mount'(1) in order to mount the jaz drive
     (`/dev/jaz') in the `/mnt/jaz' directory (`MOUNT-JAZ').

`ESC m t'
     Call `mount'(1) in order to mount the file systems corresponding to
     the selected subdirectories.  For example, if you are in the `/mnt'
     directory and the `cdrom' and `zip' subdirectories are
     selected, the cdrom and the zip disk will be mounted (`MOUNT-THESE').

`ESC r a'
     Call `umount'(1) in order to remove (unmount) the first floppy
     (`/dev/fd0') (`UMOUNT-A').

`ESC r b'
     Call `umount'(1) in order to remove (unmount) the second floppy
     (`/dev/fd1') (`UMOUNT-B').

`ESC r c'
     Call `umount'(1) in order to remove (unmount) the cdrom
     (`/dev/cdrom') (`UMOUNT-CDROM').
   findex UMOUNT-CDROM

`ESC r z'
     Call `umount'(1) in order to remove (unmount) the zip drive
     (`/dev/zip') (`UMOUNT-ZIP').

`ESC r j'
     Call `umount'(1) in order to remove (unmount) the jaz drive
     (`/dev/jaz') (`UMOUNT-JAZ').

`ESC r t'
     Call `umount'(1) in order to remove (unmount) the file systems
     mounted into the selected subdirectories. For example, if the current
     directory is `/mnt' and the `cdrom' and `zip'
     subdirectories are selected, the cdrom and the zip disk will be
     unmounted (`UMOUNT-THESE').


File: git.info,  Node: Sysinfo,  Next: Environment,  Prev: Mounting,  Up: git

Getting some useful system information
--------------------------------------

`^X T'
     Call `date'(1) in order to display the current time/date
     (`DATE').

`ESC S f'
     Call `finger'(1) in order to display information about local and
     remote users  (`FINGER').

`ESC S m'
     Call `mount'(1) in order to display a list of the currently
     mounted file systems (`MOUNTED-FILE-SYSTEMS').

`ESC S q'
     Call `quota'(1) in order to display a user file system disk quota
     and quota (`QUOTA').

`ESC S s'
     Call `df'(1) in order to get the status of the currently mounted
     file systems (`DISK-FREE-SPACE').

`ESC S u'
     Call `users'(1) in order to get the name of the currently logged in
     users (`USERS').

`ESC S v'
     Call `$GIT_VMSTAT'(1) in order to get the current virtual memory
     status.  This is very system dependent, `Linux' uses `free',
     other systems use `vmstat', so the $GIT_VMSTAT variable is
     used to deal with this (`VIRTUAL-MEMORY-STATUS').
   *Note Environment Variables::, for more information.

`ESC S w'
     Call `who'(1) in order to find out who is on the system
     (`WHO').


File: git.info,  Node: Environment,  Next: Processes,  Prev: Sysinfo,  Up: git

How to look at the environment variables
----------------------------------------

`^X E'
     Call `env'(1) in order to display the current environment
     (`ENV').

`^X H'
     Call `xhost'(1) in order to add/remove hosts names to the list
     allowed to make connection to the X server (`XHOST').


File: git.info,  Node: Processes,  Next: Sync,  Prev: Environment,  Up: git

Viewing/killing processes
-------------------------

   There are at least two kinds of `ps'(1) utilities.  One that accepts
(more or less) combinations of the 'a', 'u', and 'x' flags and another
that accepts combinations of 'e', 'f' and 'l' flags.  Since is quite
difficult to test which one works fine on a given `UNIX' system, `git'
provides key bindings for both of them.  Anyway, if your `ps'(1) fails
to accept the predefined combinations, please take a look in its manual
and then modify the `.gitrc.TERM' file as needed.

   Since the number of possible combinations of flags in the `ps'
command line is quite big and *very* system dependent, there is no real
reason to display them all here.  We are only interested in giving you
a starting point in your search through the `.gitrc.TERM' file.

   Note also that you can display a list of processes using `ps'(1) or
browse through a list of them (killing as needed) using `gitps'.  As a
convention, we have used the same key sequence for a given set of
`ps'(1) flags for both `ps'(1) and `gitps', the only difference being
that `ps'(1) keys end in an uppercase letter.  *Note gitps::, for more
information.

   Under Linux it is possible to see a tree of processes using
`pstree'(1).

   Here there are the default key bindings for the 'e', 'f' and 'l'
`ps'(1) flags combinations:

`ESC P b', `ESC P c', `ESC P e'
     Call `gitps' or `ps'(1) in order to browse through or display
     a list of currently running processes (`GITPS', `PS').

... and the default key bindings for the 'a', 'u' and 'x' `ps'(1) flags
combinations:

`ESC P a', `ESC P l', `ESC P u' `ESC P x', `ESC P y'
     Call `gitps' or `ps'(1) in order to browse through or display
     a list of currently running processes (`GITPS', `PS').

`ESC P T'
     Call `pstree'(1) in order to displat the tree of currently running
     processes (`PSTREE').

`^X k'
     Call `kill'(1) in order to kill a user specified process with a
     given signal (`KILL').


File: git.info,  Node: Sync,  Next: Documentation,  Prev: Processes,  Up: git

Synchronizing the file systems
------------------------------

`^X S'
     Call `sync'(1) in order to synchronize all the file systems
     (`SYNC').


File: git.info,  Node: Documentation,  Next: Exit,  Prev: Sync,  Up: git

Reading the documentation
-------------------------

`^X q'
     Read a manual page. The user is prompted for its name (`MAN').

`F1', `ESC 1', `^X i'
     Read an info documentation. The user is prompted for the documentation
     name (`INFO').

`^X h'
     Read the html documentation (`HTML').


File: git.info,  Node: Exit,  Prev: Documentation,  Up: git

Exiting GNU Interactive Tools
-----------------------------

`F10', `ESC 0', `^X ^C', `^X c'
     Exit GNU Interactive Tools (`exit').


File: git.info,  Node: gitps,  Next: gitview,  Prev: git,  Up: Description

The GIT process viewer/killer
=============================

   `gitps' is an interactive process viewer/killer.  It calls
internally the `ps'(1) utility.  This is a brief description of the
command line arguments.

`-h'         print this help message

`-v'         print the version number

`-i'         print the installation directory

`-c'         use ANSI colors

`-b'         don't use ANSI colors

`-l'         don't use the last screen character

`-p'         pass the remaining arguments to ps(1)

   Running `gitps' it is self explanatory.  Use the `arrows', `PageUp',
`PageDown', `Home', `End', `^N', `^P', `^V', `ESC v' to move in the
list, `^L' to refresh it and `F10' or `^X ^C' to leave.

   You can change these keys, just read the GITPS-Setup, GITPS-Color,
GITPS-Monochrome and GITPS-Keys sections in the configuration files
`.gitrc.TERM'.


File: git.info,  Node: gitview,  Next: gitkeys,  Prev: gitps,  Up: Description

The GIT ASCII/HEX file viewer
=============================

   `gitview' is an ASCII/HEX file viewer.  Use the `arrows', `PageUp',
`PageDown', `Home', `End', `^N', `^P', `^V', `ESC v' to move in the
file, `^L' to refresh the screen and `F10' or `^X ^C' to leave.

   You can change these keys, just read the GITVIEW-Setup,
GITVIEW-Color, GITVIEW-Monochrome and GITVIEW-Keys sections in the
configuration files `.gitrc.TERM'.

   Here is a brief description of the command line arguments:

`-h'         print this help message

`-v'         print the version number

`-i'         print the installation directory

`-c'         use ANSI colors

`-b'         don't use ANSI colors

`-l'         don't use the last screen character


File: git.info,  Node: gitkeys,  Next: gitwipe,  Prev: gitview,  Up: Description

The GIT key sequences display utility
=====================================

   `gitkeys' is a program that displays the key sequence sent by the
pressed key.  This is the key sequence received by `GIT' tools, so this
program is useful when setting up the `.gitrc.TERM' configuration files.


File: git.info,  Node: gitwipe,  Next: gitmount,  Prev: gitkeys,  Up: Description

The GIT wipe file utility
=========================

   `gitwipe' is an utility for wiping files. It overwrites the file
contents with a random sequence of numbers and then calls `sync'().

   Note that `gitwipe' does *not* delete the file since (under `Linux'
at least) the `sync'() system call might return before actually writing
the new file contents to disk.  Deleting the file might be dangerous
because some file systems can detect that the blocks in the file are no
longer used and never write them back to disk in order to improve
performance.  It is up to you to delete the file(s) at a later moment.


File: git.info,  Node: gitmount,  Next: gitaction,  Prev: gitwipe,  Up: Description

The GIT mount utility
=====================

   `gitmount' is a script that allows you to mount a list of block
devices (specified in the command line), without specifying the file
system type.  With a command like `gitmount fd0 cdrom' the first floppy
will be mounted in `/mnt/fd0' and the cdrom will be mounted in
`/mnt/cdrom'.  Make sure your `/etc/fstab' settings are correct.

   You don't need to know the file system type anymore.  If you want to
use `gitmount' with the block device `/dev/xxx' then the directory
`/mnt/xxx' must exist.  `gitmount' will attempt to create the necessary
directories, but root permissions might be required.


File: git.info,  Node: gitaction,  Next: gitunpack,  Prev: gitmount,  Up: Description

The GIT per file type action script
===================================

   `gitaction' is a script that executes a different action for each
file type specified.  It is called by the `git' program when pressing
`F2', `ESC 2' or `^Xa'.

   The first parameter is the current directory name and the second one
is the file name to be matched against the default patterns.  The
matching is done using the shell 'case' statement.

   If you press `F2', `ESC 2' or `^Xa' on a `*.c' file, `git' will
compile it, if you press `F2', `ESC 2' or `^Xa' on a `*.tar.gz' file,
`git' will list the tar archive contents, if you press the same keys on
a `*.gz' file, `git' will display its uncompressed contents on the
screen, etc ...

   If you want to find out what the default action for each file type is
(or if you want to modify it), just read/modify the `gitaction' script.
If no pattern is found, the file is displayed using `more'.

   If you press `F2', `ESC 2' or `^Xa' on a `*.gif' file or `*.jpg'
file and you have the `zgv' utility installed, you will be able to see
it.  If you want to change the gif/jpeg viewer, all you need to do is
to change its name in the `gitaction' script.

   Also, you can add a `.gitaction' shell script in your home directory
and/or in any other directory.  Before trying to match a file name,
`gitaction' will attempt to execute `./.gitaction'.  If that one fails
to match the file name against its patterns, it backs up to
`$HOME/.gitaction'.  When this one fails too the patterns in
`gitaction' are tried.  For an example of how to write .gitaction
scripts take a look at the `.gitaction' shell script provided as part
of the distribution and installed in the `$(prefix)/bin' directory.


File: git.info,  Node: gitunpack,  Next: gitrgrep,  Prev: gitaction,  Up: Description

Unified archive unpacking
=========================

   `gitunpack' is a shell script that accepts a directory and a set of
archives as its command line parameters, and then attempts to unpack
those archives in the given directory, selecting the utility used to
unpack the archives based on the archive extensions.


File: git.info,  Node: gitrgrep,  Prev: gitunpack,  Up: Description

The GIT recursive grep script
=============================

   `gitrgrep' is a very small script that calls `grep' recursively.  It
accepts `grep' like options / parameters, the only difference being
that file specifications should be quoted:

     	`gitrgrep' main '*.c'
     
     or
     
     	`gitrgrep' errno '*.c *.h'

   `gitregrep' and `gitrfgrep' are recursive versions of the egrep and
fgrep programs.


File: git.info,  Node: Customization,  Next: Limitations,  Prev: Description,  Up: Top

Customizing GNU Interactive Tools
*********************************

* Menu:

* Environment Variables::       Environment variables used by GIT
* Configuration Files::         GIT's configuration files


File: git.info,  Node: Environment Variables,  Next: Configuration Files,  Up: Customization

Environment Variables
=====================

   The configuration files use shell environment variables to call the
shell, editor, mail reader, compress and virtual memory status utility.
That means that if you set GIT_SHELL, GIT_EDITOR, GIT_RMAIL, or
GIT_VMSTAT to some value, that value will be used instead of the
default one.  The defaults are:

     	GIT_SHELL='/bin/sh'
     	GIT_EDITOR='vi'
     	GIT_RMAIL='emacs -f rmail'
     	GIT_PAGER='more'
     	GIT_VMSTAT='free'

   If SHELL is defined, GIT_SHELL will be set to that value.  If EDITOR
is defined, GIT_EDITOR will be set to that value.  If you want to
change the default settings, put something like this into your
`.profile':

     	export GIT_SHELL='/usr/local/bin/bash'
     	export GIT_EDITOR='emacs'
     	export GIT_RMAIL='elm'
     	export GIT_PAGER='less'
     	export GIT_VMSTAT='vmstat'


File: git.info,  Node: Configuration Files,  Prev: Environment Variables,  Up: Customization

Configuration Files
===================

   There is one configuration file per terminal type in `GIT'.  The
configuration file(s) reside in the user's home directory or (the
default versions) in the directory `$(prefix)/lib' (usually
`/usr/local/lib').

   Their generic name is `.gitrc.TERM'.  `GIT' allows each terminal
type to have its own configuration file (TERM is the value of the TERM
environment variable (e.g `vt102'); for the `Linux' console the
configuration file is `.gitrc.console').

   Since most of the key bindings are common to all the terminal types,
a configuration file called `.gitrc.common' is parsed before parsing
the normal `.gitrc.TERM' configuration file, the later one defining
only those keys that are terminal specific.  However, if a key binding
is redefined in the `.gitrc.TERM' file, that binding will be used.

   If the `GIT' package have been compiled without passing the
`--enable-terminfo' option to the `configure' script and your system
has a huge `termcap' database (`/etc/termcap'), you can copy the
termcap definition(s) of your terminal(s) in a file called, lets say
`.termcap' and put it in your home directory.  After that, set your
TERMCAP environment variable to point to it.  You should add something
like this to your `.profile':

     TERMCAP=`/home/mike/.termcap'

   The interactive programs in the `GIT' package can run without such a
file, but on systems with huge `termcap' databases, copying the
definitions of the most used terminals in a local `.termcap' file will
lead to a faster start.

   The `.gitrc.TERM' it is first time searched in the home directory
then, if not found, in the directory `$(prefix)/lib' (usually
`/usr/local/lib'). The configuration file is structured on sections,
each section containing variables in the following format:

     	`variable-name' = `first-field';`second-field'; ...

   After the `variable-name' at least one space or tab is required.
All characters after a `#' are ignored and if you comment a section
name, the whole section is ignored.

   Section names are enclosed in rectangular brackets (`[' and `]').
Note that this manual don't include them while refering to section
names.

   The `GIT' package contains three major programs: `git', `gitps' and
`gitview'.  Each one has its own sections in the configuration files.
There is also a global setup section called `Setup' that is used by all
these programs.

* Menu:

* Key Sequences::               How to write a key sequence.

* Setup::                       The global setup section.

* git Sections::                git's sections.
* gitps Sections::              gitps's Sections.
* gitview Sections::            gitview's Sections.


File: git.info,  Node: Key Sequences,  Next: Setup,  Up: Configuration Files

Writing key sequences
---------------------

   `GIT' contains three interactive programs.  Their names are: `git'
(this is the file system browser), `gitps' (this is the process
viewer/killer and `gitview' (this is the ASCII/HEX file viewer).  Each
one of these programs has its own set of key bindings.

   The convention used in describing key bindings are very simple.  Here
there are some examples that will help you to understand them.  The
corresponding `Emacs' conventions will help you even more.

   `^A' means keeping the Ctrl key down and pressing the `a' key
(`C-a').

   The `ESC' character is represented as `^[' so that you can use the
meta character (`M-' ) where available (or the `ESC' key):

   `^[a' corresponds to `M-a' (pressing the `ESC' key and then `a').

   The `^' character is represented as `^^'.

   The `backspace' character is represented as `^_'.

   The `Ctrl-SPACE' character (`C-SPC') is represented as `^$'.

   The space (`SPC') character is represented as `^@'.

   Note that the key bindings notation described here is only used in
the configuration files.  For the sake of readability this manual uses
`ESC' for the `ESC' key, `SPC' for the `SPACE' key and `RET' for the
`RETURN' (`ENTER') key.


File: git.info,  Node: Setup,  Next: git Sections,  Prev: Key Sequences,  Up: Configuration Files

The global setup section
------------------------

   In this section the variables have only one field.

`AnsiColors'

   This variable should be set to `ON' if the terminal supports
standard `ANSI' color sequences.  Otherwise it should be `OFF'.  If
`AnsiColors' is `ON', `GITxxx-Color' sections will be used in the
configuration files `.gitrc.TERM'.  Otherwise, `GIT' interactive
programs will use the `GITxxx-Monochrome' sections.

`UseLastScreenChar'

   This variable is used for terminals that can't write on the last
character of the screen without scrolling the entire screen.  If your
terminal has no problem writing there (`Linux' console, vt100, vt102,
xterm, ...)  set it to `ON'.  Otherwise (hpterm), it should be `OFF'.

`StartupScrollStep'

   This variable specifies the scroll step initial value for both
panels.


File: git.info,  Node: git Sections,  Next: gitps Sections,  Prev: Setup,  Up: Configuration Files

git Sections
------------

* Menu:

* GIT-Setup::                   git's setup section.
* GIT-Color::                   git's color section.
* GIT-Monochrome::              git's monochrome section.
* GIT-Keys::                    git's keys section.
* GIT-FTI::                     git's file type information section.


File: git.info,  Node: GIT-Setup,  Next: GIT-Color,  Up: git Sections

git Setup
.........

   In this section the variables have only one field.

`StartupFileDisplayMode'

   This variable specifies the file specific information displayed at
startup.  It can be any of `OwnerGroup', `DateTime', `Size', `Mode' or
`FullName'.  Its value initially affects both panels but it can be
changed separately afterward.

`StartupFileSortMethod'

   This variable specifies the startup sort method.  It can be any of
`Name', `Extension', `Size', `Date', `Mode', `OwnerId', `GroupId',
`OwnerName' or `GroupName'.  Its value initially affects both panels
but it can be changed separately afterward.

`ConfirmOnExit'

   If this variable is `ON', the user is prompted for confirmation at
exit.

`HistoryFile'

   This variable specifies the history file name.  The default value is
`~/.githistory'.

`InfoDisplay'

   If this variable is `OFF', auxiliary file informations are not
displayed.  This can be useful if you are using a very slow terminal.

`LeadingDotMatch'

   If this variable is `OFF' when matching files for
select-files-matching-pattern / unselect-files-matching-pattern then the
leading '.' in the file name is matched only explicitly.

`TypeSensitivity'

   If this variable is `OFF', colors are not used when displaying
files.  Normally, the information in the `GIT-FTI' section is used to
display files with different colors, depending on their types.  Note
that `TypeSensitivity' is automatically set to `OFF' when `AnsiColors'
is `OFF'.  *Note GIT-FTI::, for mor information.

`NormalModeHelp'

`CommandLineModeHelp'

   These variables describe the status bar contents for each `git' mode
when no errors occurred.  `git' can display on the status bar a help
string and/or some system information (system type, hostname, machine
type and the current date) using escape characters:

     	\s      ->      the system type
     	\h      ->      the host name
     	\m      ->      the machine type
     	\d      ->      the current date
   *Note Modes::, for more information.


File: git.info,  Node: GIT-Color,  Next: GIT-Monochrome,  Prev: GIT-Setup,  Up: git Sections

Using git on colors displays
............................

   In this sections the variables have only one field.

   These section allows you to customize the colors of `git'.  Reading
the `.gitrc.TERM' configuration file is self explanatory.


File: git.info,  Node: GIT-Monochrome,  Next: GIT-Keys,  Prev: GIT-Color,  Up: git Sections

Using git on monochrome displays
................................

   In this sections the variables have only one field.

   These section allows you to customize the appearance of `git' on
monochrome displays. Reading the `.gitrc.TERM' configuration file is
self explanatory.


File: git.info,  Node: GIT-Keys,  Next: GIT-FTI,  Prev: GIT-Monochrome,  Up: git Sections

Defining keys
.............

   These section describes the actions `git' takes when a specified key
is pressed.  A variable can have up to 6 fields separated by ';'.  Each
line in this section looks like:

     `key-sequence' = `command-name';`formatted-command';`new-dir';
     	       `save-screen';`pause';`hide'

   Note that you can't continue the variable fields description on the
next line.

* Menu:

* key-sequence::                The key-sequence field.
* command-name::                The command-name field.
* formatted-command::           The formatted-command field.
* new-dir::                     The new-dir field.
* save-screen::                 The save-screen field.
* pause::                       The pause field.
* hide::                        The hide field.


File: git.info,  Node: key-sequence,  Next: command-name,  Up: GIT-Keys

The key-sequence field
......................

   `key-sequence' is the key sequence associated with the given
command.  You can use any key sequence that doesn't start with an ascii
character (0x20 to 0x7e).

   Symbolic key names (`F0', `F1', `F2', ... `F10', `UP', `DOWN',
`RIGHT', `LEFT', `INS', `DEL', `HOME', `END', `PGUP' and `PGDOWN') can
be used instead of the key sequence.  If some keys don't have a
`termcap'/ `terminfo' description (like the `F11'/`F12' keys on the
`Linux' console) you can specify the key sequence in the usual way.


File: git.info,  Node: command-name,  Next: formatted-command,  Prev: key-sequence,  Up: GIT-Keys

The command-name field
......................

   `command-name' is a command generic name.  Even if it is not always
used, the `command-name' must be present (if a command is associated
with a `key-sequence').  If it is not, no action will be taken when
pressing `key-sequence'.

   There are two types of commands in `git': built-in commands and user
defined commands.  If the `command-name' section contains a built-in
command specification, the other fields are ignored.

   Note that by convention built-in command names contain only lower
case letters while user defined command names contain only upper case
letters.


File: git.info,  Node: formatted-command,  Next: new-dir,  Prev: command-name,  Up: GIT-Keys

The formatted-command field
...........................

   - `formatted-command' is a shell command which can contain some
scanf like format specifiers.  They are used to get the current entry
name, owner, group, mode, etc.

   Note that using uppercase `format specifiers' you will be able to
access the other panel path, file and directory names, etc.

   These are the available `format specifiers':

* Menu:

* %s::                          The %s format specifier.
* %f::                          The %f format specifier.
* %d::                          The %d format specifier.
* %l::                          The %l format specifier.
* %t::                          The %t format specifier.
* %z::                          The %z format specifier.
* %a::                          The %a format specifier.
* %m::                          The %m format specifier.
* %g::                          The %g format specifier.
* %o::                          The %o format specifier.
* %p::                          The %p format specifier.
* %b::                          The %b format specifier.
* %i::                          The %i format specifier.
* %?::                          The %? format specifier.


File: git.info,  Node: %s,  Next: %f,  Up: formatted-command

The %s format specifier
.......................

   The format of %s is:  %s{question,default_answer}.

   When `git' encounters a %s in the `formatted-command' it asks the
user the question `question' whose default answer is `default_answer'
and replaces the `%s{ , }' with the user's answer.  Both `question' and
`default_answer' can contain any other `format specifiers' except %s.

   Note that there should be no spaces between %s and '{'.


File: git.info,  Node: %f,  Next: %d,  Prev: %s,  Up: formatted-command

The %f format specifier
.......................

   `git' will replace %f with the current directory entry name only if
it is a file (not a directory).


File: git.info,  Node: %d,  Next: %l,  Prev: %f,  Up: formatted-command

The %d format specifier
.......................

   `git' will replace %d with the current directory entry name only if
it is a directory (not a file).


File: git.info,  Node: %l,  Next: %t,  Prev: %d,  Up: formatted-command

The %l format specifier
.......................

   `git' will replace %l with the current directory entry name only if
it is a symbolic link with no target.


File: git.info,  Node: %t,  Next: %z,  Prev: %l,  Up: formatted-command

The %t format specifier
.......................

   `git' will replace %t with the current directory entry name only if
it is a named pipe.


File: git.info,  Node: %z,  Next: %a,  Prev: %t,  Up: formatted-command

The %z format specifier
.......................

   `git' will replace %z with the current directory entry name only if
it is a socket.


File: git.info,  Node: %a,  Next: %m,  Prev: %z,  Up: formatted-command

The %a format specifier
.......................

   `git' will always replace %a with the current directory entry name.


File: git.info,  Node: %m,  Next: %g,  Prev: %a,  Up: formatted-command

The %m format specifier
.......................

   `git' will always replace %m with the current file mode.


File: git.info,  Node: %g,  Next: %o,  Prev: %m,  Up: formatted-command

The %g format specifier
.......................

   `git' will always replace %g with the current file group.


File: git.info,  Node: %o,  Next: %p,  Prev: %g,  Up: formatted-command

The %o format specifier
.......................

   `git' will always replace %o with the current file owner.


File: git.info,  Node: %p,  Next: %b,  Prev: %o,  Up: formatted-command

The %p format specifier
.......................

   `git' will always replace %p with the current panel path.


File: git.info,  Node: %b,  Next: %i,  Prev: %p,  Up: formatted-command

The %b format specifier
.......................

   `git' will always replace %b with the current panel directory name.


File: git.info,  Node: %i,  Next: %?,  Prev: %b,  Up: formatted-command

The %i format specifier
.......................

   `git' will always replace %i with all the current panel selected
entry names.


File: git.info,  Node: %?,  Prev: %i,  Up: formatted-command

The %? format specifier
.......................

   The format of %? is: %?{confirmation}.

   `git' uses this format specifier only to ask for confirmation before
expanding / executing the current command.  The `confirmation' string
is displayed and, if the user doesn't confirm, the command is aborted.
Otherwise, %?{confirmation} expands to a null string and the command is
expanded / executed normally.


File: git.info,  Node: new-dir,  Next: save-screen,  Prev: formatted-command,  Up: GIT-Keys

The new-dir field
.................

   If the `formatted-command' successfully exits (exit code = 0) or it
has no body and this field is present then `new-dir' will become the
current panel directory.

   The character '~' used at the beginning of the `new-dir' field is
replaced by the user's home directory.


File: git.info,  Node: save-screen,  Next: pause,  Prev: new-dir,  Up: GIT-Keys

The save-screen field
.....................

   This field is a character (usually 'y' or 'n') that tells `git' to
save ('y') or not to save ('n') the terminal's screen after executing
the `formatted-command'.  Saving the screen is not necessary while
editing or viewing a file because the information left after the editor
or the viewer exits is not important.  Saving the screen means that that
screen will be restored before the execution of the next command.
Currently this field is used only if you are working as a super user
under `Linux' on a virtual console.  Its default value is 'y'.


File: git.info,  Node: pause,  Next: hide,  Prev: save-screen,  Up: GIT-Keys

The pause field
...............

   Users may wish to read some commands's results before repainting the
panels.  If this field is present git will wait for a key to be pressed
before restoring the panels.  Its default value is 'n'.


File: git.info,  Node: hide,  Prev: pause,  Up: GIT-Keys

The hide field
..............

   Some commands that don't displaying any useful information if
successfully complete their execution: `mount', `chmod', `chown',
`chgrp', `sync' ... and, if an error occurs, a line or two are sent to
stderr.  If this option is 'y', the stdout and stderr will be
redirected to some files (`git.1.pid' and `git.2.pid', where pid is
`git''s pid) and only if the command's exit code is not 0, the
`git.2.pid' file will be displayed, line by line, onto the status bar.
This way the panels will not be deleted and then repainted and the
command appears to be built-in.  `git.1.pid' and `git.2.pid' are
created in the temporary directory specified in the `TMPDIR'
environment variable (or "/tmp" if `TMPDIR' is not defined).  The
default value of the `hide' field is 'n'.


File: git.info,  Node: GIT-FTI,  Prev: GIT-Keys,  Up: git Sections

Setting up colors for different file types
------------------------------------------

   This sections contains entries of the form:

     `pattern' = `foreground'; `background'; `brightness'

where `pattern' is a file name matching pattern, `foreground',
`background' and `brightness' are the color specification to be used
when a file whose name match the given `pattern' is displayed in a
panel.  Colors can be turned off using the `TypeSensitivity' variable
in the `GIT-Setup' seection.


File: git.info,  Node: gitps Sections,  Next: gitview Sections,  Prev: git Sections,  Up: Configuration Files

gitps Sections
--------------

* Menu:

* GITPS-Setup::                 gitps's setup section.
* GITPS-Color::                 gitps's color section.
* GITPS-Monochrome::            gitps's monochrome section.
* GITPS-Keys::                  gitps's keys section.


File: git.info,  Node: GITPS-Setup,  Next: GITPS-Color,  Up: gitps Sections

gitps Setup
...........

   In this section the variables have only one field.

`Help'

   This variable describe `gitps''s status bar contents.


File: git.info,  Node: GITPS-Color,  Next: GITPS-Monochrome,  Prev: GITPS-Setup,  Up: gitps Sections

Using gitps on color displays
.............................

   In this sections the variables have only one field.

   These section allows you to customize the colors of `gitps'.
Reading the `.gitrc.TERM' configuration file is self explanatory.


File: git.info,  Node: GITPS-Monochrome,  Next: GITPS-Keys,  Prev: GITPS-Color,  Up: gitps Sections

Using gitps on monochrome displays
..................................

   In this sections the variables have only one field.

   These section allows you to customize the appearance of `gitps' on
monochrome displays. Reading the `.gitrc.TERM' configuration file is
self explanatory.


File: git.info,  Node: GITPS-Keys,  Prev: GITPS-Monochrome,  Up: gitps Sections

Defining keys
.............


File: git.info,  Node: gitview Sections,  Prev: gitps Sections,  Up: Configuration Files

gitview Sections
----------------

* Menu:

* GITVIEW-Setup::               gitview's setup section.
* GITVIEW-Color::               gitview's color section.
* GITVIEW-Monochrome::          gitview's monochrome section.
* GITVIEW-Keys::                gitview's keys section.


File: git.info,  Node: GITVIEW-Setup,  Next: GITVIEW-Color,  Up: gitview Sections

gitview Setup
.............

   In this section the variables have only one field.

`Help'

   This variable describe `gitps''s status bar contents.


File: git.info,  Node: GITVIEW-Color,  Next: GITVIEW-Monochrome,  Prev: GITVIEW-Setup,  Up: gitview Sections

Using gitview on color displays
...............................

   In this sections the variables have only one field.

   These section allows you to customize the colors of `gitview'.
Reading the `.gitrc.TERM' configuration file is self explanatory.


File: git.info,  Node: GITVIEW-Monochrome,  Next: GITVIEW-Keys,  Prev: GITVIEW-Color,  Up: gitview Sections

Using gitview on monochrome displays
....................................

   In this sections the variables have only one field.

   These section allows you to customize the appearance of `gitview' on
monochrome displays. Reading the `.gitrc.TERM' configuration file is
self explanatory.


File: git.info,  Node: GITVIEW-Keys,  Prev: GITVIEW-Monochrome,  Up: gitview Sections

Defining keys
.............


File: git.info,  Node: Limitations,  Next: Bugs,  Prev: Customization,  Up: Top

GNU Interactive Tools limitations
*********************************

   Background commands (& terminated)can be specified in the
configuration file but their result (stdout and stderr redirection),
will be overwritten by the result of newer commands and, if an error
occurs, it will not be seen.

   When `git' is compiled for `Linux', the default built-in color
descriptions are for color monitors, so you can't (decently) run `git'
on a b/w monitor without the `.gitrc.TERM' file correctly configured.
`.gitrc.TERM' should be configured with `AnsiColors' = OFF.

   Job support is implemented only in `git'.

   Due to the fact that the ';' character is used as a field separator
in the configuration files, you can't write something like that in the
`.gitrc.TERM' files:

   ^AAA = SHOW-USERS-AND-GROUPS; more /etc/passwd; more /etc/group

because 'more /etc/group' will be considered as a directory to switch
to.  You must write a small script instead:

   #! /bin/sh

   more /etc/passwd more /etc/group

   Supposing the script name is `show_ug', the `.gitrc.TERM' line will
look like this:

   ^AAA = SHOW-USERS-AND-GROUPS; show_ug

   There is no support for appearance modes on magic-cookie terminals.


File: git.info,  Node: Bugs,  Prev: Limitations,  Up: Top

GNU Interactive Tools bugs
**************************

   Any questions, comments, or bug reports, should be emailed to `Tudor
Hulubei <tudor@cs.unh.edu>'.  Please include the version number.

