Packages and Binaries:
expect
Automates interactive applications
Expect is a tool for automating interactive applications according to a script.
Following the script, Expect knows what can be expected from a program and what
the correct response should be. Expect is also useful for testing these same
applications. And by adding Tk, you can also wrap interactive applications in
X11 GUIs. An interpreted language provides branching and high-level control
structures to direct the dialogue. In addition, the user can take control and
interact directly when desired, afterward returning control to the script.
This package contains the expect binary and several Expect based scripts.
Installed size: 324 KB
How to install: sudo apt install expect
Dependencies:
- libc6
- libtcl8.6
- libtcl9.0
- tcl-expect
- tcl8.6
- tcl9.0
autoexpect
Generate an Expect script from watching a session
root@kali:~# man autoexpect
AUTOEXPECT(1) General Commands Manual AUTOEXPECT(1)
NAME
autoexpect - generate an Expect script from watching a session
SYNOPSIS
autoexpect [ args ] [ program args... ]
INTRODUCTION
autoexpect watches you interacting with another program and creates an Ex-
pect script that reproduces your interactions. For straightline scripts,
autoexpect saves substantial time over writing scripts by hand. Even if
you are an Expect expert, you will find it convenient to use autoexpect to
automate the more mindless parts of interactions. It is much easier to
cut/paste hunks of autoexpect scripts together than to write them from
scratch. And if you are a beginner, you may be able to get away with
learning nothing more about Expect than how to call autoexpect.
The simplest way to use autoexpect is to call it from the command line
with no arguments. For example:
% autoexpect
By default, autoexpect spawns a shell for you. Given a program name and
arguments, autoexpect spawns that program. For example:
% autoexpect ftp ftp.cme.nist.gov
Once your spawned program is running, interact normally. When you have
exited the shell (or program that you specified), autoexpect will create a
new script for you. By default, autoexpect writes the new script to
"script.exp". You can override this with the -f flag followed by a new
script name.
The following example runs "ftp ftp.cme.nist.gov" and stores the resulting
Expect script in the file "nist".
% autoexpect -f nist ftp ftp.cme.nist.gov
It is important to understand that autoexpect does not guarantee a working
script because it necessarily has to guess about certain things - and oc-
casionally it guesses wrong. However, it is usually very easy to identify
and fix these problems. The typical problems are:
* Timing. A surprisingly large number of programs (rn, ksh, zsh,
telnet, etc.) and devices (e.g., modems) ignore keystrokes that
arrive "too quickly" after prompts. If you find your new
script hanging up at one spot, try adding a short sleep just
before the previous send.
You can force this behavior throughout by overriding the vari-
able "force_conservative" near the beginning of the generated
script. This "conservative" mode makes autoexpect automati-
cally pause briefly (one tenth of a second) before sending each
character. This pacifies every program I know of.
This conservative mode is useful if you just want to quickly
reassure yourself that the problem is a timing one (or if you
really don't care about how fast the script runs). This same
mode can be forced before script generation by using the -c
flag.
Fortunately, these timing spots are rare. For example, telnet
ignores characters only after entering its escape sequence.
Modems only ignore characters immediately after connecting to
them for the first time. A few programs exhibit this behavior
all the time but typically have a switch to disable it. For
example, rn's -T flag disables this behavior.
The following example starts autoexpect in conservative mode.
autoexpect -c
The -C flag defines a key to toggle conservative mode. The
following example starts autoexpect (in non-conservative mode)
with ^L as the toggle. (Note that the ^L is entered literally
- i.e., enter a real control-L).
autoexpect -C ^L
The following example starts autoexpect in conservative mode
with ^L as the toggle.
autoexpect -c -C ^L
* Echoing. Many program echo characters. For example, if you
type "more" to a shell, what autoexpect actually sees is:
you typed 'm',
computer typed 'm',
you typed 'o',
computer typed 'o',
you typed 'r',
computer typed 'r',
...
Without specific knowledge of the program, it is impossible to
know if you are waiting to see each character echoed before
typing the next. If autoexpect sees characters being echoed,
it assumes that it can send them all as a group rather than in-
terleaving them the way they originally appeared. This makes
the script more pleasant to read. However, it could conceiv-
ably be incorrect if you really had to wait to see each charac-
ter echoed.
* Change. Autoexpect records every character from the interac-
tion in the script. This is desirable because it gives you the
ability to make judgements about what is important and what can
be replaced with a pattern match.
On the other hand, if you use commands whose output differs
from run to run, the generated scripts are not going to be cor-
rect. For example, the "date" command always produces differ-
ent output. So using the date command while running autoexpect
is a sure way to produce a script that will require editing in
order for it to work.
The -p flag puts autoexpect into "prompt mode". In this mode,
autoexpect will only look for the last line of program output -
which is usually the prompt. This handles the date problem
(see above) and most others.
The following example starts autoexpect in prompt mode.
autoexpect -p
The -P flag defines a key to toggle prompt mode. The following
example starts autoexpect (in non-prompt mode) with ^P as the
toggle. Note that the ^P is entered literally - i.e., enter a
real control-P.
autoexpect -P ^P
The following example starts autoexpect in prompt mode with ^P
as the toggle.
autoexpect -p -P ^P
OTHER FLAGS
The -quiet flag disables informational messages produced by autoexpect.
The -Q flag names a quote character which can be used to enter characters
that autoexpect would otherwise consume because they are used as toggles.
The following example shows a number of flags with quote used to provide a
way of entering the toggles literally.
autoexpect -P ^P -C ^L -Q ^Q
STYLE
I don't know if there is a "style" for Expect programs but autoexpect
should definitely not be held up as any model of style. For example, au-
toexpect uses features of Expect that are intended specifically for com-
puter-generated scripting. So don't try to faithfully write scripts that
appear as if they were generated by autoexpect. This is not useful.
On the other hand, autoexpect scripts do show some worthwhile things. For
example, you can see how any string must be quoted in order to use it in a
Tcl script simply by running the strings through autoexpect.
SEE ALSO
"Exploring Expect: A Tcl-Based Toolkit for Automating Interactive Pro-
grams" by Don Libes, O'Reilly and Associates, January 1995.
AUTHOR
Don Libes, National Institute of Standards and Technology
expect and autoexpect are in the public domain. NIST and I would appreci-
ate credit if these programs or parts of them are used.
30 June 1995 AUTOEXPECT(1)
autopasswd
root@kali:~# autopasswd -h
spawn passwd -h
Usage: passwd [options] [LOGIN]
Options:
-a, --all report password status on all accounts
-d, --delete delete the password for the named account
-e, --expire force expire the password for the named account
-h, --help display this help message and exit
-k, --keep-tokens change password only if expired
-i, --inactive INACTIVE set password inactive after expiration
to INACTIVE
-l, --lock lock the password of the named account
-n, --mindays MIN_DAYS set minimum number of days before password
change to MIN_DAYS
-q, --quiet quiet mode
-r, --repository REPOSITORY change password in REPOSITORY repository
-R, --root CHROOT_DIR directory to chroot into
-P, --prefix PREFIX_DIR directory prefix
-S, --status report password status on the named account
-u, --unlock unlock the password of the named account
-w, --warndays WARN_DAYS set expiration warning days to WARN_DAYS
-x, --maxdays MAX_DAYS set maximum number of days before password
change to MAX_DAYS
-s, --stdin read new token from stdin
cryptdir
Encrypt/decrypt all files in a directory
root@kali:~# cryptdir -h
This example requires the mcrypt package.
decryptdir
Encrypt/decrypt all files in a directory
root@kali:~# decryptdir -h
This example requires the mcrypt package.
dislocate
Expect_disconnect and reconnect processes Disconnect and reconnect processes
root@kali:~# dislocate -h
bad flag "-h": must be -console, -ignore, -leaveopen, -noecho, -nottycopy, -nottyinit, -open, or -pty
while executing
"spawn -h"
("eval" body line 1)
invoked from within
"eval spawn $argv"
(procedure "child" line 11)
invoked from within
"child $datearg $argv"
invoked from within
"if {$argc} {
# initial creation occurs before fork because if we do it after
# then either the child or the parent may have to spin retrying
..."
(file "/usr/bin/dislocate" line 264)
expect
Programmed dialogue with interactive programs, Version 5 Programmed dialogue with interactive programs, Version 5
root@kali:~# expect -h
expect: invalid option -- 'h'
usage: expect [-div] [-c cmds] [[-f] cmdfile] [args]
expect8.6
Programmed dialogue with interactive programs, Version 5
root@kali:~# expect8.6 -h
expect8.6: invalid option -- 'h'
usage: expect [-div] [-c cmds] [[-f] cmdfile] [args]
expect9.0
Programmed dialogue with interactive programs, Version 5
root@kali:~# expect9.0 -h
expect9.0: invalid option -- 'h'
usage: expect [-div] [-c cmds] [[-f] cmdfile] [args]
expect_autoexpect
Generate an Expect script from watching a session
root@kali:~# man expect_autoexpect
AUTOEXPECT(1) General Commands Manual AUTOEXPECT(1)
NAME
autoexpect - generate an Expect script from watching a session
SYNOPSIS
autoexpect [ args ] [ program args... ]
INTRODUCTION
autoexpect watches you interacting with another program and creates an Ex-
pect script that reproduces your interactions. For straightline scripts,
autoexpect saves substantial time over writing scripts by hand. Even if
you are an Expect expert, you will find it convenient to use autoexpect to
automate the more mindless parts of interactions. It is much easier to
cut/paste hunks of autoexpect scripts together than to write them from
scratch. And if you are a beginner, you may be able to get away with
learning nothing more about Expect than how to call autoexpect.
The simplest way to use autoexpect is to call it from the command line
with no arguments. For example:
% autoexpect
By default, autoexpect spawns a shell for you. Given a program name and
arguments, autoexpect spawns that program. For example:
% autoexpect ftp ftp.cme.nist.gov
Once your spawned program is running, interact normally. When you have
exited the shell (or program that you specified), autoexpect will create a
new script for you. By default, autoexpect writes the new script to
"script.exp". You can override this with the -f flag followed by a new
script name.
The following example runs "ftp ftp.cme.nist.gov" and stores the resulting
Expect script in the file "nist".
% autoexpect -f nist ftp ftp.cme.nist.gov
It is important to understand that autoexpect does not guarantee a working
script because it necessarily has to guess about certain things - and oc-
casionally it guesses wrong. However, it is usually very easy to identify
and fix these problems. The typical problems are:
* Timing. A surprisingly large number of programs (rn, ksh, zsh,
telnet, etc.) and devices (e.g., modems) ignore keystrokes that
arrive "too quickly" after prompts. If you find your new
script hanging up at one spot, try adding a short sleep just
before the previous send.
You can force this behavior throughout by overriding the vari-
able "force_conservative" near the beginning of the generated
script. This "conservative" mode makes autoexpect automati-
cally pause briefly (one tenth of a second) before sending each
character. This pacifies every program I know of.
This conservative mode is useful if you just want to quickly
reassure yourself that the problem is a timing one (or if you
really don't care about how fast the script runs). This same
mode can be forced before script generation by using the -c
flag.
Fortunately, these timing spots are rare. For example, telnet
ignores characters only after entering its escape sequence.
Modems only ignore characters immediately after connecting to
them for the first time. A few programs exhibit this behavior
all the time but typically have a switch to disable it. For
example, rn's -T flag disables this behavior.
The following example starts autoexpect in conservative mode.
autoexpect -c
The -C flag defines a key to toggle conservative mode. The
following example starts autoexpect (in non-conservative mode)
with ^L as the toggle. (Note that the ^L is entered literally
- i.e., enter a real control-L).
autoexpect -C ^L
The following example starts autoexpect in conservative mode
with ^L as the toggle.
autoexpect -c -C ^L
* Echoing. Many program echo characters. For example, if you
type "more" to a shell, what autoexpect actually sees is:
you typed 'm',
computer typed 'm',
you typed 'o',
computer typed 'o',
you typed 'r',
computer typed 'r',
...
Without specific knowledge of the program, it is impossible to
know if you are waiting to see each character echoed before
typing the next. If autoexpect sees characters being echoed,
it assumes that it can send them all as a group rather than in-
terleaving them the way they originally appeared. This makes
the script more pleasant to read. However, it could conceiv-
ably be incorrect if you really had to wait to see each charac-
ter echoed.
* Change. Autoexpect records every character from the interac-
tion in the script. This is desirable because it gives you the
ability to make judgements about what is important and what can
be replaced with a pattern match.
On the other hand, if you use commands whose output differs
from run to run, the generated scripts are not going to be cor-
rect. For example, the "date" command always produces differ-
ent output. So using the date command while running autoexpect
is a sure way to produce a script that will require editing in
order for it to work.
The -p flag puts autoexpect into "prompt mode". In this mode,
autoexpect will only look for the last line of program output -
which is usually the prompt. This handles the date problem
(see above) and most others.
The following example starts autoexpect in prompt mode.
autoexpect -p
The -P flag defines a key to toggle prompt mode. The following
example starts autoexpect (in non-prompt mode) with ^P as the
toggle. Note that the ^P is entered literally - i.e., enter a
real control-P.
autoexpect -P ^P
The following example starts autoexpect in prompt mode with ^P
as the toggle.
autoexpect -p -P ^P
OTHER FLAGS
The -quiet flag disables informational messages produced by autoexpect.
The -Q flag names a quote character which can be used to enter characters
that autoexpect would otherwise consume because they are used as toggles.
The following example shows a number of flags with quote used to provide a
way of entering the toggles literally.
autoexpect -P ^P -C ^L -Q ^Q
STYLE
I don't know if there is a "style" for Expect programs but autoexpect
should definitely not be held up as any model of style. For example, au-
toexpect uses features of Expect that are intended specifically for com-
puter-generated scripting. So don't try to faithfully write scripts that
appear as if they were generated by autoexpect. This is not useful.
On the other hand, autoexpect scripts do show some worthwhile things. For
example, you can see how any string must be quoted in order to use it in a
Tcl script simply by running the strings through autoexpect.
SEE ALSO
"Exploring Expect: A Tcl-Based Toolkit for Automating Interactive Pro-
grams" by Don Libes, O'Reilly and Associates, January 1995.
AUTHOR
Don Libes, National Institute of Standards and Technology
expect and autoexpect are in the public domain. NIST and I would appreci-
ate credit if these programs or parts of them are used.
30 June 1995 AUTOEXPECT(1)
expect_autopasswd
root@kali:~# expect_autopasswd -h
spawn passwd -h
Usage: passwd [options] [LOGIN]
Options:
-a, --all report password status on all accounts
-d, --delete delete the password for the named account
-e, --expire force expire the password for the named account
-h, --help display this help message and exit
-k, --keep-tokens change password only if expired
-i, --inactive INACTIVE set password inactive after expiration
to INACTIVE
-l, --lock lock the password of the named account
-n, --mindays MIN_DAYS set minimum number of days before password
change to MIN_DAYS
-q, --quiet quiet mode
-r, --repository REPOSITORY change password in REPOSITORY repository
-R, --root CHROOT_DIR directory to chroot into
-P, --prefix PREFIX_DIR directory prefix
-S, --status report password status on the named account
-u, --unlock unlock the password of the named account
-w, --warndays WARN_DAYS set expiration warning days to WARN_DAYS
-x, --maxdays MAX_DAYS set maximum number of days before password
change to MAX_DAYS
-s, --stdin read new token from stdin
expect_cryptdir
Encrypt/decrypt all files in a directory
root@kali:~# expect_cryptdir -h
This example requires the mcrypt package.
expect_decryptdir
Encrypt/decrypt all files in a directory
root@kali:~# expect_decryptdir -h
This example requires the mcrypt package.
expect_dislocate
Disconnect and reconnect processes
root@kali:~# expect_dislocate -h
bad flag "-h": must be -console, -ignore, -leaveopen, -noecho, -nottycopy, -nottyinit, -open, or -pty
while executing
"spawn -h"
("eval" body line 1)
invoked from within
"eval spawn $argv"
(procedure "child" line 11)
invoked from within
"child $datearg $argv"
invoked from within
"if {$argc} {
# initial creation occurs before fork because if we do it after
# then either the child or the parent may have to spin retrying
..."
(file "/usr/bin/expect_dislocate" line 264)
expect_kibitz
Allow two people to interact with one shell
root@kali:~# man expect_kibitz
KIBITZ(1) General Commands Manual KIBITZ(1)
NAME
kibitz - allow two people to interact with one shell
SYNOPSIS
kibitz [ kibitz-args ] user [ program program-args... ]
kibitz [ kibitz-args ] user@host [ program program-args... ]
INTRODUCTION
kibitz allows two (or more) people to interact with one shell (or any ar-
bitrary program). Uses include:
* A novice user can ask an expert user for help. Using kibitz,
the expert can see what the user is doing, and offer advice or
show how to do it right.
* By running kibitz and then starting a full-screen editor, peo-
ple may carry out a conversation, retaining the ability to
scroll backwards, save the entire conversation, or even edit it
while in progress.
* People can team up on games, document editing, or other cooper-
ative tasks where each person has strengths and weaknesses that
complement one another.
USAGE
To start kibitz, user1 runs kibitz with the argument of the user to kib-
itz. For example:
kibitz user2
kibitz starts a new shell (or another program, if given on the command
line), while prompting user2 to run kibitz. If user2 runs kibitz as di-
rected, the keystrokes of both users become the input of the shell. Simi-
larly, both users receive the output from the shell.
To terminate kibitz it suffices to terminate the shell itself. For exam-
ple, if either user types ^D (and the shell accepts this to be EOF), the
shell terminates followed by kibitz.
Normally, all characters are passed uninterpreted. However, if the escape
character (described when kibitz starts) is issued, the user may talk di-
rectly to the kibitz interpreter. Any Expect(1) or Tcl(3) commands may be
given. Also, job control may be used while in the interpreter, to, for
example, suspend or restart kibitz.
Various processes can provide various effects. For example, you can emu-
late a two-way write(1) session with the command:
kibitz user2 sleep 1000000
ARGUMENTS
kibitz takes arguments, these should also be separated by whitespace.
The -noproc flag runs kibitz with no process underneath. Characters are
passed to the other kibitz. This is particularly useful for connecting
multiple interactive processes together. In this mode, characters are not
echoed back to the typist.
-noescape disables the escape character.
-escape char sets the escape character. The default escape character is
^].
-silent turns off informational messages describing what kibitz is doing
to initiate a connection.
-tty ttyname defines the tty to which the invitation should be sent.
If you start kibitz to user2 on a remote computer, kibitz performs a
rlogin to the remote computer with your current username. The flag -proxy
username causes rlogin to use username for the remote login (e.g. if your
account on the remote computer has a different username). If the -proxy
flag is not given, kibitz tries to determine your current username by (in
that order) inspecting the environment variables USER and LOGNAME, then by
using the commands whoami and logname.
The arguments -noescape and -escape can also be given by user2 when
prompted to run kibitz.
MORE THAN TWO USERS
The current implementation of kibitz explicitly understands only two
users, however, it is nonetheless possible to have a three (or more) -way
kibitz, by kibitzing another kibitz. For example, the following command
runs kibitz with the current user, user2, and user3:
% kibitz user2 kibitz user3
Additional users may be added by simply appending more "kibitz user" com-
mands.
The xkibitz script is similar to kibitz but supports the ability to add
additional users (and drop them) dynamically.
CAVEATS
kibitz assumes the 2nd user has the same terminal type and size as the 1st
user. If this assumption is incorrect, graphical programs may display
oddly.
kibitz handles character graphics, but cannot handle bitmapped graphics.
Thus,
% xterm -e kibitz will work
% kibitz xterm will not work
However, you can get the effect of the latter command by using xkibitz
(see SEE ALSO below). kibitz uses the same permissions as used by rlogin,
rsh, etc. Thus, you can only kibitz to users at hosts for which you can
rlogin. Similarly, kibitz will prompt for a password on the remote host
if rlogin would.
If you kibitz to users at remote hosts, kibitz needs to distinguish your
prompt from other things that may precede it during login. (Ideally, the
end of it is preferred but any part should suffice.) If you have an un-
usual prompt, set the environment variable EXPECT_PROMPT to an
egrep(1)-style regular expression. Brackets should be preceded with one
backslash in ranges, and three backslashes for literal brackets. The de-
fault prompt r.e. is "($|%|#) ".
kibitz requires the kibitz program on both hosts. kibitz requires ex-
pect(1).
By comparison, the xkibitz script uses the X authorization mechanism for
inter-host communication so it does not need to login, recognize your
prompt, or require kibitz on the remote host. It does however need per-
mission to access the other X servers.
BUGS
An early version of Sun's tmpfs had a bug in it that causes kibitz to blow
up. If kibitz reports "error flushing ...: Is a directory" ask Sun for
patch #100174.
If your Expect is not compiled with multiple-process support (i.e., you do
not have a working select or poll), you will not be able to run kibitz.
ENVIRONMENT
The environment variable SHELL is used to determine the shell to start, if
no other program is given on the command line.
If the environment variable EXPECT_PROMPT exists, it is taken as a regular
expression which matches the end of your login prompt (but does not other-
wise occur while logging in). See also CAVEATS above.
If the environment variables USER or LOGNAME are defined, they are used to
determine the current user name for a kibitz to a remote computer. See de-
scription of the -proxy option in ARGUMENTS above.
SEE ALSO
Tcl(3), libexpect(3), xkibitz(1)
"Exploring Expect: A Tcl-Based Toolkit for Automating Interactive Pro-
grams" by Don Libes, O'Reilly and Associates, January 1995.
"Kibitz - Connecting Multiple Interactive Programs Together", by Don
Libes, Software - Practice & Experience, John Wiley & Sons, West Sussex,
England, Vol. 23, No. 5, May, 1993.
AUTHOR
Don Libes, National Institute of Standards and Technology
kibitz is in the public domain. NIST and I would appreciate credit if
this program or parts of it are used.
19 October 1994 KIBITZ(1)
expect_lpunlock
root@kali:~# expect_lpunlock -h
spawn ed /etc/printcap
expect_mkpasswd
Generate new password, optionally apply it to a user
root@kali:~# expect_mkpasswd -h
3pu6xh#BA
expect_multixterm
Drive multiple xterms separately or together
root@kali:~# man expect_multixterm
MULTIXTERM(1) General Commands Manual MULTIXTERM(1)
NAME
multixterm - drive multiple xterms separately or together
SYNOPSIS
multixterm [ args ]
DESCRIPTION
Multixterm creates multiple xterms that can be driven together or sepa-
rately.
In its simplest form, multixterm is run with no arguments and commands are
interactively entered in the first entry field. Press return (or click
the "new xterm" button) to create a new xterm running that command.
Keystrokes in the "stdin window" are redirected to all xterms started by
multixterm. xterms may be driven separately simply by focusing on them.
The stdin window must have the focus for keystrokes to be sent to the
xterms. When it has the focus, the color changes to aquamarine. As char-
acters are entered, the color changes to green for a second. This pro-
vides feedback since characters are not echoed in the stdin window.
Typing in the stdin window while holding down the alt or meta keys sends
an escape character before the typed characters. This provides support
for programs such as emacs.
ARGUMENTS
-xa
The optional -xa argument indicates arguments to pass to xterm.
-xc
The optional -xc argument indicates a command to be run in each
named xterm (see -xn). With no -xc argument, the command is
the current shell.
-xd
The optional -xd argument indicates a directory to search for
files that will appear in the Files menu. By default, the di-
rectory is: ~/lib/multixterm
-xf
The optional -xf argument indicates a file to be read at
startup. See FILES below for more info.
-xn
The optional -xn argument indicates a name for each xterm.
This name will also be substituted for any %n in the command
argument (see -xc).
-xv
The optional -xv flag puts multixterm into a verbose mode where
it will describe some of the things it is doing internally.
The verbose output is not intended to be understandable to any-
one but the author.
Less common options may be changed by the startup file (see FILES below).
All the usual X and wish flags are supported (i.e., -display, -name).
There are so many of them that to avoid colliding and make them easy to
remember, all the multixterm flags begin with -x.
If any arguments do not match the flags above, the remainder of the com-
mand line is made available for user processing. By default, the remain-
der is used as a list of xterm names in the style of -xn. The default be-
havior may be changed using the .multixtermrc file (see DOT FILE below).
EXAMPLE COMMAND LINE ARGUMENTS
The following command line starts up two xterms using ssh to the hosts bud
and dexter.
multixterm -xc "ssh %n" bud dexter
FILES
Command files may be used to drive or initialize multixterm. The File
menu may be used to invoke other files. If files exist in the command
file directory (see -xd above), they will appear in the File menu. Files
may also be loaded by using File->Open. Any filename is acceptable but
the File->Open browser defaults to files with a .mxt suffix.
Files are written in Tcl and may change any variables or invoke any proce-
dures. The primary variables of interest are 'xtermCmd' which identifies
the command (see -xc) and 'xtermNames' which is a list of names (see -xn).
The procedure xtermStartAll, starts xterms for each name in the list.
Other variables and procedures may be discovered by examining multixterm
itself.
EXAMPLE FILE
The following file does the same thing as the earlier example command
line:
# start two xterms connected to bud and dexter
set xtermCmd "ssh %n"
set xtermNames {bud dexter}
xtermStartAll
DOT FILE
At startup, multixterm reads ~/.multixtermrc if present. This is similar
to the command files (see FILES above) except that .multixtermrc may not
call xtermStartAll. Instead it is called implicitly, similar to the way
that it is implicit in the command line use of -xn.
The following example .multixtermrc file makes every xterm run ssh to the
hosts named on the command line.
set xtermCmd "ssh %n"
Then multixterm could be called simply:
multixterm bud dexter
If any command-line argument does not match a multixterm flag, the remain-
der of the command line is made available to .multixtermrc in the argv
variable. If argv is non-empty when .multixtermrc returns, it is assigned
to xtermNames unless xtermNames is non-empty in which case, the content of
argv is ignored.
Commands from multixterm are evaluated early in the initialization of mul-
tixterm. Anything that must be done late in the initialization (such as
adding additional bindings to the user interface) may be done by putting
the commands inside a procedure called "initLate".
MENUS
Except as otherwise noted, the menus are self-explanatory. Some of the
menus have dashed lines as the first entry. Clicking on the dashed lines
will "tear off" the menus.
USAGE SUGGESTION - ALIASES AND COMMAND FILES
Aliases may be used to store lengthy command-line invocations. Command
files can be also be used to store such invocations as well as providing a
convenient way to share configurations.
Tcl is a general-purpose language. Thus multixterm command files can be
extremely flexible, such as loading hostnames from other programs or files
that may change from day-to-day. In addition, command files can be used
for other purposes. For example, command files may be used to prepared
common canned interaction sequences. For example, the command to send the
same string to all xterms is:
xtermSend "a particularly long string"
The File menu (torn-off) makes canned sequences particularly convenient.
Interactions could also be bound to a mouse button, keystroke, or added to
a menu via the .multixtermrc file.
The following .multixtermrc causes tiny xterms to tile across and down the
screen. (You may have to adjust the parameters for your screen.) This
can be very helpful when dealing with large numbers of xterms.
set yPos 0
set xPos 0
trace add variable xtermArgs {read} traceArgs
proc traceArgs {args} {
global xPos yPos
set ::xtermArgs "-geometry 80x12+$xPos+$yPos -font 6x10"
if {$xPos} {
set xPos 0
incr yPos 145
if {$yPos > 800} {set yPos 0}
} else {
set xPos 500
}
}
The xtermArgs variable in the code above is the variable corresponding to
the -xa argument.
xterms can be also be created directly. The following command file cre-
ates three xterms overlapped horizontally:
set xPos 0
foreach name {bud dexter hotdog} {
set ::xtermArgs "-geometry 80x12+$xPos+0 -font 6x10"
set ::xtermNames $name
xtermStartAll
incr xPos 300
}
USAGE SUGGESTION - SELECTING HOSTS BY NICKNAME
The following .multixtermrc shows an example of changing the default han-
dling of the arguments from hostnames to a filename containing hostnames:
set xtermNames [exec cat $argv]
The following is a variation, retrieving the host names from the yp data-
base:
set xtermNames [exec ypcat $argv]
The following hardcodes two sets of hosts, so that you can call multixterm
with either "cluster1" or "cluster2":
switch $argv {
cluster1 {
set xtermNames "bud dexter"
}
cluster2 {
set xtermNames "frank hotdog weiner"
}
}
COMPARE/CONTRAST
It is worth comparing multixterm to xkibitz. Multixterm connects a sepa-
rate process to each xterm. xkibitz connects the same process to each
xterm.
LIMITATIONS
Multixterm provides no way to remotely control scrollbars, resize, and
most other window system related functions.
Because xterm has no mechanism for propagating size information to exter-
nal processes, particularly for character graphic applications (e.g., vi,
emacs), you may have to manually ensure that the spawned process behind
each xterm has the correct size. For example, if you create or set the
xterm to a size, you may have to send an explicit stty command with the
correct size to the spawned process(es). Alternatively, you can add the
correct size argument when an xterm is created (i.e., "-geometry 80x20").
Multixterm can only control new xterms that multixterm itself has started.
As a convenience, the File menu shows a limited number of files. To show
all the files, use File->Open.
FILES
$DOTDIR/.multixtermrc initial command file
~/.multixtermrc fallback command file
~/lib/multixterm/ default command file directory
BUGS
If multixterm is killed using an uncatchable kill, the xterms are not
killed. This appears to be a bug in xterm itself.
Send/expect sequences can be done in multixterm command files. However,
due to the richness of the possibilities, to document it properly would
take more time than the author has at present.
REQUIREMENTS
Requires Expect 5.36.0 or later.
Requires Tk 8.3.3 or later.
VERSION
This man page describes version 1.8 of multixterm.
The latest version of multixterm is available from http://ex-
pect.nist.gov/example/multixterm . If your version of Expect and Tk are
too old (see REQUIREMENTS above), download a new version of Expect from
http://expect.nist.gov
DATE
April 30, 2002
AUTHOR
Don Libes <[email protected]>
LICENSE
Multixterm is in the public domain; however the author would appreciate
acknowledgement if multixterm or parts of it or ideas from it are used.
16 August 2002 MULTIXTERM(1)
expect_passmass
Change password on multiple machines
root@kali:~# man expect_passmass
PASSMASS(1) General Commands Manual PASSMASS(1)
NAME
passmass - change password on multiple machines
SYNOPSIS
passmass [ host1 host2 host3 ... ]
INTRODUCTION
Passmass changes a password on multiple machines. If you have accounts on
several machines that do not share password databases, Passmass can help
you keep them all in sync. This, in turn, will make it easier to change
them more frequently.
When Passmass runs, it asks you for the old and new passwords. (If you
are changing root passwords and have equivalencing, the old password is
not used and may be omitted.)
Passmass understands the "usual" conventions. Additional arguments may be
used for tuning. They affect all hosts which follow until another argu-
ment overrides it. For example, if you are known as "libes" on host1 and
host2, but "don" on host3, you would say:
passmass host1 host2 -user don host3
Arguments are:
-user
User whose password will be changed. By default, the current
user is used.
-rlogin
Use rlogin to access host. (default)
-slogin
Use slogin to access host.
-ssh
Use ssh to access host.
-telnet
Use telnet to access host.
-program
Next argument is a program to run to set the password. Default
is "passwd". Other common choices are "yppasswd" and "set
passwd" (e.g., VMS hosts). A program name such as "password
fred" can be used to create entries for new accounts (when run
as root).
-prompt
Next argument is a prompt suffix pattern. This allows the
script to know when the shell is prompting. The default is "#
" for root and "% " for non-root accounts.
-timeout
Next argument is the number of seconds to wait for responses.
Default is 30 but some systems can be much slower logging in.
-su
Next argument is 1 or 0. If 1, you are additionally prompted
for a root password which is used to su after logging in.
root's password is changed rather than the user's. This is
useful for hosts which do not allow root to log in.
HOW TO USE
The best way to run Passmass is to put the command in a one-line shell
script or alias. Whenever you get a new account on a new machine, add the
appropriate arguments to the command. Then run it whenever you want to
change your passwords on all the hosts.
CAVEATS
Using the same password on multiple hosts carries risks. In particular,
if the password can be stolen, then all of your accounts are at risk.
Thus, you should not use Passmass in situations where your password is
visible, such as across a network which hackers are known to eavesdrop.
On the other hand, if you have enough accounts with different passwords,
you may end up writing them down somewhere - and that can be a security
problem. Funny story: my college roommate had an 11"x13" piece of paper
on which he had listed accounts and passwords all across the Internet.
This was several years worth of careful work and he carried it with him
everywhere he went. Well one day, he forgot to remove it from his jeans,
and we found a perfectly blank sheet of paper when we took out the wash
the following day!
SEE ALSO
"Exploring Expect: A Tcl-Based Toolkit for Automating Interactive Pro-
grams" by Don Libes, O'Reilly and Associates, January 1995.
AUTHOR
Don Libes, National Institute of Standards and Technology
7 October 1993 PASSMASS(1)
expect_rftp
root@kali:~# expect_rftp -h
Once logged in, cd to the directory to be transferred and press:
~p to put the current directory from the local to the remote host
~g to get the current directory from the remote host to the local host
~l to list the current directory from the remote host
spawn ftp -h
expect_rlogin-cwd
root@kali:~# expect_rlogin-cwd -h
spawn rlogin -h
rlogin: invalid option -- 'h'
rlogin: Unknown option!
Usage: rlogin [-46v] [-l user] [-p port] [user@]host
expect_timed-read
expect_timed-run
root@kali:~# expect_timed-run -h
usage: spawn [spawn-args] program [program-args]
while executing
"spawn"
("eval" body line 1)
invoked from within
"eval spawn [lrange $argv 1 end]"
(file "/usr/bin/expect_timed-run" line 12)
expect_tknewsbiff
Pop up a window when news appears
root@kali:~# man expect_tknewsbiff
TKNEWSBIFF(1) General Commands Manual TKNEWSBIFF(1)
NAME
tknewsbiff - pop up a window when news appears
SYNOPSIS
tknewsbiff [ server or config-file ]
INTRODUCTION
tknewsbiff pops up a window when there is unread news in your favorite
newsgroups and removes the window after you've read the news. tknewsbiff
can optionally play a sound, start your newsreader, etc.
SELECTING NEWSGROUPS
By default, the configuration file ~/.tknewsbiff describes how tknewsbiff
behaves. The syntax observes the usual Tcl rules - however, even if you
don't know Tcl, all but the most esoteric configurations will be obvious.
Each newsgroup (or set of newsgroups) to be watched is described by using
the "watch" command. For example:
watch dc.dining
watch nist.*
watch comp.unix.wizard -threshold 3
watch *.sources.* -threshold 20
For each newsgroup pattern, any newsgroup that matches it and which you
are subscribed to (according to your newsrc file) is eligible for report-
ing. By default, tknewsbiff reports on the newsgroup if there is at least
one unread article. The "-threshold" flag changes the threshold to the
following number. For example, "-threshold 3" means there must be at
least three articles unread before tknewsbiff will report the newsgroup.
If no watch commands are given (or no configuration file exists), all
groups which are subscribed to are watched.
To suppress newsgroups that would otherwise be reported, use the "ignore"
command. For example, the following matches all comp.* and nist.* new-
groups except for nist.posix or .d (discussion) groups:
watch comp.*
watch nist.*
ignore nist.posix.*
ignore *.d
The flag "-new" describes a command to be executed when the newsgroup is
first reported as having unread news. For example, the following lines
invoke the UNIX command "play" to play a sound.
watch dc.dining -new "exec play /usr/local/sounds/yumyum.au"
watch rec.auto* -new "exec play /usr/local/sounds/vroom.au"
You can cut down on the verbosity of actions by defining procedures. For
example, if you have many -new flags that all play sound files, you could
define a sound procedure. This would allow the -new specification to be
much shorter.
proc play {sound} {
exec play /usr/local/sounds/$sound.au
}
watch dc.dining -new "play yumyum"
watch rec.auto* -new "play vroom"
As an aside, you can put an "&" at the end of an "exec" command to get
commands to execute asynchronously. However, it's probably not a good
idea to do this when playing sound files anyway.
"newsgroup" is a read-only variable which contains the name of the news-
group that is being reported. This is useful when the action is triggered
by a pattern. For example, the following line could run the newsgroup
name through a speech synthesizer:
watch * -new {
exec play herald.au
exec speak "New news has arrived in $newsgroup."
}
The flag "-display" describes a command to be executed every time the
newsgroup is reported as having unread news. The special command "dis-
play" is the default command. It schedules $newsgroup to be written to
tknewsbiff's display when it is rewritten. For example, by explicitly
providing a -display flag that omits the display command, you can disable
the display of newsgroups that are already reported via -new.
watch dc.dining -new {exec play yumyum.au} -display {}
If you want to execute an action repeatedly and still display the news-
group in the default manner, explicitly invoke the display command via the
-display flag. For example:
watch *security* -display {
exec play red-alert.au
display
}
Actions associated with the -new and -display flags are executed only once
for each matching newsgroup. The command executed is the one associated
with the first pattern in the configuration file that matches and observes
the given threshold.
Any command that is simply listed in the configuration file is executed
each time before the update loop in tknewsbiff. The reserved (but user-
defined) procedure "user" is run immediately after the newsgroups are
scheduled to be written to the display and before they are actually writ-
ten.
For example, suppose unread articles appear in several rec.auto groups and
you play the same sound for each one. To prevent playing the sound sev-
eral times in a row, make the -new command simply set a flag. In the user
procedure, play the sound if the flag is set (and then reset the flag).
The user procedure could also be used to start a newsreader. This would
avoid the possibility of starting multiple newsreaders just because multi-
ple newsgroups contained unread articles. (A check should, of course, be
made to make sure that a newsreader is not already running.)
MORE VARIABLES
The following example lines show variables that can affect the behavior of
tknewsbiff
set delay 120
set server news.nist.gov
set server_timeout 60
set newsrc ~/.newsrc
set width 40
set height 20
set active_file /usr/news/lib/active
tknewsbiff alternates between checking for unread news and sleeping (kind
of like many undergraduates). The "delay" variable describes how many
seconds to sleep.
The "server" variable names an NNTP news-server. The default is "news".
The "server" variable is only used if the "active_file" variable is not
set.
The "server_timeout" variable describes how how many seconds to wait for a
response from the server before giving up. -1 means wait forever or until
the server itself times out. The default is 60 seconds.
The "newsrc" variable describes the name of your .newsrc file. By de-
fault, tknewsbiff looks in your home directory for a newsrc file. A
server-specific newsrc is used if found. For example, if you have set
server to "cubit.nist.gov", then tknewsbiff looks for ~/.newsrc-cu-
bit.nist.gov. (This is the Emacs gnus convention - which is very conve-
nient when you read news from multiple servers.) If there is no server-
specific newsrc, tknewsbiff uses ~/.newsrc.
The "width" variable describes the width that tknewsbiff will use to dis-
play information. If any newsgroup names are long enough, they will be
truncated so that the article counts can still be shown. You can manually
resize the window to see what was truncated. However, if your configura-
tion file sets the width variable, the window will be restored to that
size the next time that tknewsbiff checks for unread news and updates its
display.
The "height" variable describes the maximum height that tknewsbiff will
use to display information. If fewer newsgroups are reported, tknewsbiff
will shrink the window appropriately. You can manually resize the window
but if your configuration file sets the height variable, the window will
be restored to that size the next time that tknewsbiff checks for unread
news and updates its display.
The "active_file" variable describes the name of the news active file. If
set, the active file is read directly in preference to using NNTP (even if
the "server" variable is set). This is particularly useful for testing
out new configuration files since you can edit a fake active file and then
click button 2 to immediately see how tknewsbiff responds (see BUTTONS be-
low).
If the environment variable DOTDIR is set, then its value is used as a di-
rectory in which to find all dotfiles instead of from the home directory.
In particular, this affects the tknewsbiff configuration file and the
.newsrc file (assuming the newsrc variable is not set explicitly).
WATCHING DIFFERENT NEWS SERVERS
To watch multiple servers, run tknewsbiff multiple times. (Since you need
different .newsrc files and the servers have different newsgroups and ar-
ticle numbers anyway, there is no point in trying to do this in a single
process.)
You can point tknewsbiff at a different server with an appropriate argu-
ment. The argument is tried both as a configuration file name and as a
suffix to the string "~/.tknewsbiff-". So if you want to watch the server
"kidney", store the tknewsbiff configuration information in ~/.tknewsbiff-
kidney". The following two commands will both use that configuration
file.
tknewsbiff kidney
tknewsbiff ~/.tknewsbiff-kidney
In both cases, the actual server to contact is set by the value of the
server variable in the configuration file.
If no configuration file is found, the argument is used as the server to
contact. This allows tknewsbiff to be run with no preparation whatsoever.
If the argument is the special keyword "active" (or ends in "/active"), it
is used as the name of an active file. This is in turn used to initialize
the variable "active_file" so that tknewsbiff reads from the active file
directly rather than using NNTP.
Creating your own active file is a convenient way of testing your configu-
ration file. For example, after running the following command, you can
repeatedly edit your active file and trigger the update-now command (ei-
ther by pressing button 2 or setting the delay variable very low) to see
how tknewsbiff responds.
The active file must follow the format of a real active file. The format
is one newsgroup per line. After the newsgroup name is the number of the
highest article, the lowest article. Lastly is the letter y or m. m
means the newsgroup is moderated. y means posting is allowed.
WINDOW
When unread news is found, a window is popped up. The window lists the
names of the newsgroups and the number of unread articles in each (unless
suppressed by the -display flag). When there is no longer any unread
news, the window disappears (although the process continues to run).
BUTTONS
Button or key bindings may be assigned by bind commands. Feel free to
change them. The default bind commands are:
bind .list <1> help
bind .list <2> update-now
bind .list <3> unmapwindow
By default button 1 (left) is bound to "help". The help command causes
tknewsbiff to pop up a help window.
By default, button 2 (middle) is bound to "update-now". The update-now
command causes tknewsbiff to immediately check for unread news. If your
news server is slow or maintains a very large number of newsgroups, or you
have a large number of patterns in your configuration file, tknewsbiff can
take considerable time before actually updating the window.
By default, button 3 (right) is bound to "unmapwindow". The unmapwindow
command causes tknewsbiff to remove the window from the display until the
next time it finds unread news. (The mapwindow command causes tknewsbiff
to restore the window.)
As an example, here is a binding to pop up an xterm and run rn when you
hold down the shift key and press button 1 in the listing window.
bind .list <Shift-1> {
exec xterm -e rn &
}
Here is a similar binding. However it tells rn to look only at the news-
group that is under the mouse when you pressed it. (The "display_list"
variable is described later in this man page.)
bind .list <Shift-1> {
exec xterm -e rn [lindex $display_list [.list nearest %y]] &
}
OTHER COMMANDS AND VARIABLES
Built-in commands already mentioned are: watch, ignore, display, help, up-
date-now, unmapwindow, and mapwindow.
Any Tcl and Tk command can also be given. In particular, the list of
newsgroups is stored in the list widget ".list", and the scroll bar is
stored in the scrollbar widget ".scroll". So for example, if you want to
change the foreground and background colors of the newsgroup list, you can
say:
.list config -bg honeydew1 -fg orchid2
These can also be controlled by the X resource database as well. However,
the configuration file allows arbitrarily complex commands to be evaluated
rather than simple assignments.
Certain Tcl/Tk commands can disrupt proper function of tknewsbiff. These
will probably be obvious to anyone who knows enough to give these commands
in the first place. As a simple example, the program assumes the font in
the list box is of fixed width. The newsgroups will likely not align if
you use a variable-width font.
The following variables are accessible and can be used for esoteric uses.
All other variables are private. Private variables and commands begin
with "_" so you don't need to worry about accidental collisions.
The array "db" is a database which maintains information about read and
unread news. db($newsgroup,hi) is the highest article that exists.
db($newsgroup,seen) is the highest article that you have read.
A number of lists maintain interesting information. "active_list" is a
list of known newsgroups. "seen_list" is a list of newsgroups that have
been seen so far as the -new and -display flags are being processed.
"previous_seen_list" is "seen_list" from the previous cycle. "ig-
nore_list" is the list of newsgroup patterns to ignore. "watch_list" is
the list of newsgroup patterns to watch. "display_list" is the list of
newsgroup will be displayed at the next opportunity.
UPDATING YOUR FILES
tknewsbiff automatically rereads your configuration file each time it
wakes up to check for unread news. To force tknewsbiff to reread the file
immediately (such as if you are testing a new configuration or have just
modified your newsrc file), press button 2 in the display (see BUTTONS
above).
CAVEATS
tknewsbiff defines the number of unread articles as the highest existing
article minus the highest article that you've read. So if you've read the
last article in the newsgroup but no others, tknewsbiff thinks there are
no unread articles. (It's impossible to do any better by reading the ac-
tive file and it would be very time consuming to do this more accurately
via NNTP since servers provide no efficient way of reporting their own
holes in the newsgroups.) Fortunately, this definition is considered a
feature by most people. It allows you to read articles and then mark them
"unread" but not have tknewsbiff continue telling you that they are un-
read.
UNWARRANTED CONCERNS
Your news administrator may wonder if many people using tknewsbiff se-
verely impact an NNTP server. In fact, the impact is negligible even when
the delay is very low. To gather all the information it needs, tknewsbiff
uses a single NNTP query - it just asks for the active file. The NNTP
server does no computation, formatting, etc, it just sends the file. All
the interesting processing happens locally in the tknewsbiff program it-
self.
BUGS
The man page is longer than the program.
SEE ALSO
"Exploring Expect: A Tcl-Based Toolkit for Automating Interactive Pro-
grams" by Don Libes, O'Reilly and Associates, January 1995.
AUTHOR
Don Libes, National Institute of Standards and Technology
1 January 1994 TKNEWSBIFF(1)
expect_tkpasswd
expect_unbuffer
Unbuffer output
root@kali:~# expect_unbuffer -h
bad flag "-h": must be -console, -ignore, -leaveopen, -noecho, -nottycopy, -nottyinit, -open, or -pty
while executing
"spawn -noecho -h"
("eval" body line 1)
invoked from within
"eval [list spawn -noecho] $argv"
invoked from within
"if {[string compare [lindex $argv 0] "-p"] == 0} {
# pipeline
set stty_init "-echo"
eval [list spawn -noecho] [lrange $argv 1 end]
clo..."
(file "/usr/bin/expect_unbuffer" line 13)
expect_weather
root@kali:~# expect_weather -h
spawn telnet rainmaker.wunderground.com 3000
Server lookup failure: rainmaker.wunderground.com:3000, Name or service not known
failed to telnet to weather server
expect_xkibitz
Allow multiple people to interact in an xterm
root@kali:~# expect_xkibitz -h
bad flag "-h": must be -console, -ignore, -leaveopen, -noecho, -nottycopy, -nottyinit, -open, or -pty
while executing
"spawn -noecho -h"
("eval" body line 1)
invoked from within
"eval spawn -noecho $argv"
invoked from within
"if {[llength $argv]>0} {
eval spawn -noecho $argv
} else {
spawn -noecho $env(SHELL)
}"
(file "/usr/bin/expect_xkibitz" line 201)
expect_xpstat
kibitz
Allow two people to interact with one shell
root@kali:~# man kibitz
KIBITZ(1) General Commands Manual KIBITZ(1)
NAME
kibitz - allow two people to interact with one shell
SYNOPSIS
kibitz [ kibitz-args ] user [ program program-args... ]
kibitz [ kibitz-args ] user@host [ program program-args... ]
INTRODUCTION
kibitz allows two (or more) people to interact with one shell (or any ar-
bitrary program). Uses include:
* A novice user can ask an expert user for help. Using kibitz,
the expert can see what the user is doing, and offer advice or
show how to do it right.
* By running kibitz and then starting a full-screen editor, peo-
ple may carry out a conversation, retaining the ability to
scroll backwards, save the entire conversation, or even edit it
while in progress.
* People can team up on games, document editing, or other cooper-
ative tasks where each person has strengths and weaknesses that
complement one another.
USAGE
To start kibitz, user1 runs kibitz with the argument of the user to kib-
itz. For example:
kibitz user2
kibitz starts a new shell (or another program, if given on the command
line), while prompting user2 to run kibitz. If user2 runs kibitz as di-
rected, the keystrokes of both users become the input of the shell. Simi-
larly, both users receive the output from the shell.
To terminate kibitz it suffices to terminate the shell itself. For exam-
ple, if either user types ^D (and the shell accepts this to be EOF), the
shell terminates followed by kibitz.
Normally, all characters are passed uninterpreted. However, if the escape
character (described when kibitz starts) is issued, the user may talk di-
rectly to the kibitz interpreter. Any Expect(1) or Tcl(3) commands may be
given. Also, job control may be used while in the interpreter, to, for
example, suspend or restart kibitz.
Various processes can provide various effects. For example, you can emu-
late a two-way write(1) session with the command:
kibitz user2 sleep 1000000
ARGUMENTS
kibitz takes arguments, these should also be separated by whitespace.
The -noproc flag runs kibitz with no process underneath. Characters are
passed to the other kibitz. This is particularly useful for connecting
multiple interactive processes together. In this mode, characters are not
echoed back to the typist.
-noescape disables the escape character.
-escape char sets the escape character. The default escape character is
^].
-silent turns off informational messages describing what kibitz is doing
to initiate a connection.
-tty ttyname defines the tty to which the invitation should be sent.
If you start kibitz to user2 on a remote computer, kibitz performs a
rlogin to the remote computer with your current username. The flag -proxy
username causes rlogin to use username for the remote login (e.g. if your
account on the remote computer has a different username). If the -proxy
flag is not given, kibitz tries to determine your current username by (in
that order) inspecting the environment variables USER and LOGNAME, then by
using the commands whoami and logname.
The arguments -noescape and -escape can also be given by user2 when
prompted to run kibitz.
MORE THAN TWO USERS
The current implementation of kibitz explicitly understands only two
users, however, it is nonetheless possible to have a three (or more) -way
kibitz, by kibitzing another kibitz. For example, the following command
runs kibitz with the current user, user2, and user3:
% kibitz user2 kibitz user3
Additional users may be added by simply appending more "kibitz user" com-
mands.
The xkibitz script is similar to kibitz but supports the ability to add
additional users (and drop them) dynamically.
CAVEATS
kibitz assumes the 2nd user has the same terminal type and size as the 1st
user. If this assumption is incorrect, graphical programs may display
oddly.
kibitz handles character graphics, but cannot handle bitmapped graphics.
Thus,
% xterm -e kibitz will work
% kibitz xterm will not work
However, you can get the effect of the latter command by using xkibitz
(see SEE ALSO below). kibitz uses the same permissions as used by rlogin,
rsh, etc. Thus, you can only kibitz to users at hosts for which you can
rlogin. Similarly, kibitz will prompt for a password on the remote host
if rlogin would.
If you kibitz to users at remote hosts, kibitz needs to distinguish your
prompt from other things that may precede it during login. (Ideally, the
end of it is preferred but any part should suffice.) If you have an un-
usual prompt, set the environment variable EXPECT_PROMPT to an
egrep(1)-style regular expression. Brackets should be preceded with one
backslash in ranges, and three backslashes for literal brackets. The de-
fault prompt r.e. is "($|%|#) ".
kibitz requires the kibitz program on both hosts. kibitz requires ex-
pect(1).
By comparison, the xkibitz script uses the X authorization mechanism for
inter-host communication so it does not need to login, recognize your
prompt, or require kibitz on the remote host. It does however need per-
mission to access the other X servers.
BUGS
An early version of Sun's tmpfs had a bug in it that causes kibitz to blow
up. If kibitz reports "error flushing ...: Is a directory" ask Sun for
patch #100174.
If your Expect is not compiled with multiple-process support (i.e., you do
not have a working select or poll), you will not be able to run kibitz.
ENVIRONMENT
The environment variable SHELL is used to determine the shell to start, if
no other program is given on the command line.
If the environment variable EXPECT_PROMPT exists, it is taken as a regular
expression which matches the end of your login prompt (but does not other-
wise occur while logging in). See also CAVEATS above.
If the environment variables USER or LOGNAME are defined, they are used to
determine the current user name for a kibitz to a remote computer. See de-
scription of the -proxy option in ARGUMENTS above.
SEE ALSO
Tcl(3), libexpect(3), xkibitz(1)
"Exploring Expect: A Tcl-Based Toolkit for Automating Interactive Pro-
grams" by Don Libes, O'Reilly and Associates, January 1995.
"Kibitz - Connecting Multiple Interactive Programs Together", by Don
Libes, Software - Practice & Experience, John Wiley & Sons, West Sussex,
England, Vol. 23, No. 5, May, 1993.
AUTHOR
Don Libes, National Institute of Standards and Technology
kibitz is in the public domain. NIST and I would appreciate credit if
this program or parts of it are used.
19 October 1994 KIBITZ(1)
lpunlock
root@kali:~# lpunlock -h
spawn ed /etc/printcap
multixterm
Drive multiple xterms separately or together
root@kali:~# man multixterm
MULTIXTERM(1) General Commands Manual MULTIXTERM(1)
NAME
multixterm - drive multiple xterms separately or together
SYNOPSIS
multixterm [ args ]
DESCRIPTION
Multixterm creates multiple xterms that can be driven together or sepa-
rately.
In its simplest form, multixterm is run with no arguments and commands are
interactively entered in the first entry field. Press return (or click
the "new xterm" button) to create a new xterm running that command.
Keystrokes in the "stdin window" are redirected to all xterms started by
multixterm. xterms may be driven separately simply by focusing on them.
The stdin window must have the focus for keystrokes to be sent to the
xterms. When it has the focus, the color changes to aquamarine. As char-
acters are entered, the color changes to green for a second. This pro-
vides feedback since characters are not echoed in the stdin window.
Typing in the stdin window while holding down the alt or meta keys sends
an escape character before the typed characters. This provides support
for programs such as emacs.
ARGUMENTS
-xa
The optional -xa argument indicates arguments to pass to xterm.
-xc
The optional -xc argument indicates a command to be run in each
named xterm (see -xn). With no -xc argument, the command is
the current shell.
-xd
The optional -xd argument indicates a directory to search for
files that will appear in the Files menu. By default, the di-
rectory is: ~/lib/multixterm
-xf
The optional -xf argument indicates a file to be read at
startup. See FILES below for more info.
-xn
The optional -xn argument indicates a name for each xterm.
This name will also be substituted for any %n in the command
argument (see -xc).
-xv
The optional -xv flag puts multixterm into a verbose mode where
it will describe some of the things it is doing internally.
The verbose output is not intended to be understandable to any-
one but the author.
Less common options may be changed by the startup file (see FILES below).
All the usual X and wish flags are supported (i.e., -display, -name).
There are so many of them that to avoid colliding and make them easy to
remember, all the multixterm flags begin with -x.
If any arguments do not match the flags above, the remainder of the com-
mand line is made available for user processing. By default, the remain-
der is used as a list of xterm names in the style of -xn. The default be-
havior may be changed using the .multixtermrc file (see DOT FILE below).
EXAMPLE COMMAND LINE ARGUMENTS
The following command line starts up two xterms using ssh to the hosts bud
and dexter.
multixterm -xc "ssh %n" bud dexter
FILES
Command files may be used to drive or initialize multixterm. The File
menu may be used to invoke other files. If files exist in the command
file directory (see -xd above), they will appear in the File menu. Files
may also be loaded by using File->Open. Any filename is acceptable but
the File->Open browser defaults to files with a .mxt suffix.
Files are written in Tcl and may change any variables or invoke any proce-
dures. The primary variables of interest are 'xtermCmd' which identifies
the command (see -xc) and 'xtermNames' which is a list of names (see -xn).
The procedure xtermStartAll, starts xterms for each name in the list.
Other variables and procedures may be discovered by examining multixterm
itself.
EXAMPLE FILE
The following file does the same thing as the earlier example command
line:
# start two xterms connected to bud and dexter
set xtermCmd "ssh %n"
set xtermNames {bud dexter}
xtermStartAll
DOT FILE
At startup, multixterm reads ~/.multixtermrc if present. This is similar
to the command files (see FILES above) except that .multixtermrc may not
call xtermStartAll. Instead it is called implicitly, similar to the way
that it is implicit in the command line use of -xn.
The following example .multixtermrc file makes every xterm run ssh to the
hosts named on the command line.
set xtermCmd "ssh %n"
Then multixterm could be called simply:
multixterm bud dexter
If any command-line argument does not match a multixterm flag, the remain-
der of the command line is made available to .multixtermrc in the argv
variable. If argv is non-empty when .multixtermrc returns, it is assigned
to xtermNames unless xtermNames is non-empty in which case, the content of
argv is ignored.
Commands from multixterm are evaluated early in the initialization of mul-
tixterm. Anything that must be done late in the initialization (such as
adding additional bindings to the user interface) may be done by putting
the commands inside a procedure called "initLate".
MENUS
Except as otherwise noted, the menus are self-explanatory. Some of the
menus have dashed lines as the first entry. Clicking on the dashed lines
will "tear off" the menus.
USAGE SUGGESTION - ALIASES AND COMMAND FILES
Aliases may be used to store lengthy command-line invocations. Command
files can be also be used to store such invocations as well as providing a
convenient way to share configurations.
Tcl is a general-purpose language. Thus multixterm command files can be
extremely flexible, such as loading hostnames from other programs or files
that may change from day-to-day. In addition, command files can be used
for other purposes. For example, command files may be used to prepared
common canned interaction sequences. For example, the command to send the
same string to all xterms is:
xtermSend "a particularly long string"
The File menu (torn-off) makes canned sequences particularly convenient.
Interactions could also be bound to a mouse button, keystroke, or added to
a menu via the .multixtermrc file.
The following .multixtermrc causes tiny xterms to tile across and down the
screen. (You may have to adjust the parameters for your screen.) This
can be very helpful when dealing with large numbers of xterms.
set yPos 0
set xPos 0
trace add variable xtermArgs {read} traceArgs
proc traceArgs {args} {
global xPos yPos
set ::xtermArgs "-geometry 80x12+$xPos+$yPos -font 6x10"
if {$xPos} {
set xPos 0
incr yPos 145
if {$yPos > 800} {set yPos 0}
} else {
set xPos 500
}
}
The xtermArgs variable in the code above is the variable corresponding to
the -xa argument.
xterms can be also be created directly. The following command file cre-
ates three xterms overlapped horizontally:
set xPos 0
foreach name {bud dexter hotdog} {
set ::xtermArgs "-geometry 80x12+$xPos+0 -font 6x10"
set ::xtermNames $name
xtermStartAll
incr xPos 300
}
USAGE SUGGESTION - SELECTING HOSTS BY NICKNAME
The following .multixtermrc shows an example of changing the default han-
dling of the arguments from hostnames to a filename containing hostnames:
set xtermNames [exec cat $argv]
The following is a variation, retrieving the host names from the yp data-
base:
set xtermNames [exec ypcat $argv]
The following hardcodes two sets of hosts, so that you can call multixterm
with either "cluster1" or "cluster2":
switch $argv {
cluster1 {
set xtermNames "bud dexter"
}
cluster2 {
set xtermNames "frank hotdog weiner"
}
}
COMPARE/CONTRAST
It is worth comparing multixterm to xkibitz. Multixterm connects a sepa-
rate process to each xterm. xkibitz connects the same process to each
xterm.
LIMITATIONS
Multixterm provides no way to remotely control scrollbars, resize, and
most other window system related functions.
Because xterm has no mechanism for propagating size information to exter-
nal processes, particularly for character graphic applications (e.g., vi,
emacs), you may have to manually ensure that the spawned process behind
each xterm has the correct size. For example, if you create or set the
xterm to a size, you may have to send an explicit stty command with the
correct size to the spawned process(es). Alternatively, you can add the
correct size argument when an xterm is created (i.e., "-geometry 80x20").
Multixterm can only control new xterms that multixterm itself has started.
As a convenience, the File menu shows a limited number of files. To show
all the files, use File->Open.
FILES
$DOTDIR/.multixtermrc initial command file
~/.multixtermrc fallback command file
~/lib/multixterm/ default command file directory
BUGS
If multixterm is killed using an uncatchable kill, the xterms are not
killed. This appears to be a bug in xterm itself.
Send/expect sequences can be done in multixterm command files. However,
due to the richness of the possibilities, to document it properly would
take more time than the author has at present.
REQUIREMENTS
Requires Expect 5.36.0 or later.
Requires Tk 8.3.3 or later.
VERSION
This man page describes version 1.8 of multixterm.
The latest version of multixterm is available from http://ex-
pect.nist.gov/example/multixterm . If your version of Expect and Tk are
too old (see REQUIREMENTS above), download a new version of Expect from
http://expect.nist.gov
DATE
April 30, 2002
AUTHOR
Don Libes <[email protected]>
LICENSE
Multixterm is in the public domain; however the author would appreciate
acknowledgement if multixterm or parts of it or ideas from it are used.
16 August 2002 MULTIXTERM(1)
passmass
Change password on multiple machines
root@kali:~# man passmass
PASSMASS(1) General Commands Manual PASSMASS(1)
NAME
passmass - change password on multiple machines
SYNOPSIS
passmass [ host1 host2 host3 ... ]
INTRODUCTION
Passmass changes a password on multiple machines. If you have accounts on
several machines that do not share password databases, Passmass can help
you keep them all in sync. This, in turn, will make it easier to change
them more frequently.
When Passmass runs, it asks you for the old and new passwords. (If you
are changing root passwords and have equivalencing, the old password is
not used and may be omitted.)
Passmass understands the "usual" conventions. Additional arguments may be
used for tuning. They affect all hosts which follow until another argu-
ment overrides it. For example, if you are known as "libes" on host1 and
host2, but "don" on host3, you would say:
passmass host1 host2 -user don host3
Arguments are:
-user
User whose password will be changed. By default, the current
user is used.
-rlogin
Use rlogin to access host. (default)
-slogin
Use slogin to access host.
-ssh
Use ssh to access host.
-telnet
Use telnet to access host.
-program
Next argument is a program to run to set the password. Default
is "passwd". Other common choices are "yppasswd" and "set
passwd" (e.g., VMS hosts). A program name such as "password
fred" can be used to create entries for new accounts (when run
as root).
-prompt
Next argument is a prompt suffix pattern. This allows the
script to know when the shell is prompting. The default is "#
" for root and "% " for non-root accounts.
-timeout
Next argument is the number of seconds to wait for responses.
Default is 30 but some systems can be much slower logging in.
-su
Next argument is 1 or 0. If 1, you are additionally prompted
for a root password which is used to su after logging in.
root's password is changed rather than the user's. This is
useful for hosts which do not allow root to log in.
HOW TO USE
The best way to run Passmass is to put the command in a one-line shell
script or alias. Whenever you get a new account on a new machine, add the
appropriate arguments to the command. Then run it whenever you want to
change your passwords on all the hosts.
CAVEATS
Using the same password on multiple hosts carries risks. In particular,
if the password can be stolen, then all of your accounts are at risk.
Thus, you should not use Passmass in situations where your password is
visible, such as across a network which hackers are known to eavesdrop.
On the other hand, if you have enough accounts with different passwords,
you may end up writing them down somewhere - and that can be a security
problem. Funny story: my college roommate had an 11"x13" piece of paper
on which he had listed accounts and passwords all across the Internet.
This was several years worth of careful work and he carried it with him
everywhere he went. Well one day, he forgot to remove it from his jeans,
and we found a perfectly blank sheet of paper when we took out the wash
the following day!
SEE ALSO
"Exploring Expect: A Tcl-Based Toolkit for Automating Interactive Pro-
grams" by Don Libes, O'Reilly and Associates, January 1995.
AUTHOR
Don Libes, National Institute of Standards and Technology
7 October 1993 PASSMASS(1)
rlogin-cwd
root@kali:~# rlogin-cwd -h
spawn rlogin -h
rlogin: invalid option -- 'h'
rlogin: Unknown option!
Usage: rlogin [-46v] [-l user] [-p port] [user@]host
timed-read
timed-run
root@kali:~# timed-run -h
usage: spawn [spawn-args] program [program-args]
while executing
"spawn"
("eval" body line 1)
invoked from within
"eval spawn [lrange $argv 1 end]"
(file "/usr/bin/timed-run" line 12)
tknewsbiff
Pop up a window when news appears
root@kali:~# man tknewsbiff
TKNEWSBIFF(1) General Commands Manual TKNEWSBIFF(1)
NAME
tknewsbiff - pop up a window when news appears
SYNOPSIS
tknewsbiff [ server or config-file ]
INTRODUCTION
tknewsbiff pops up a window when there is unread news in your favorite
newsgroups and removes the window after you've read the news. tknewsbiff
can optionally play a sound, start your newsreader, etc.
SELECTING NEWSGROUPS
By default, the configuration file ~/.tknewsbiff describes how tknewsbiff
behaves. The syntax observes the usual Tcl rules - however, even if you
don't know Tcl, all but the most esoteric configurations will be obvious.
Each newsgroup (or set of newsgroups) to be watched is described by using
the "watch" command. For example:
watch dc.dining
watch nist.*
watch comp.unix.wizard -threshold 3
watch *.sources.* -threshold 20
For each newsgroup pattern, any newsgroup that matches it and which you
are subscribed to (according to your newsrc file) is eligible for report-
ing. By default, tknewsbiff reports on the newsgroup if there is at least
one unread article. The "-threshold" flag changes the threshold to the
following number. For example, "-threshold 3" means there must be at
least three articles unread before tknewsbiff will report the newsgroup.
If no watch commands are given (or no configuration file exists), all
groups which are subscribed to are watched.
To suppress newsgroups that would otherwise be reported, use the "ignore"
command. For example, the following matches all comp.* and nist.* new-
groups except for nist.posix or .d (discussion) groups:
watch comp.*
watch nist.*
ignore nist.posix.*
ignore *.d
The flag "-new" describes a command to be executed when the newsgroup is
first reported as having unread news. For example, the following lines
invoke the UNIX command "play" to play a sound.
watch dc.dining -new "exec play /usr/local/sounds/yumyum.au"
watch rec.auto* -new "exec play /usr/local/sounds/vroom.au"
You can cut down on the verbosity of actions by defining procedures. For
example, if you have many -new flags that all play sound files, you could
define a sound procedure. This would allow the -new specification to be
much shorter.
proc play {sound} {
exec play /usr/local/sounds/$sound.au
}
watch dc.dining -new "play yumyum"
watch rec.auto* -new "play vroom"
As an aside, you can put an "&" at the end of an "exec" command to get
commands to execute asynchronously. However, it's probably not a good
idea to do this when playing sound files anyway.
"newsgroup" is a read-only variable which contains the name of the news-
group that is being reported. This is useful when the action is triggered
by a pattern. For example, the following line could run the newsgroup
name through a speech synthesizer:
watch * -new {
exec play herald.au
exec speak "New news has arrived in $newsgroup."
}
The flag "-display" describes a command to be executed every time the
newsgroup is reported as having unread news. The special command "dis-
play" is the default command. It schedules $newsgroup to be written to
tknewsbiff's display when it is rewritten. For example, by explicitly
providing a -display flag that omits the display command, you can disable
the display of newsgroups that are already reported via -new.
watch dc.dining -new {exec play yumyum.au} -display {}
If you want to execute an action repeatedly and still display the news-
group in the default manner, explicitly invoke the display command via the
-display flag. For example:
watch *security* -display {
exec play red-alert.au
display
}
Actions associated with the -new and -display flags are executed only once
for each matching newsgroup. The command executed is the one associated
with the first pattern in the configuration file that matches and observes
the given threshold.
Any command that is simply listed in the configuration file is executed
each time before the update loop in tknewsbiff. The reserved (but user-
defined) procedure "user" is run immediately after the newsgroups are
scheduled to be written to the display and before they are actually writ-
ten.
For example, suppose unread articles appear in several rec.auto groups and
you play the same sound for each one. To prevent playing the sound sev-
eral times in a row, make the -new command simply set a flag. In the user
procedure, play the sound if the flag is set (and then reset the flag).
The user procedure could also be used to start a newsreader. This would
avoid the possibility of starting multiple newsreaders just because multi-
ple newsgroups contained unread articles. (A check should, of course, be
made to make sure that a newsreader is not already running.)
MORE VARIABLES
The following example lines show variables that can affect the behavior of
tknewsbiff
set delay 120
set server news.nist.gov
set server_timeout 60
set newsrc ~/.newsrc
set width 40
set height 20
set active_file /usr/news/lib/active
tknewsbiff alternates between checking for unread news and sleeping (kind
of like many undergraduates). The "delay" variable describes how many
seconds to sleep.
The "server" variable names an NNTP news-server. The default is "news".
The "server" variable is only used if the "active_file" variable is not
set.
The "server_timeout" variable describes how how many seconds to wait for a
response from the server before giving up. -1 means wait forever or until
the server itself times out. The default is 60 seconds.
The "newsrc" variable describes the name of your .newsrc file. By de-
fault, tknewsbiff looks in your home directory for a newsrc file. A
server-specific newsrc is used if found. For example, if you have set
server to "cubit.nist.gov", then tknewsbiff looks for ~/.newsrc-cu-
bit.nist.gov. (This is the Emacs gnus convention - which is very conve-
nient when you read news from multiple servers.) If there is no server-
specific newsrc, tknewsbiff uses ~/.newsrc.
The "width" variable describes the width that tknewsbiff will use to dis-
play information. If any newsgroup names are long enough, they will be
truncated so that the article counts can still be shown. You can manually
resize the window to see what was truncated. However, if your configura-
tion file sets the width variable, the window will be restored to that
size the next time that tknewsbiff checks for unread news and updates its
display.
The "height" variable describes the maximum height that tknewsbiff will
use to display information. If fewer newsgroups are reported, tknewsbiff
will shrink the window appropriately. You can manually resize the window
but if your configuration file sets the height variable, the window will
be restored to that size the next time that tknewsbiff checks for unread
news and updates its display.
The "active_file" variable describes the name of the news active file. If
set, the active file is read directly in preference to using NNTP (even if
the "server" variable is set). This is particularly useful for testing
out new configuration files since you can edit a fake active file and then
click button 2 to immediately see how tknewsbiff responds (see BUTTONS be-
low).
If the environment variable DOTDIR is set, then its value is used as a di-
rectory in which to find all dotfiles instead of from the home directory.
In particular, this affects the tknewsbiff configuration file and the
.newsrc file (assuming the newsrc variable is not set explicitly).
WATCHING DIFFERENT NEWS SERVERS
To watch multiple servers, run tknewsbiff multiple times. (Since you need
different .newsrc files and the servers have different newsgroups and ar-
ticle numbers anyway, there is no point in trying to do this in a single
process.)
You can point tknewsbiff at a different server with an appropriate argu-
ment. The argument is tried both as a configuration file name and as a
suffix to the string "~/.tknewsbiff-". So if you want to watch the server
"kidney", store the tknewsbiff configuration information in ~/.tknewsbiff-
kidney". The following two commands will both use that configuration
file.
tknewsbiff kidney
tknewsbiff ~/.tknewsbiff-kidney
In both cases, the actual server to contact is set by the value of the
server variable in the configuration file.
If no configuration file is found, the argument is used as the server to
contact. This allows tknewsbiff to be run with no preparation whatsoever.
If the argument is the special keyword "active" (or ends in "/active"), it
is used as the name of an active file. This is in turn used to initialize
the variable "active_file" so that tknewsbiff reads from the active file
directly rather than using NNTP.
Creating your own active file is a convenient way of testing your configu-
ration file. For example, after running the following command, you can
repeatedly edit your active file and trigger the update-now command (ei-
ther by pressing button 2 or setting the delay variable very low) to see
how tknewsbiff responds.
The active file must follow the format of a real active file. The format
is one newsgroup per line. After the newsgroup name is the number of the
highest article, the lowest article. Lastly is the letter y or m. m
means the newsgroup is moderated. y means posting is allowed.
WINDOW
When unread news is found, a window is popped up. The window lists the
names of the newsgroups and the number of unread articles in each (unless
suppressed by the -display flag). When there is no longer any unread
news, the window disappears (although the process continues to run).
BUTTONS
Button or key bindings may be assigned by bind commands. Feel free to
change them. The default bind commands are:
bind .list <1> help
bind .list <2> update-now
bind .list <3> unmapwindow
By default button 1 (left) is bound to "help". The help command causes
tknewsbiff to pop up a help window.
By default, button 2 (middle) is bound to "update-now". The update-now
command causes tknewsbiff to immediately check for unread news. If your
news server is slow or maintains a very large number of newsgroups, or you
have a large number of patterns in your configuration file, tknewsbiff can
take considerable time before actually updating the window.
By default, button 3 (right) is bound to "unmapwindow". The unmapwindow
command causes tknewsbiff to remove the window from the display until the
next time it finds unread news. (The mapwindow command causes tknewsbiff
to restore the window.)
As an example, here is a binding to pop up an xterm and run rn when you
hold down the shift key and press button 1 in the listing window.
bind .list <Shift-1> {
exec xterm -e rn &
}
Here is a similar binding. However it tells rn to look only at the news-
group that is under the mouse when you pressed it. (The "display_list"
variable is described later in this man page.)
bind .list <Shift-1> {
exec xterm -e rn [lindex $display_list [.list nearest %y]] &
}
OTHER COMMANDS AND VARIABLES
Built-in commands already mentioned are: watch, ignore, display, help, up-
date-now, unmapwindow, and mapwindow.
Any Tcl and Tk command can also be given. In particular, the list of
newsgroups is stored in the list widget ".list", and the scroll bar is
stored in the scrollbar widget ".scroll". So for example, if you want to
change the foreground and background colors of the newsgroup list, you can
say:
.list config -bg honeydew1 -fg orchid2
These can also be controlled by the X resource database as well. However,
the configuration file allows arbitrarily complex commands to be evaluated
rather than simple assignments.
Certain Tcl/Tk commands can disrupt proper function of tknewsbiff. These
will probably be obvious to anyone who knows enough to give these commands
in the first place. As a simple example, the program assumes the font in
the list box is of fixed width. The newsgroups will likely not align if
you use a variable-width font.
The following variables are accessible and can be used for esoteric uses.
All other variables are private. Private variables and commands begin
with "_" so you don't need to worry about accidental collisions.
The array "db" is a database which maintains information about read and
unread news. db($newsgroup,hi) is the highest article that exists.
db($newsgroup,seen) is the highest article that you have read.
A number of lists maintain interesting information. "active_list" is a
list of known newsgroups. "seen_list" is a list of newsgroups that have
been seen so far as the -new and -display flags are being processed.
"previous_seen_list" is "seen_list" from the previous cycle. "ig-
nore_list" is the list of newsgroup patterns to ignore. "watch_list" is
the list of newsgroup patterns to watch. "display_list" is the list of
newsgroup will be displayed at the next opportunity.
UPDATING YOUR FILES
tknewsbiff automatically rereads your configuration file each time it
wakes up to check for unread news. To force tknewsbiff to reread the file
immediately (such as if you are testing a new configuration or have just
modified your newsrc file), press button 2 in the display (see BUTTONS
above).
CAVEATS
tknewsbiff defines the number of unread articles as the highest existing
article minus the highest article that you've read. So if you've read the
last article in the newsgroup but no others, tknewsbiff thinks there are
no unread articles. (It's impossible to do any better by reading the ac-
tive file and it would be very time consuming to do this more accurately
via NNTP since servers provide no efficient way of reporting their own
holes in the newsgroups.) Fortunately, this definition is considered a
feature by most people. It allows you to read articles and then mark them
"unread" but not have tknewsbiff continue telling you that they are un-
read.
UNWARRANTED CONCERNS
Your news administrator may wonder if many people using tknewsbiff se-
verely impact an NNTP server. In fact, the impact is negligible even when
the delay is very low. To gather all the information it needs, tknewsbiff
uses a single NNTP query - it just asks for the active file. The NNTP
server does no computation, formatting, etc, it just sends the file. All
the interesting processing happens locally in the tknewsbiff program it-
self.
BUGS
The man page is longer than the program.
SEE ALSO
"Exploring Expect: A Tcl-Based Toolkit for Automating Interactive Pro-
grams" by Don Libes, O'Reilly and Associates, January 1995.
AUTHOR
Don Libes, National Institute of Standards and Technology
1 January 1994 TKNEWSBIFF(1)
tkpasswd
unbuffer
Unbuffer output
root@kali:~# unbuffer -h
bad flag "-h": must be -console, -ignore, -leaveopen, -noecho, -nottycopy, -nottyinit, -open, or -pty
while executing
"spawn -noecho -h"
("eval" body line 1)
invoked from within
"eval [list spawn -noecho] $argv"
invoked from within
"if {[string compare [lindex $argv 0] "-p"] == 0} {
# pipeline
set stty_init "-echo"
eval [list spawn -noecho] [lrange $argv 1 end]
clo..."
(file "/usr/bin/unbuffer" line 13)
xkibitz
Allow multiple people to interact in an xterm
root@kali:~# xkibitz -h
bad flag "-h": must be -console, -ignore, -leaveopen, -noecho, -nottycopy, -nottyinit, -open, or -pty
while executing
"spawn -noecho -h"
("eval" body line 1)
invoked from within
"eval spawn -noecho $argv"
invoked from within
"if {[llength $argv]>0} {
eval spawn -noecho $argv
} else {
spawn -noecho $env(SHELL)
}"
(file "/usr/bin/xkibitz" line 201)
xpstat
tcl-expect
Automates interactive applications (Tcl package)
Expect is a tool for automating interactive applications according to a script.
Following the script, Expect knows what can be expected from a program and what
the correct response should be. Expect is also useful for testing these same
applications. And by adding Tk, you can also wrap interactive applications in
X11 GUIs. An interpreted language provides branching and high-level control
structures to direct the dialogue. In addition, the user can take control and
interact directly when desired, afterward returning control to the script.
This package contains the library and Tcl package Expect.
Installed size: 467 KB
How to install: sudo apt install tcl-expect
Dependencies:
- libc6
- libtcl8.6 | libtcl9.0
tcl-expect-dev
Automates interactive applications (development)
Expect is a tool for automating interactive applications according to a script.
Following the script, Expect knows what can be expected from a program and what
the correct response should be. Expect is also useful for testing these same
applications. And by adding Tk, you can also wrap interactive applications in
X11 GUIs. An interpreted language provides branching and high-level control
structures to direct the dialogue. In addition, the user can take control and
interact directly when desired, afterward returning control to the script.
This package contains the development files.
Installed size: 130 KB
How to install: sudo apt install tcl-expect-dev
Dependencies:
- tcl-expect
- tcl8.6-dev
- tcl9.0-dev
Updated on: 2026-Jun-17