Send in your Unix questions today! |
See additional Unix tips and tricks
If you ever find yourself cutting and pasting Unix commands and their output into a file in order to create a record of some anomaly you have encountered on a system you manage or to document a procedure so that someone else can take charge while you are on vacation, you may have overlooked a handy command that takes all the fuss out of recording the content of your online session -- the script command.
Invoked without arguments, the script command will open a file named "typescript" and will add to it everything that goes across your terminal window, including what you type and what the system includes in its response.
If you would like to use a different file name, you simply provide it on the command line following script (e.g., script howto.txt) and the file will be created with the provided name. If you already have a file and would like to append to the end of it, script has an option (-a) for doing so.
Script continues collecting commands and output until you enter a ^D (for Bourne, bash, etc.) or exit command. Verify which works with your favorite shell before deciding on your favorite exit technique.
The script command was probably used by early Unix users as a way to easily create a script. They could invoke script, type their commands while capturing them and, at the same time verify that they worked as expected. Of course, they would then have to go back and remove the command output, leaving only the command themselves, and make the new script file executable. Even so, by the time they were done typing the commands, they would have known whether they had built a script that was going to do what they needed.
The script command is a very useful command when you need to collect error messages and other details of some hardware or software failure that you might need to send to someone else for analysis. One of the most frustrating parts of being on the receiving end of error reports is how imprecise many people are when they describe problems that they have encountered. If you can collect both the exact errors that are generated and the context in which they are generated, you will have a much easier time getting the help that you need.
Similarly, if you can train your users to use script to collect the data that you will need in diagnosing problems that they are having, you may not have to call them back to ask exactly what they are seeing and under what circumstances.
Consider using script when you are troubleshooting a difficult problem and you just might need before and after system snapshots to piece together a root cause report once everything is working again. When you are busy probing in numerous directions to pin down what might be wrong, you may not be in a state of mind to record every step that you take (since many, if not most, will not pan out) unless it's relatively painless to do so.
The script command can be very useful, but you must be wary of some screen events -- such as cursor movements used in vi -- that can make script's output files nearly impossible to view.
