Аналог goto или try в bash

Checking For Errors From spawn
All of the examples so far have assumed that spawn always succeeds. The bad news is that spawn does not always succeed. The good news is that it only fails in peculiar envi- ronments or in peculiar situations. In this section, I will describe the meaning of "peculiar" and how to check whether spawn succeeded or not.
The spawn command normally returns the process id of the newly spawned process.t This is generally of little value since spawned processes are more easily manipulable by their spawn ids. However, it is occasionally useful to be able to kill a process using its process id rather than going through some long interaction.
Once killed, the process connection should be recycled by calling close and wait.
Running out of various system resources can cause spawn to fail. For example, spawn allocates dynamic memory as well as a logical terminal interface.
Failures like this can be caught using Tcl's catch command:

"spawn -open" returns a process id of 0 to indicate no process was spawned. There is no process to kill.

Even if spawn does not return an error, that is not a guarantee that it was entirely successful. To understand why, it is necessary to explain a little of how spawn is implemented.
The spawn command follows the traditional UNIX paradigm for running a new program. First, Expect forks. Forking is the UNIX way of generating a new process. Initially, the new process is still running Expect code. This allows Expect to prepare the environment appropriately for the new program. The last step is for Expect (in the new process) to overlay itself with the new program. At this point, the original Expect process is still running, and the new process is running the requested program.
This last step of loading the program can fail if, for example, the program does not exist. If it does not exist, the new process must communicate this back to the Expect process. Ironically, the failure of the program to be found can be communicated but not its success. The reason is that the very act of successfully running the program removes any functionality of the earlier program (i.e., Expect). Thus, the new program has no idea how to signal success or even that it should.
Because of this, the original Expect process cannot wait around for a possible failure. The spawn command returns immediately. If the process does fail however, the new process sends back an error report in such a way that the Expect process hears it at the next convenient moment-the first expect command.


Exploring Expect
Checking the return value of spawn (as shown above with catch) is a good idea if you want your code to be bulletproof. These kinds of errors are often due to transient condi- tions that may go away if the operation is retried, such as a lack of memory.
On the other hand, checking spawn's success via the first expect is less valuable. For example, if a standard utility such as /bin/sh is being spawned, there is little point in checking if it succeeded. If it did not, the computer has such severe problems that few programs will be able to continue to nm.
The primary circumstance in which to check the first expect after a spawn is when the program is unknown at the time the script is written. For example, if a user can type in arbitrary command names dynamically, these names should be checked. Note that using "file executable" is a reasonable test but it is not guaranteed since there is a window between the time the file can be tested and the time it is executed, during which the file can change.