When a process is started by spawn, the variable spawn_id is set to a descriptor referring to that process.  The process described by spawn_id is considered the current process. spawn_id may be read or written, in effect providing job control. 

user_spawn_id is a global variable containing a descriptor which refers to the user.  For example, when spawn_id is set to this value, expect behaves like expect_user. 

error_spawn_id is a global variable containing a descriptor which refers to the standard error.  For example, when spawn_id is set to this value, send behaves like send_error. 

tty_spawn_id is a global variable containing a descriptor which refers to /dev/tty.  If /dev/tty does not exist (such as in a cron, at, or batch script), then tty_spawn_id is not defined.  This may be tested as: 

if [info vars tty_spawn_id] {
   # /dev/tty exists
} else {
   # /dev/tty doesn’t exist
   # probably in cron, batch, or at script
}

spawn returns the UNIX process id.  If no process is spawned, 0 is returned.  The variable spawn_out(slave,name) is set to the name of the pty slave device.  By default, spawn echoes the command name and arguments.  The -noecho flag stops spawn from doing this. 

The -console flag causes console output to be redirected to the spawned process.  This is not sup-ported on all systems. 

Internally, spawn uses a pty, initialized the same way as the user’s tty.  This is further initialized so that all settings are “sane” (according to stty(1)).  If the variable stty_init is defined, it is interpreted in the style of stty arguments as further con-figuration.  For example, “set stty_init raw” will cause further spawned processes’s terminals to start in raw mode.  -nottycopy skips the initialization based on the user’s tty.  -nottyinit skips the “sane” initialization. 

Normally, spawn takes little time to execute.  If you notice spawn taking a significant amount of time, it is probably encountering ptys that are wedged.  A number of tests are run on ptys to avoid entanglements with errant processes.  (These take 10 seconds per wedged pty.) Running Expect with the -d option will show if Expect is encountering many ptys in odd states.  If you cannot kill the processes to which these ptys are attached, your only recourse may be to reboot. 

If program cannot be spawned successfully because exec(2) fails (e.g.  when program doesn’t exist), an error message will be returned by the next interact or expect command as if program had run and produced the error message as output.  This behavior is a natural consequence of the implementation of spawn.  Internally, spawn forks, after which the spawned process has no way to communicate with the original Expect process except by communication via the spawn_id. 

The -open flag causes the next argument to be interpreted as a Tcl file identifier (i.e., returned by open.) The spawn id can then be used as if it were a spawned process.  (The file identifier should no longer be used.) This lets you treat raw devices, files, and pipelines as spawned processes without using a pty.  0 is returned to indicate there is no associated process.  When the connection to the spawned process is closed, so is the Tcl file identifier.  The -leaveopen flag is similar to -open except that -leaveopen causes the file identifier to be left open even after the spawn id is closed. 

The -pty flag causes a pty to be opened but no process spawned.  0 is returned to indicate there is no associated process.  spawn_id is set as usual. 

The variable spawn_out(slave,fd) is set to a file identifier corresponding to the pty slave.  It can be closed using “close -slave”. 

The -ignore flag names a signal to be ignored in the spawned process.  Otherwise, signals get the default behavior.  Signals are named as in the trap command, except that each signal requires a separate flag.