{
    "content": [
        {
            "type": "text",
            "text": "# expect_autoexpect(1) (man)\n\n**Summary:** autoexpect - generate an Expect script from watching a session\n\n**Synopsis:** autoexpect [ args ] [ program args...  ]\n\n## Section Outline\n\n- **NAME** (2 lines)\n- **SYNOPSIS** (2 lines)\n- **INTRODUCTION** (117 lines)\n- **OTHER FLAGS** (11 lines)\n- **STYLE** (10 lines)\n- **SEE ALSO** (3 lines)\n- **AUTHOR** (9 lines)\n\n## Full Content\n\n### NAME\n\nautoexpect - generate an Expect script from watching a session\n\n### SYNOPSIS\n\nautoexpect [ args ] [ program args...  ]\n\n### INTRODUCTION\n\nautoexpect watches you interacting with another program and creates an Expect script that re‐\nproduces your interactions.  For straightline scripts, autoexpect saves substantial time over\nwriting  scripts  by  hand.  Even if you are an Expect expert, you will find it convenient to\nuse autoexpect to automate the more mindless parts of interactions.  It  is  much  easier  to\ncut/paste  hunks  of autoexpect scripts together than to write them from scratch.  And if you\nare a beginner, you may be able to get away with learning nothing more about Expect than  how\nto call autoexpect.\n\nThe  simplest  way  to  use autoexpect is to call it from the command line with no arguments.\nFor example:\n\n% autoexpect\n\nBy default, autoexpect spawns a shell for you.  Given a program name and  arguments,  autoex‐\npect spawns that program.  For example:\n\n% autoexpect ftp ftp.cme.nist.gov\n\nOnce  your spawned program is running, interact normally.  When you have exited the shell (or\nprogram that you specified), autoexpect will create a new script for you.  By default,  auto‐\nexpect  writes  the  new script to \"script.exp\".  You can override this with the -f flag fol‐\nlowed by a new script name.\n\nThe following example runs \"ftp ftp.cme.nist.gov\" and stores the resulting Expect  script  in\nthe file \"nist\".\n\n% autoexpect -f nist ftp ftp.cme.nist.gov\n\nIt  is important to understand that autoexpect does not guarantee a working script because it\nnecessarily has to guess about certain things - and occasionally it guesses wrong.   However,\nit is usually very easy to identify and fix these problems.  The typical problems are:\n\n•   Timing.   A surprisingly large number of programs (rn, ksh, zsh, telnet, etc.) and\ndevices (e.g., modems) ignore keystrokes that arrive \"too quickly\" after  prompts.\nIf  you find your new script hanging up at one spot, try adding a short sleep just\nbefore the previous send.\n\nYou can force this behavior throughout by overriding the variable \"forceconserva‐\ntive\"  near the beginning of the generated script.  This \"conservative\" mode makes\nautoexpect automatically pause briefly (one tenth of a second) before sending each\ncharacter.  This pacifies every program I know of.\n\nThis  conservative  mode  is  useful if you just want to quickly reassure yourself\nthat the problem is a timing one (or if you really don't care about how  fast  the\nscript  runs).  This same mode can be forced before script generation by using the\n-c flag.\n\nFortunately, these timing spots are rare.  For example, telnet ignores  characters\nonly  after  entering  its escape sequence.  Modems only ignore characters immedi‐\nately after connecting to them for the first time.  A few  programs  exhibit  this\nbehavior  all  the  time  but typically have a switch to disable it.  For example,\nrn's -T flag disables this behavior.\n\nThe following example starts autoexpect in conservative mode.\n\nautoexpect -c\n\nThe -C flag defines a key to toggle  conservative  mode.   The  following  example\nstarts  autoexpect  (in  non-conservative mode) with ^L as the toggle.  (Note that\nthe ^L is entered literally - i.e., enter a real control-L).\n\nautoexpect -C ^L\n\nThe following example starts autoexpect in conservative mode with ^L as  the  tog‐\ngle.\n\nautoexpect -c -C ^L\n\n\n•   Echoing.   Many  program  echo  characters.   For example, if you type \"more\" to a\nshell, what autoexpect actually sees is:\n\nyou typed 'm',\ncomputer typed 'm',\nyou typed 'o',\ncomputer typed 'o',\nyou typed 'r',\ncomputer typed 'r',\n...\n\nWithout specific knowledge of the program, it is impossible to  know  if  you  are\nwaiting  to  see each character echoed before typing the next.  If autoexpect sees\ncharacters being echoed, it assumes that it can send them all as  a  group  rather\nthan  interleaving  them  the way they originally appeared.  This makes the script\nmore pleasant to read.  However, it could conceivably be incorrect if  you  really\nhad to wait to see each character echoed.\n\n\n•   Change.   Autoexpect  records  every character from the interaction in the script.\nThis is desirable because it gives you the ability to make judgements  about  what\nis important and what can be replaced with a pattern match.\n\nOn  the  other hand, if you use commands whose output differs from run to run, the\ngenerated scripts are not going to be correct.  For example,  the  \"date\"  command\nalways produces different output.  So using the date command while running autoex‐\npect is a sure way to produce a script that will require editing in order  for  it\nto work.\n\nThe  -p  flag  puts  autoexpect into \"prompt mode\".  In this mode, autoexpect will\nonly look for the the last line of program output - which is usually  the  prompt.\nThis handles the date problem (see above) and most others.\n\nThe following example starts autoexpect in prompt mode.\n\nautoexpect -p\n\nThe -P flag defines a key to toggle prompt mode.  The following example starts au‐\ntoexpect (in non-prompt mode) with ^P as the toggle.  Note that the ^P is  entered\nliterally - i.e., enter a real control-P.\n\nautoexpect -P ^P\n\nThe following example starts autoexpect in prompt mode with ^P as the toggle.\n\nautoexpect -p -P ^P\n\n### OTHER FLAGS\n\nThe -quiet flag disables informational messages produced by autoexpect.\n\nThe  -Q  flag  names  a quote character which can be used to enter characters that autoexpect\nwould otherwise consume because they are used as toggles.\n\nThe following example shows a number of flags with quote used to provide a  way  of  entering\nthe toggles literally.\n\nautoexpect -P ^P -C ^L -Q ^Q\n\n### STYLE\n\nI  don't  know if there is a \"style\" for Expect programs but autoexpect should definitely not\nbe held up as any model of style.  For example, autoexpect uses features of Expect  that  are\nintended  specifically  for  computer-generated  scripting.  So don't try to faithfully write\nscripts that appear as if they were generated by autoexpect.  This is not useful.\n\nOn the other hand, autoexpect scripts do show some worthwhile things.  For example,  you  can\nsee  how  any  string must be quoted in order to use it in a Tcl script simply by running the\nstrings through autoexpect.\n\n### SEE ALSO\n\n\"Exploring Expect: A Tcl-Based Toolkit for Automating Interactive  Programs\"  by  Don  Libes,\nO'Reilly and Associates, January 1995.\n\n### AUTHOR\n\nDon Libes, National Institute of Standards and Technology\n\nexpect  and autoexpect are in the public domain.  NIST and I would appreciate credit if these\nprograms or parts of them are used.\n\n\n\n\n30 June 1995                               AUTOEXPECT(1)\n\n"
        }
    ],
    "structuredContent": {
        "command": "expect_autoexpect",
        "section": "1",
        "mode": "man",
        "summary": "autoexpect - generate an Expect script from watching a session",
        "synopsis": "autoexpect [ args ] [ program args...  ]",
        "flags": [],
        "examples": [],
        "see_also": [],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "SYNOPSIS",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "INTRODUCTION",
                "lines": 117,
                "subsections": []
            },
            {
                "name": "OTHER FLAGS",
                "lines": 11,
                "subsections": []
            },
            {
                "name": "STYLE",
                "lines": 10,
                "subsections": []
            },
            {
                "name": "SEE ALSO",
                "lines": 3,
                "subsections": []
            },
            {
                "name": "AUTHOR",
                "lines": 9,
                "subsections": []
            }
        ]
    }
}