This is a request for a new feature. Perhaps there are good reasons why it can't be done, but from the outside looking in it seems possible, and I have taken into account advice from the bash help mailing list.
Could there be a dry-run option for bash. A dry-run option would be something akin to a combination of the -x and -n options. When a script is processed by bash in dry-run mode there would be output to stdout or stderr the sequence of commands that bash determines to run, something like -x, but the commands are not in fact executed, as with -n If the output were to be captured as a script, that script itself could be run by a normal invocation of bash, giving the same result, output and side-effects, as the original script would give. If the captured script were executed in dry-run mode the output should be the same as the input. make has a dry run option as described, "-n". A typical use would be determine what a complicated script, like libtool, will end up doing. >From googling, people have posted suggestions as to how to achieve this behaviour in scripts. This indicates that there is a demand for such a feature. An allied question is also raised: In -x mode, where command lines are echoed but unfortunately any applicable redirections of stdout and stdin are lost. Some details and difficulties have been anticipated. 1. Which commands are dry-run? Only external commands are candidates for dry-running. Moreover, the user must have the chance somehow to specify which commands are executed and which not. For the use-case of building code (ie with make, libtool and those kind of things) /usr/bin/ls should proceed, so as to see what files are present, which are out of date etc, but usr/bin/gcc should be dry-run, just the recommended command line listed to stdout. 2. What to do about variables set by commands when the commands are not run. Example. command # not executed if $? another_command # return value of previous command not known Another example var= `command` # command not executed another_command $var # $var not known Either way bash is being asked to read a variable that is invalid because the step to set it was skipped. Suggested response. bash treats this as an error (similar to -u option) and would most likely exit (as in -e) However the user may want to specify that 0 is assumed for $? for commands not executed.
