requested dry-run mode for bash.

[Robert Durkacz]

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.