config.but

putty

With auto wrap mode on, if a long line of text reaches the
right-hand edge, it will wrap over on to the next line so you can
still see all the text. With auto wrap mode off, the cursor will
stay at the right-hand edge of the screen, and all the characters in
the line will be printed on top of each other.

If you are running a full-screen application and you occasionally
find the screen scrolling up when it looks as if it shouldn't, you
could try turning this option off.

Auto wrap mode can be turned on and off by \i{control sequence}s sent by
the server. This configuration option controls the \e{default}
state, which will be restored when you reset the terminal (see
\k{reset-terminal}). However, if you modify this option in
mid-session using \q{Change Settings}, it will take effect
immediately.

\S{config-decom} \q{DEC Origin Mode initially on}

\cfg{winhelp-topic}{terminal.decom}

\i{DEC Origin Mode} is a minor option which controls how PuTTY
interprets cursor-position \i{control sequence}s sent by the server.

The server can send a control sequence that restricts the \i{scrolling
region} of the display. For example, in an editor, the server might
reserve a line at the top of the screen and a line at the bottom,
and might send a control sequence that causes scrolling operations
to affect only the remaining lines.

With DEC Origin Mode on, \i{cursor coordinates} are counted from the top
of the scrolling region. With it turned off, cursor coordinates are
counted from the top of the whole screen regardless of the scrolling
region.

It is unlikely you would need to change this option, but if you find
a full-screen application is displaying pieces of text in what looks
like the wrong part of the screen, you could try turning DEC Origin
Mode on to see whether that helps.

DEC Origin Mode can be turned on and off by control sequences sent
by the server. This configuration option controls the \e{default}
state, which will be restored when you reset the terminal (see
\k{reset-terminal}). However, if you modify this option in
mid-session using \q{Change Settings}, it will take effect
immediately.

\S{config-crlf} \q{Implicit CR in every LF}

\cfg{winhelp-topic}{terminal.lfhascr}

Most servers send two control characters, \i{CR} and \i{LF}, to start a
\i{new line} of the screen. The CR character makes the cursor return to the
left-hand side of the screen. The LF character makes the cursor move
one line down (and might make the screen scroll).

Some servers only send LF, and expect the terminal to move the
cursor over to the left automatically. If you come across a server
that does this, you will see a \I{stair-stepping}stepped effect on the
screen, like this:

\c First line of text
\c                   Second line
\c                              Third line

If this happens to you, try enabling the \q{Implicit CR in every LF}
option, and things might go back to normal:

\c First line of text
\c Second line
\c Third line

\S{config-erase} \q{Use \i{background colour} to erase screen}

\cfg{winhelp-topic}{terminal.bce}

Not all terminals agree on what colour to turn the screen when the
server sends a \q{\i{clear screen}} sequence. Some terminals believe the
screen should always be cleared to the \e{default} background
colour. Others believe the screen should be cleared to whatever the
server has selected as a background colour.

There exist applications that expect both kinds of behaviour.
Therefore, PuTTY can be configured to do either.

With this option disabled, screen clearing is always done in the
default background colour. With this option enabled, it is done in
the \e{current} background colour.

Background-colour erase can be turned on and off by \i{control
sequences} sent by the server. This configuration option controls the
\e{default} state, which will be restored when you reset the
terminal (see \k{reset-terminal}). However, if you modify this
option in mid-session using \q{Change Settings}, it will take effect
immediately.

\S{config-blink} \q{Enable \i{blinking text}}

\cfg{winhelp-topic}{terminal.blink}

The server can ask PuTTY to display text that blinks on and off.
This is very distracting, so PuTTY allows you to turn blinking text
off completely.

When blinking text is disabled and the server attempts to make some
text blink, PuTTY will instead display the text with a \I{background
colour, bright}bolded background colour.

Blinking text can be turned on and off by \i{control sequence}s sent by
the server. This configuration option controls the \e{default}
state, which will be restored when you reset the terminal (see
\k{reset-terminal}). However, if you modify this option in
mid-session using \q{Change Settings}, it will take effect
immediately.

\S{config-answerback} \q{\ii{Answerback} to ^E}

\cfg{winhelp-topic}{terminal.answerback}

This option controls what PuTTY will send back to the server if the
server sends it the ^E \i{enquiry character}. Normally it just sends
the string \q{PuTTY}.

If you accidentally write the contents of a binary file to your
terminal, you will probably find that it contains more than one ^E
character, and as a result your next command line will probably read
\q{PuTTYPuTTYPuTTY...} as if you had typed the answerback string
multiple times at the keyboard. If you set the answerback string to
be empty, this problem should go away, but doing so might cause
other problems.

Note that this is \e{not} the feature of PuTTY which the server will
typically use to determine your terminal type. That feature is the
\q{\ii{Terminal-type} string} in the Connection panel; see
\k{config-termtype} for details.

You can include control characters in the answerback string using
\c{^C} notation. (Use \c{^~} to get a literal \c{^}.)

\S{config-localecho} \q{\ii{Local echo}}

\cfg{winhelp-topic}{terminal.localecho}

With local echo disabled, characters you type into the PuTTY window
are not echoed in the window \e{by PuTTY}. They are simply sent to
the server. (The \e{server} might choose to \I{remote echo}echo them
back to you; this can't be controlled from the PuTTY control panel.)

Some types of session need local echo, and many do not. In its
default mode, PuTTY will automatically attempt to deduce whether or
not local echo is appropriate for the session you are working in. If
you find it has made the wrong decision, you can use this
configuration option to override its choice: you can force local
echo to be turned on, or force it to be turned off, instead of
relying on the automatic detection.

\S{config-localedit} \q{\ii{Local line editing}}

\cfg{winhelp-topic}{terminal.localedit}

Normally, every character you type into the PuTTY window is sent
immediately to the server the moment you type it.

If you enable local line editing, this changes. PuTTY will let you
edit a whole line at a time locally, and the line will only be sent
to the server when you press Return. If you make a mistake, you can
use the Backspace key to correct it before you press Return, and the
server will never see the mistake.

Since it is hard to edit a line locally without being able to see
it, local line editing is mostly used in conjunction with \i{local echo}
(\k{config-localecho}). This makes it ideal for use in raw mode
\#{FIXME} or when connecting to \i{MUD}s or \i{talker}s. (Although some more
advanced MUDs do occasionally turn local line editing on and turn
local echo off, in order to accept a password from the user.)

Some types of session need local line editing, and many do not. In
its default mode, PuTTY will automatically attempt to deduce whether
or not local line editing is appropriate for the session you are
working in. If you find it has made the wrong decision, you can use
this configuration option to override its choice: you can force
local line editing to be turned on, or force it to be turned off,
instead of relying on the automatic detection.

\S{config-printing} \ii{Remote-controlled printing}

\cfg{winhelp-topic}{terminal.printing}

A lot of VT100-compatible terminals support printing under control
of the remote server. PuTTY supports this feature as well, but it is
turned off by default.

To enable remote-controlled printing, choose a printer from the
\q{Printer to send ANSI printer output to} drop-down list box. This
should allow you to select from all the printers you have installed
drivers for on your computer. Alternatively, you can type the
network name of a networked printer (for example,
\c{\\\\printserver\\printer1}) even if you haven't already
installed a driver for it on your own machine.

When the remote server attempts to print some data, PuTTY will send
that data to the printer \e{raw} - without translating it,
attempting to format it, or doing anything else to it. It is up to
you to ensure your remote server knows what type of printer it is
talking to.

Since PuTTY sends data to the printer raw, it cannot offer options
such as portrait versus landscape, print quality, or paper tray
selection. All these things would be done by your PC printer driver
(which PuTTY bypasses); if you need them done, you will have to find
a way to configure your remote server to do them.

To disable remote printing again, choose \q{None (printing
disabled)} from the printer selection list. This is the default
state.

\H{config-keyboard} The Keyboard panel

The Keyboard configuration panel allows you to control the behaviour
of the \i{keyboard} in PuTTY.  The correct state for many of these
settings depends on what the server to which PuTTY is connecting
expects.  With a \i{Unix} server, this is likely to depend on the
\i\c{termcap} or \i\c{terminfo} entry it uses, which in turn is likely to
be controlled by the \q{\ii{Terminal-type} string} setting in the Connection
panel; see \k{config-termtype} for details.  If none of the settings here
seems to help, you may find \k{faq-keyboard} to be useful.

\S{config-backspace} Changing the action of the \ii{Backspace key}

\cfg{winhelp-topic}{keyboard.backspace}

Some terminals believe that the Backspace key should send the same
thing to the server as \i{Control-H} (ASCII code 8). Other terminals
believe that the Backspace key should send ASCII code 127 (usually
known as \i{Control-?}) so that it can be distinguished from Control-H.
This option allows you to choose which code PuTTY generates when you
press Backspace.

If you are connecting over SSH, PuTTY by default tells the server
the value of this option (see \k{config-ttymodes}), so you may find
that the Backspace key does the right thing either way. Similarly,
if you are connecting to a \i{Unix} system, you will probably find that
the Unix \i\c{stty} command lets you configure which the server
expects to see, so again you might not need to change which one PuTTY
generates. On other systems, the server's expectation might be fixed
and you might have no choice but to configure PuTTY.

If you do have the choice, we recommend configuring PuTTY to
generate Control-? and configuring the server to expect it, because
that allows applications such as \c{emacs} to use Control-H for
help.

(Typing \i{Shift-Backspace} will cause PuTTY to send whichever code
isn't configured here as the default.)

\S{config-homeend} Changing the action of the \i{Home and End keys}

\cfg{winhelp-topic}{keyboard.homeend}

The Unix terminal emulator \i\c{rxvt} disagrees with the rest of the
world about what character sequences should be sent to the server by
the Home and End keys.

\i\c{xterm}, and other terminals, send \c{ESC [1~} for the Home key,
and \c{ESC [4~} for the End key. \c{rxvt} sends \c{ESC [H} for the
Home key and \c{ESC [Ow} for the End key.

If you find an application on which the Home and End keys aren't
working, you could try switching this option to see if it helps.

\S{config-funkeys} Changing the action of the \i{function keys} and
\i{keypad}

\cfg{winhelp-topic}{keyboard.funkeys}

This option affects the function keys (F1 to F12) and the top row of
the numeric keypad.

\b In the default mode, labelled \c{ESC [n~}, the function keys
generate sequences like \c{ESC [11~}, \c{ESC [12~} and so on. This
matches the general behaviour of Digital's terminals.

\b In Linux mode, F6 to F12 behave just like the default mode, but
F1 to F5 generate \c{ESC [[A} through to \c{ESC [[E}. This mimics the
\i{Linux virtual console}.

\b In \I{xterm}Xterm R6 mode, F5 to F12 behave like the default mode, but F1
to F4 generate \c{ESC OP} through to \c{ESC OS}, which are the
sequences produced by the top row of the \e{keypad} on Digital's
terminals.

\b In \i{VT400} mode, all the function keys behave like the default
mode, but the actual top row of the numeric keypad generates \c{ESC
OP} through to \c{ESC OS}.

\b In \i{VT100+} mode, the function keys generate \c{ESC OP} through to
\c{ESC O[}

\b In \i{SCO} mode, the function keys F1 to F12 generate \c{ESC [M}
through to \c{ESC [X}.  Together with shift, they generate \c{ESC [Y}
through to \c{ESC [j}.  With control they generate \c{ESC [k} through
to \c{ESC [v}, and with shift and control together they generate
\c{ESC [w} through to \c{ESC [\{}.

If you don't know what any of this means, you probably don't need to