Packages and Binaries:

expect

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: 308 KB
How to install: sudo apt install expect

Dependencies:
  • libc6
  • libtcl8.6
  • tcl-expect
  • tcl8.6
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
       Expect 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 au-
       toexpect  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  auto-
       expect.

       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 result-
       ing 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 work-
       ing  script  because  it necessarily has to guess about certain things -
       and occasionally it guesses wrong.  However, it is usually very easy  to
       identify and fix these problems.  The typical problems are:

              o   Timing.   A  surprisingly  large number of programs (rn, ksh,
                  zsh, telnet, etc.) and devices  (e.g.,  modems)  ignore  key-
                  strokes 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
                  variable  "force_conservative" near the beginning of the gen-
                  erated script.  This "conservative" mode makes autoexpect au-
                  tomatically 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,  tel-
                  net  ignores  characters  only  after entering its escape se-
                  quence.  Modems only ignore characters immediately after con-
                  necting 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  behav-
                  ior.

                  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

              o   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 be-
                  fore typing the next.  If autoexpect  sees  characters  being
                  echoed,  it  assumes  that  it  can  send them all as a group
                  rather than interleaving them the  way  they  originally  ap-
                  peared.   This  makes the script more pleasant to read.  How-
                  ever, it could conceivably be incorrect if you really had  to
                  wait to see each character echoed.

              o   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
                  correct.   For  example,  the  "date" command always produces
                  different output.  So using the date  command  while  running
                  autoexpect  is  a  sure way to produce a script that will re-
                  quire editing in order for it to work.

                  The -p flag puts autoexpect  into  "prompt  mode".   In  this
                  mode, autoexpect will only look for the the last line of pro-
                  gram  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 follow-
                  ing 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  charac-
       ters  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,
       autoexpect uses features of Expect that are  intended  specifically  for
       computer-generated  scripting.  So don't try to faithfully write scripts
       that appear as if they were generated by autoexpect.  This is  not  use-
       ful.

       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 appre-
       ciate 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)
Killed

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]

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
       Expect 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 au-
       toexpect  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  auto-
       expect.

       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 result-
       ing 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 work-
       ing  script  because  it necessarily has to guess about certain things -
       and occasionally it guesses wrong.  However, it is usually very easy  to
       identify and fix these problems.  The typical problems are:

              o   Timing.   A  surprisingly  large number of programs (rn, ksh,
                  zsh, telnet, etc.) and devices  (e.g.,  modems)  ignore  key-
                  strokes 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
                  variable  "force_conservative" near the beginning of the gen-
                  erated script.  This "conservative" mode makes autoexpect au-
                  tomatically 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,  tel-
                  net  ignores  characters  only  after entering its escape se-
                  quence.  Modems only ignore characters immediately after con-
                  necting 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  behav-
                  ior.

                  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

              o   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 be-
                  fore typing the next.  If autoexpect  sees  characters  being
                  echoed,  it  assumes  that  it  can  send them all as a group
                  rather than interleaving them the  way  they  originally  ap-
                  peared.   This  makes the script more pleasant to read.  How-
                  ever, it could conceivably be incorrect if you really had  to
                  wait to see each character echoed.

              o   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
                  correct.   For  example,  the  "date" command always produces
                  different output.  So using the date  command  while  running
                  autoexpect  is  a  sure way to produce a script that will re-
                  quire editing in order for it to work.

                  The -p flag puts autoexpect  into  "prompt  mode".   In  this
                  mode, autoexpect will only look for the the last line of pro-
                  gram  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 follow-
                  ing 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  charac-
       ters  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,
       autoexpect uses features of Expect that are  intended  specifically  for
       computer-generated  scripting.  So don't try to faithfully write scripts
       that appear as if they were generated by autoexpect.  This is  not  use-
       ful.

       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 appre-
       ciate 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)
Killed

expect_ftp-rfc
root@kali:~# expect_ftp-rfc -h
spawn ftp ftp.uu.net

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
       arbitrary program).  Uses include:

              o   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.

              o   By  running  kibitz  and  then starting a full-screen editor,
                  people may carry out a conversation, retaining the ability to
                  scroll backwards, save the entire conversation, or even  edit
                  it while in progress.

              o   People can team up on games, document editing, or other coop-
                  erative  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.
       Similarly, both users receive the output from the shell.

       To terminate kibitz it suffices to terminate the shell itself.  For  ex-
       ample,  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  es-
       cape  character  (described  when kibitz starts) is issued, the user may
       talk directly to the kibitz interpreter.  Any Expect(1) or  Tcl(3)  com-
       mands  may  be given.  Also, job control may be used while in the inter-
       preter, to, for example, suspend or restart kibitz.

       Various processes can provide various effects.  For example, you can em-
       ulate 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  user-
       name  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"
       commands.

       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 dis-
       play 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 re-
       mote 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
       unusual  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
       default 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 kib-
       itz.

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 regu-
       lar  expression which matches the end of your login prompt (but does not
       otherwise 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 description 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
1fd3dR*xT

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  com-
       mand.

       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
       characters  are  entered, the color changes to green for a second.  This
       provides 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 com-
                  mand 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
                  directory 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 inter-
                  nally.  The verbose output is not intended to be  understand-
                  able to anyone but the author.

       Less  common  options  may be changed by the startup file (see FILES be-
       low).

       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  re-
       mainder  is  used as a list of xterm names in the style of -xn.  The de-
       fault behavior 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  accept-
       able 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 pro-
       cedures.  The primary variables of interest are 'xtermCmd' which identi-
       fies  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  simi-
       lar 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  re-
       mainder  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
       multixterm.  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 variable xtermArgs r 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
       handling  of the arguments from hostnames to a filename containing host-
       names:

            set xtermNames [exec cat $argv]

       The following is a variation, retrieving the  host  names  from  the  yp
       database:

            set xtermNames [exec ypcat $argv]

       The  following hardcodes two sets of hosts, so that you can call multix-
       term 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 sep-
       arate 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  ex-
       ternal processes, particularly for character graphic applications (e.g.,
       vi, emacs), you may have to manually ensure that the spawned process be-
       hind 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
       argument 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.  De-
                  fault 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  ac-
                  counts (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.   tknewsb-
       iff can optionally play a sound, start your newsreader, etc.

SELECTING NEWSGROUPS
       By  default, the configuration file ~/.tknewsbiff describes how tknewsb-
       iff behaves.  The syntax observes the usual Tcl rules - however, even if
       you don't know Tcl, all but the most esoteric configurations will be ob-
       vious.

       Each newsgroup (or set of newsgroups) to be watched is described by  us-
       ing 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  re-
       porting.  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 "ig-
       nore" command.  For example, the following matches all comp.* and nist.*
       newgroups 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 trig-
       gered by a pattern.  For example, the following line could run the news-
       group 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  dis-
       able 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 asso-
       ciated 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
       written.

       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
       several 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 mul-
       tiple 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
       display 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
       configuration  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,  tknewsb-
       iff  will  shrink the window appropriately.  You can manually resize the
       window but if your configuration file sets the height variable, the win-
       dow 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 below).

       If  the  environment variable DOTDIR is set, then its value is used as a
       directory in which to find all dotfiles instead of from the home  direc-
       tory.  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  article 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 whatso-
       ever.

       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 ini-
       tialize the variable "active_file" so that tknewsbiff reads from the ac-
       tive file directly rather than using NNTP.

       Creating your own active file is a convenient way of testing  your  con-
       figuration  file.  For example, after running the following command, you
       can repeatedly edit your active file and trigger the update-now  command
       (either  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  for-
       mat  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  (un-
       less  suppressed by the -display flag).  When there is no longer any un-
       read 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, tknewsb-
       iff 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
       newsgroup  that  is  under  the  mouse  when you pressed it.  (The "dis-
       play_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,
       update-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.  How-
       ever, 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 BUT-
       TONS 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  active file and it would be very time consuming to do this more ac-
       curately 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 unread.

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 itself.

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
Trying 35.160.169.47...

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

ftp-rfc
root@kali:~# ftp-rfc -h
spawn ftp ftp.uu.net

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
       arbitrary program).  Uses include:

              o   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.

              o   By  running  kibitz  and  then starting a full-screen editor,
                  people may carry out a conversation, retaining the ability to
                  scroll backwards, save the entire conversation, or even  edit
                  it while in progress.

              o   People can team up on games, document editing, or other coop-
                  erative  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.
       Similarly, both users receive the output from the shell.

       To terminate kibitz it suffices to terminate the shell itself.  For  ex-
       ample,  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  es-
       cape  character  (described  when kibitz starts) is issued, the user may
       talk directly to the kibitz interpreter.  Any Expect(1) or  Tcl(3)  com-
       mands  may  be given.  Also, job control may be used while in the inter-
       preter, to, for example, suspend or restart kibitz.

       Various processes can provide various effects.  For example, you can em-
       ulate 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  user-
       name  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"
       commands.

       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 dis-
       play 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 re-
       mote 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
       unusual  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
       default 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 kib-
       itz.

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 regu-
       lar  expression which matches the end of your login prompt (but does not
       otherwise 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 description 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  com-
       mand.

       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
       characters  are  entered, the color changes to green for a second.  This
       provides 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 com-
                  mand 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
                  directory 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 inter-
                  nally.  The verbose output is not intended to be  understand-
                  able to anyone but the author.

       Less  common  options  may be changed by the startup file (see FILES be-
       low).

       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  re-
       mainder  is  used as a list of xterm names in the style of -xn.  The de-
       fault behavior 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  accept-
       able 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 pro-
       cedures.  The primary variables of interest are 'xtermCmd' which identi-
       fies  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  simi-
       lar 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  re-
       mainder  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
       multixterm.  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 variable xtermArgs r 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
       handling  of the arguments from hostnames to a filename containing host-
       names:

            set xtermNames [exec cat $argv]

       The following is a variation, retrieving the  host  names  from  the  yp
       database:

            set xtermNames [exec ypcat $argv]

       The  following hardcodes two sets of hosts, so that you can call multix-
       term 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 sep-
       arate 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  ex-
       ternal processes, particularly for character graphic applications (e.g.,
       vi, emacs), you may have to manually ensure that the spawned process be-
       hind 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
       argument 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.  De-
                  fault 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  ac-
                  counts (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.   tknewsb-
       iff can optionally play a sound, start your newsreader, etc.

SELECTING NEWSGROUPS
       By  default, the configuration file ~/.tknewsbiff describes how tknewsb-
       iff behaves.  The syntax observes the usual Tcl rules - however, even if
       you don't know Tcl, all but the most esoteric configurations will be ob-
       vious.

       Each newsgroup (or set of newsgroups) to be watched is described by  us-
       ing 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  re-
       porting.  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 "ig-
       nore" command.  For example, the following matches all comp.* and nist.*
       newgroups 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 trig-
       gered by a pattern.  For example, the following line could run the news-
       group 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  dis-
       able 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 asso-
       ciated 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
       written.

       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
       several 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 mul-
       tiple 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
       display 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
       configuration  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,  tknewsb-
       iff  will  shrink the window appropriately.  You can manually resize the
       window but if your configuration file sets the height variable, the win-
       dow 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 below).

       If  the  environment variable DOTDIR is set, then its value is used as a
       directory in which to find all dotfiles instead of from the home  direc-
       tory.  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  article 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 whatso-
       ever.

       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 ini-
       tialize the variable "active_file" so that tknewsbiff reads from the ac-
       tive file directly rather than using NNTP.

       Creating your own active file is a convenient way of testing  your  con-
       figuration  file.  For example, after running the following command, you
       can repeatedly edit your active file and trigger the update-now  command
       (either  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  for-
       mat  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  (un-
       less  suppressed by the -display flag).  When there is no longer any un-
       read 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, tknewsb-
       iff 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
       newsgroup  that  is  under  the  mouse  when you pressed it.  (The "dis-
       play_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,
       update-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.  How-
       ever, 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 BUT-
       TONS 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  active file and it would be very time consuming to do this more ac-
       curately 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 unread.

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 itself.

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

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: 262 KB
How to install: sudo apt install tcl-expect

Dependencies:
  • libc6
  • libtcl8.6

tcl-expect-dev

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: 109 KB
How to install: sudo apt install tcl-expect-dev

Dependencies:
  • tcl-expect
  • tcl8.6-dev

Updated on: 2024-Aug-14