Subversion Repositories or1k

This is gdb.info, produced by makeinfo version 4.1 from ./gdb.texinfo.

INFO-DIR-SECTION Programming & development tools.

START-INFO-DIR-ENTRY

* Gdb: (gdb).                     The GNU debugger.

END-INFO-DIR-ENTRY

   This file documents the GNU debugger GDB.

   This is the Ninth Edition, December 2001, of `Debugging with GDB:

the GNU Source-Level Debugger' for GDB Version 5.3.

   Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996,

1998,

1999, 2000, 2001, 2002 Free Software Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document

under the terms of the GNU Free Documentation License, Version 1.1 or

any later version published by the Free Software Foundation; with the

Invariant Sections being "Free Software" and "Free Software Needs Free

Documentation", with the Front-Cover Texts being "A GNU Manual," and

with the Back-Cover Texts as in (a) below.

   (a) The Free Software Foundation's Back-Cover Text is: "You have

freedom to copy and modify this GNU Manual, like GNU software.  Copies

published by the Free Software Foundation raise funds for GNU

development."

File: gdb.info,  Node: GDB/MI Thread Commands,  Next: GDB/MI Tracepoint Commands,  Prev: GDB/MI Target Manipulation,  Up: GDB/MI

GDB/MI Thread Commands

======================

The `-thread-info' Command

--------------------------

Synopsis

........

      -thread-info

GDB command

...........

   No equivalent.

Example

.......

   N.A.

The `-thread-list-all-threads' Command

--------------------------------------

Synopsis

........

      -thread-list-all-threads

GDB Command

...........

   The equivalent GDB command is `info threads'.

Example

.......

   N.A.

The `-thread-list-ids' Command

------------------------------

Synopsis

........

      -thread-list-ids

   Produces a list of the currently known GDB thread ids.  At the end

of the list it also prints the total number of such threads.

GDB Command

...........

   Part of `info threads' supplies the same information.

Example

.......

   No threads present, besides the main process:

     (gdb)

     -thread-list-ids

     ^done,thread-ids={},number-of-threads="0"

     (gdb)

   Several threads:

     (gdb)

     -thread-list-ids

     ^done,thread-ids={thread-id="3",thread-id="2",thread-id="1"},

     number-of-threads="3"

     (gdb)

The `-thread-select' Command

----------------------------

Synopsis

........

      -thread-select THREADNUM

   Make THREADNUM the current thread.  It prints the number of the new

current thread, and the topmost frame for that thread.

GDB Command

...........

   The corresponding GDB command is `thread'.

Example

.......

     (gdb)

     -exec-next

     ^running

     (gdb)

     *stopped,reason="end-stepping-range",thread-id="2",line="187",

     file="../../../devo/gdb/testsuite/gdb.threads/linux-dp.c"

     (gdb)

     -thread-list-ids

     ^done,

     thread-ids={thread-id="3",thread-id="2",thread-id="1"},

     number-of-threads="3"

     (gdb)

     -thread-select 3

     ^done,new-thread-id="3",

     frame={level="0 ",func="vprintf",

     args=[{name="format",value="0x8048e9c \"%*s%c %d %c\\n\""},

     {name="arg",value="0x2"}],file="vprintf.c",line="31"}

     (gdb)

File: gdb.info,  Node: GDB/MI Tracepoint Commands,  Next: GDB/MI Variable Objects,  Prev: GDB/MI Thread Commands,  Up: GDB/MI

GDB/MI Tracepoint Commands

==========================

   The tracepoint commands are not yet implemented.

File: gdb.info,  Node: GDB/MI Variable Objects,  Prev: GDB/MI Tracepoint Commands,  Up: GDB/MI

GDB/MI Variable Objects

=======================

Motivation for Variable Objects in GDB/MI

-----------------------------------------

   For the implementation of a variable debugger window (locals, watched

expressions, etc.), we are proposing the adaptation of the existing code

used by `Insight'.

   The two main reasons for that are:

  1. It has been proven in practice (it is already on its second

     generation).

  2. It will shorten development time (needless to say how important it

     is now).

   The original interface was designed to be used by Tcl code, so it was

slightly changed so it could be used through GDB/MI.  This section

describes the GDB/MI operations that will be available and gives some

hints about their use.

   _Note_: In addition to the set of operations described here, we

expect the GUI implementation of a variable window to require, at

least, the following operations:

   * `-gdb-show' `output-radix'

   * `-stack-list-arguments'

   * `-stack-list-locals'

   * `-stack-select-frame'

Introduction to Variable Objects in GDB/MI

------------------------------------------

   The basic idea behind variable objects is the creation of a named

object to represent a variable, an expression, a memory location or

even a CPU register.  For each object created, a set of operations is

available for examining or changing its properties.

   Furthermore, complex data types, such as C structures, are

represented in a tree format.  For instance, the `struct' type variable

is the root and the children will represent the struct members.  If a

child is itself of a complex type, it will also have children of its

own.  Appropriate language differences are handled for C, C++ and Java.

   When returning the actual values of the objects, this facility allows

for the individual selection of the display format used in the result

creation.  It can be chosen among: binary, decimal, hexadecimal, octal

and natural.  Natural refers to a default format automatically chosen

based on the variable type (like decimal for an `int', hex for

pointers, etc.).

   The following is the complete set of GDB/MI operations defined to

access this functionality:

*Operation*                   *Description*

`-var-create'                 create a variable object

`-var-delete'                 delete the variable object and its children

`-var-set-format'             set the display format of this variable

`-var-show-format'            show the display format of this variable

`-var-info-num-children'      tells how many children this object has

`-var-list-children'          return a list of the object's children

`-var-info-type'              show the type of this variable object

`-var-info-expression'        print what this variable object represents

`-var-show-attributes'        is this variable editable? does it exist

                              here?

`-var-evaluate-expression'    get the value of this variable

`-var-assign'                 set the value of this variable

`-var-update'                 update the variable and its children

   In the next subsection we describe each operation in detail and

suggest how it can be used.

Description And Use of Operations on Variable Objects

-----------------------------------------------------

The `-var-create' Command

-------------------------

Synopsis

........

      -var-create {NAME | "-"}

         {FRAME-ADDR | "*"} EXPRESSION

   This operation creates a variable object, which allows the

monitoring of a variable, the result of an expression, a memory cell or

a CPU register.

   The NAME parameter is the string by which the object can be

referenced.  It must be unique.  If `-' is specified, the varobj system

will generate a string "varNNNNNN" automatically.  It will be unique

provided that one does not specify NAME on that format.  The command

fails if a duplicate name is found.

   The frame under which the expression should be evaluated can be

specified by FRAME-ADDR.  A `*' indicates that the current frame should

be used.

   EXPRESSION is any expression valid on the current language set (must

not begin with a `*'), or one of the following:

   * `*ADDR', where ADDR is the address of a memory cell

   * `*ADDR-ADDR' -- a memory address range (TBD)

   * `$REGNAME' -- a CPU register name

Result

......

   This operation returns the name, number of children and the type of

the object created.  Type is returned as a string as the ones generated

by the GDB CLI:

      name="NAME",numchild="N",type="TYPE"

The `-var-delete' Command

-------------------------

Synopsis

........

      -var-delete NAME

   Deletes a previously created variable object and all of its children.

   Returns an error if the object NAME is not found.

The `-var-set-format' Command

-----------------------------

Synopsis

........

      -var-set-format NAME FORMAT-SPEC

   Sets the output format for the value of the object NAME to be

FORMAT-SPEC.

   The syntax for the FORMAT-SPEC is as follows:

      FORMAT-SPEC ==>

      {binary | decimal | hexadecimal | octal | natural}

The `-var-show-format' Command

------------------------------

Synopsis

........

      -var-show-format NAME

   Returns the format used to display the value of the object NAME.

      FORMAT ==>

      FORMAT-SPEC

The `-var-info-num-children' Command

------------------------------------

Synopsis

........

      -var-info-num-children NAME

   Returns the number of children of a variable object NAME:

      numchild=N

The `-var-list-children' Command

--------------------------------

Synopsis

........

      -var-list-children NAME

   Returns a list of the children of the specified variable object:

      numchild=N,children={{name=NAME,

      numchild=N,type=TYPE},(repeats N times)}

The `-var-info-type' Command

----------------------------

Synopsis

........

      -var-info-type NAME

   Returns the type of the specified variable NAME.  The type is

returned as a string in the same format as it is output by the GDB CLI:

      type=TYPENAME

The `-var-info-expression' Command

----------------------------------

Synopsis

........

      -var-info-expression NAME

   Returns what is represented by the variable object NAME:

      lang=LANG-SPEC,exp=EXPRESSION

where LANG-SPEC is `{"C" | "C++" | "Java"}'.

The `-var-show-attributes' Command

----------------------------------

Synopsis

........

      -var-show-attributes NAME

   List attributes of the specified variable object NAME:

      status=ATTR [ ( ,ATTR )* ]

where ATTR is `{ { editable | noneditable } | TBD }'.

The `-var-evaluate-expression' Command

--------------------------------------

Synopsis

........

      -var-evaluate-expression NAME

   Evaluates the expression that is represented by the specified

variable object and returns its value as a string in the current format

specified for the object:

      value=VALUE

The `-var-assign' Command

-------------------------

Synopsis

........

      -var-assign NAME EXPRESSION

   Assigns the value of EXPRESSION to the variable object specified by

NAME.  The object must be `editable'.

The `-var-update' Command

-------------------------

Synopsis

........

      -var-update {NAME | "*"}

   Update the value of the variable object NAME by evaluating its

expression after fetching all the new values from memory or registers.

A `*' causes all existing variable objects to be updated.

File: gdb.info,  Node: GDB Bugs,  Next: Formatting Documentation,  Prev: GDB/MI,  Up: Top

Reporting Bugs in GDB

*********************

   Your bug reports play an essential role in making GDB reliable.

   Reporting a bug may help you by bringing a solution to your problem,

or it may not.  But in any case the principal function of a bug report

is to help the entire community by making the next version of GDB work

better.  Bug reports are your contribution to the maintenance of GDB.

   In order for a bug report to serve its purpose, you must include the

information that enables us to fix the bug.

* Menu:

* Bug Criteria::                Have you found a bug?

* Bug Reporting::               How to report bugs

File: gdb.info,  Node: Bug Criteria,  Next: Bug Reporting,  Up: GDB Bugs

Have you found a bug?

=====================

   If you are not sure whether you have found a bug, here are some

guidelines:

   * If the debugger gets a fatal signal, for any input whatever, that

     is a GDB bug.  Reliable debuggers never crash.

   * If GDB produces an error message for valid input, that is a bug.

     (Note that if you're cross debugging, the problem may also be

     somewhere in the connection to the target.)

   * If GDB does not produce an error message for invalid input, that

     is a bug.  However, you should note that your idea of "invalid

     input" might be our idea of "an extension" or "support for

     traditional practice".

   * If you are an experienced user of debugging tools, your suggestions

     for improvement of GDB are welcome in any case.

File: gdb.info,  Node: Bug Reporting,  Prev: Bug Criteria,  Up: GDB Bugs

How to report bugs

==================

   A number of companies and individuals offer support for GNU products.

If you obtained GDB from a support organization, we recommend you

contact that organization first.

   You can find contact information for many support companies and

individuals in the file `etc/SERVICE' in the GNU Emacs distribution.

   In any event, we also recommend that you submit bug reports for GDB.

The prefered method is to submit them directly using GDB's Bugs web

page (http://www.gnu.org/software/gdb/bugs/).  Alternatively, the

e-mail gateway  can be used.

   *Do not send bug reports to `info-gdb', or to `help-gdb', or to any

newsgroups.*  Most users of GDB do not want to receive bug reports.

Those that do have arranged to receive `bug-gdb'.

   The mailing list `bug-gdb' has a newsgroup `gnu.gdb.bug' which

serves as a repeater.  The mailing list and the newsgroup carry exactly

the same messages.  Often people think of posting bug reports to the

newsgroup instead of mailing them.  This appears to work, but it has one

problem which can be crucial: a newsgroup posting often lacks a mail

path back to the sender.  Thus, if we need to ask for more information,

we may be unable to reach you.  For this reason, it is better to send

bug reports to the mailing list.

   The fundamental principle of reporting bugs usefully is this:

*report all the facts*.  If you are not sure whether to state a fact or

leave it out, state it!

   Often people omit facts because they think they know what causes the

problem and assume that some details do not matter.  Thus, you might

assume that the name of the variable you use in an example does not

matter.  Well, probably it does not, but one cannot be sure.  Perhaps

the bug is a stray memory reference which happens to fetch from the

location where that name is stored in memory; perhaps, if the name were

different, the contents of that location would fool the debugger into

doing the right thing despite the bug.  Play it safe and give a

specific, complete example.  That is the easiest thing for you to do,

and the most helpful.

   Keep in mind that the purpose of a bug report is to enable us to fix

the bug.  It may be that the bug has been reported previously, but

neither you nor we can know that unless your bug report is complete and

self-contained.

   Sometimes people give a few sketchy facts and ask, "Does this ring a

bell?"  Those bug reports are useless, and we urge everyone to _refuse

to respond to them_ except to chide the sender to report bugs properly.

   To enable us to fix the bug, you should include all these things:

   * The version of GDB.  GDB announces it if you start with no

     arguments; you can also print it at any time using `show version'.

     Without this, we will not know whether there is any point in

     looking for the bug in the current version of GDB.

   * The type of machine you are using, and the operating system name

     and version number.

   * What compiler (and its version) was used to compile GDB--e.g.

     "gcc-2.8.1".

   * What compiler (and its version) was used to compile the program

     you are debugging--e.g.  "gcc-2.8.1", or "HP92453-01 A.10.32.03 HP

     C Compiler".  For GCC, you can say `gcc --version' to get this

     information; for other compilers, see the documentation for those

     compilers.

   * The command arguments you gave the compiler to compile your

     example and observe the bug.  For example, did you use `-O'?  To

     guarantee you will not omit something important, list them all.  A

     copy of the Makefile (or the output from make) is sufficient.

     If we were to try to guess the arguments, we would probably guess

     wrong and then we might not encounter the bug.

   * A complete input script, and all necessary source files, that will

     reproduce the bug.

   * A description of what behavior you observe that you believe is

     incorrect.  For example, "It gets a fatal signal."

     Of course, if the bug is that GDB gets a fatal signal, then we

     will certainly notice it.  But if the bug is incorrect output, we

     might not notice unless it is glaringly wrong.  You might as well

     not give us a chance to make a mistake.

     Even if the problem you experience is a fatal signal, you should

     still say so explicitly.  Suppose something strange is going on,

     such as, your copy of GDB is out of synch, or you have encountered

     a bug in the C library on your system.  (This has happened!)  Your

     copy might crash and ours would not.  If you told us to expect a

     crash, then when ours fails to crash, we would know that the bug

     was not happening for us.  If you had not told us to expect a

     crash, then we would not be able to draw any conclusion from our

     observations.

   * If you wish to suggest changes to the GDB source, send us context

     diffs.  If you even discuss something in the GDB source, refer to

     it by context, not by line number.

     The line numbers in our development sources will not match those

     in your sources.  Your line numbers would convey no useful

     information to us.

   Here are some things that are not necessary:

   * A description of the envelope of the bug.

     Often people who encounter a bug spend a lot of time investigating

     which changes to the input file will make the bug go away and which

     changes will not affect it.

     This is often time consuming and not very useful, because the way

     we will find the bug is by running a single example under the

     debugger with breakpoints, not by pure deduction from a series of

     examples.  We recommend that you save your time for something else.

     Of course, if you can find a simpler example to report _instead_

     of the original one, that is a convenience for us.  Errors in the

     output will be easier to spot, running under the debugger will take

     less time, and so on.

     However, simplification is not vital; if you do not want to do

     this, report the bug anyway and send us the entire test case you

     used.

   * A patch for the bug.

     A patch for the bug does help us if it is a good one.  But do not

     omit the necessary information, such as the test case, on the

     assumption that a patch is all we need.  We might see problems

     with your patch and decide to fix the problem another way, or we

     might not understand it at all.

     Sometimes with a program as complicated as GDB it is very hard to

     construct an example that will make the program follow a certain

     path through the code.  If you do not send us the example, we will

     not be able to construct one, so we will not be able to verify

     that the bug is fixed.

     And if we cannot understand what bug you are trying to fix, or why

     your patch should be an improvement, we will not install it.  A

     test case will help us to understand.

   * A guess about what the bug is or what it depends on.

     Such guesses are usually wrong.  Even we cannot guess right about

     such things without first using the debugger to find the facts.

File: gdb.info,  Node: Command Line Editing,  Next: Using History Interactively,  Prev: Formatting Documentation,  Up: Top

Command Line Editing

********************

   This chapter describes the basic features of the GNU command line

editing interface.

* Menu:

* Introduction and Notation::   Notation used in this text.

* Readline Interaction::        The minimum set of commands for editing a line.

* Readline Init File::          Customizing Readline from a user's view.

* Bindable Readline Commands::  A description of most of the Readline commands

                                available for binding

* Readline vi Mode::            A short description of how to make Readline

                                behave like the vi editor.

File: gdb.info,  Node: Introduction and Notation,  Next: Readline Interaction,  Up: Command Line Editing

Introduction to Line Editing

============================

   The following paragraphs describe the notation used to represent

keystrokes.

   The text  is read as `Control-K' and describes the character

produced when the  key is pressed while the Control key is depressed.

   The text  is read as `Meta-K' and describes the character

produced when the Meta key (if you have one) is depressed, and the 

key is pressed.  The Meta key is labeled  on many keyboards.  On

keyboards with two keys labeled  (usually to either side of the

space bar), the  on the left side is generally set to work as a

Meta key.  The  key on the right may also be configured to work as

a Meta key or may be configured as some other modifier, such as a

Compose key for typing accented characters.

   If you do not have a Meta or  key, or another key working as a

Meta key, the identical keystroke can be generated by typing 

first, and then typing .  Either process is known as "metafying" the

 key.

   The text  is read as `Meta-Control-k' and describes the

character produced by "metafying" .

   In addition, several keys have their own names.  Specifically,

, , , , , and  all stand for themselves

when seen in this text, or in an init file (*note Readline Init File::).

If your keyboard lacks a  key, typing  will produce the

desired character.  The  key may be labeled  or  on

some keyboards.

File: gdb.info,  Node: Readline Interaction,  Next: Readline Init File,  Prev: Introduction and Notation,  Up: Command Line Editing

Readline Interaction

====================

   Often during an interactive session you type in a long line of text,

only to notice that the first word on the line is misspelled.  The

Readline library gives you a set of commands for manipulating the text

as you type it in, allowing you to just fix your typo, and not forcing

you to retype the majority of the line.  Using these editing commands,

you move the cursor to the place that needs correction, and delete or

insert the text of the corrections.  Then, when you are satisfied with

the line, you simply press .  You do not have to be at the end

of the line to press ; the entire line is accepted regardless

of the location of the cursor within the line.

* Menu:

* Readline Bare Essentials::    The least you need to know about Readline.

* Readline Movement Commands::  Moving about the input line.

* Readline Killing Commands::   How to delete text, and how to get it back!

* Readline Arguments::          Giving numeric arguments to commands.

* Searching::                   Searching through previous lines.

File: gdb.info,  Node: Readline Bare Essentials,  Next: Readline Movement Commands,  Up: Readline Interaction

Readline Bare Essentials

------------------------

   In order to enter characters into the line, simply type them.  The

typed character appears where the cursor was, and then the cursor moves

one space to the right.  If you mistype a character, you can use your

erase character to back up and delete the mistyped character.

   Sometimes you may mistype a character, and not notice the error

until you have typed several other characters.  In that case, you can

type  to move the cursor to the left, and then correct your

mistake.  Afterwards, you can move the cursor to the right with .

   When you add text in the middle of a line, you will notice that

characters to the right of the cursor are `pushed over' to make room

for the text that you have inserted.  Likewise, when you delete text

behind the cursor, characters to the right of the cursor are `pulled

back' to fill in the blank space created by the removal of the text.  A

list of the bare essentials for editing the text of an input line

follows.

     Move back one character.

     Move forward one character.

 or 

     Delete the character to the left of the cursor.

     Delete the character underneath the cursor.

Printing characters

     Insert the character into the line at the cursor.

 or 

     Undo the last editing command.  You can undo all the way back to an

     empty line.

(Depending on your configuration, the  key be set to delete

the character to the left of the cursor and the  key set to delete

the character underneath the cursor, like , rather than the

character to the left of the cursor.)

File: gdb.info,  Node: Readline Movement Commands,  Next: Readline Killing Commands,  Prev: Readline Bare Essentials,  Up: Readline Interaction

Readline Movement Commands

--------------------------

   The above table describes the most basic keystrokes that you need in

order to do editing of the input line.  For your convenience, many

other commands have been added in addition to , , , and

.  Here are some commands for moving more rapidly about the line.

     Move to the start of the line.

     Move to the end of the line.

     Move forward a word, where a word is composed of letters and

     digits.

     Move backward a word.

     Clear the screen, reprinting the current line at the top.

   Notice how  moves forward a character, while  moves

forward a word.  It is a loose convention that control keystrokes

operate on characters while meta keystrokes operate on words.

File: gdb.info,  Node: Readline Killing Commands,  Next: Readline Arguments,  Prev: Readline Movement Commands,  Up: Readline Interaction

Readline Killing Commands

-------------------------

   "Killing" text means to delete the text from the line, but to save

it away for later use, usually by "yanking" (re-inserting) it back into

the line.  (`Cut' and `paste' are more recent jargon for `kill' and

`yank'.)

   If the description for a command says that it `kills' text, then you

can be sure that you can get the text back in a different (or the same)

place later.

   When you use a kill command, the text is saved in a "kill-ring".

Any number of consecutive kills save all of the killed text together, so

that when you yank it back, you get it all.  The kill ring is not line

specific; the text that you killed on a previously typed line is

available to be yanked back later, when you are typing another line.

   Here is the list of commands for killing text.

     Kill the text from the current cursor position to the end of the

     line.

     Kill from the cursor to the end of the current word, or, if between

     words, to the end of the next word.  Word boundaries are the same

     as those used by .

     Kill from the cursor the start of the previous word, or, if between

     words, to the start of the previous word.  Word boundaries are the

     same as those used by .

     Kill from the cursor to the previous whitespace.  This is

     different than  because the word boundaries differ.

   Here is how to "yank" the text back into the line.  Yanking means to

copy the most-recently-killed text from the kill buffer.

     Yank the most recently killed text back into the buffer at the

     cursor.

     Rotate the kill-ring, and yank the new top.  You can only do this

     if the prior command is  or .

File: gdb.info,  Node: Readline Arguments,  Next: Searching,  Prev: Readline Killing Commands,  Up: Readline Interaction

Readline Arguments

------------------

   You can pass numeric arguments to Readline commands.  Sometimes the

argument acts as a repeat count, other times it is the sign of the

argument that is significant.  If you pass a negative argument to a

command which normally acts in a forward direction, that command will

act in a backward direction.  For example, to kill text back to the

start of the line, you might type `M-- C-k'.

   The general way to pass numeric arguments to a command is to type

meta digits before the command.  If the first `digit' typed is a minus

sign (`-'), then the sign of the argument will be negative.  Once you

have typed one meta digit to get the argument started, you can type the

remainder of the digits, and then the command.  For example, to give

the  command an argument of 10, you could type `M-1 0 C-d'.

File: gdb.info,  Node: Searching,  Prev: Readline Arguments,  Up: Readline Interaction

Searching for Commands in the History

-------------------------------------

   Readline provides commands for searching through the command history

for lines containing a specified string.  There are two search modes:

INCREMENTAL and NON-INCREMENTAL.

   Incremental searches begin before the user has finished typing the

search string.  As each character of the search string is typed,

Readline displays the next entry from the history matching the string

typed so far.  An incremental search requires only as many characters

as needed to find the desired history entry.  To search backward in the

history for a particular string, type .  Typing  searches

forward through the history.  The characters present in the value of

the `isearch-terminators' variable are used to terminate an incremental

search.  If that variable has not been assigned a value, the  and

 characters will terminate an incremental search.   will

abort an incremental search and restore the original line.  When the

search is terminated, the history entry containing the search string

becomes the current line.

   To find other matching entries in the history list, type  or

 as appropriate.  This will search backward or forward in the

history for the next entry matching the search string typed so far.

Any other key sequence bound to a Readline command will terminate the

search and execute that command.  For instance, a  will terminate

the search and accept the line, thereby executing the command from the

history list.

   Non-incremental searches read the entire search string before

starting to search for matching history lines.  The search string may be

typed by the user or be part of the contents of the current line.

File: gdb.info,  Node: Readline Init File,  Next: Bindable Readline Commands,  Prev: Readline Interaction,  Up: Command Line Editing

Readline Init File

==================

   Although the Readline library comes with a set of Emacs-like

keybindings installed by default, it is possible to use a different set

of keybindings.  Any user can customize programs that use Readline by

putting commands in an "inputrc" file, conventionally in his home

directory.  The name of this file is taken from the value of the

environment variable `INPUTRC'.  If that variable is unset, the default

is `~/.inputrc'.

   When a program which uses the Readline library starts up, the init

file is read, and the key bindings are set.

   In addition, the `C-x C-r' command re-reads this init file, thus

incorporating any changes that you might have made to it.

* Menu:

* Readline Init File Syntax::   Syntax for the commands in the inputrc file.

* Conditional Init Constructs:: Conditional key bindings in the inputrc file.

* Sample Init File::            An example inputrc file.

File: gdb.info,  Node: Readline Init File Syntax,  Next: Conditional Init Constructs,  Up: Readline Init File

Readline Init File Syntax

-------------------------

   There are only a few basic constructs allowed in the Readline init

file.  Blank lines are ignored.  Lines beginning with a `#' are

comments.  Lines beginning with a `$' indicate conditional constructs

(*note Conditional Init Constructs::).  Other lines denote variable

settings and key bindings.

Variable Settings