Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Dry-run a potentially dangerous script?

Tags:

linux

bash

A predecessor of mine installed a crappy piece of software on an old machine (running Linux) which I've inherited. Said crappy piece of software installed flotsam all over the place, and also is sufficiently bloated that I want it off ASAP -- it no longer has any functional purpose since we've moved on to better software.

Vendor provided an uninstall script. Not trusting the crappy piece of software, I opened the uninstall script in an editor (a 200+ line Bash monster), and it starts off something like this:

SWROOT=`cat /etc/vendor/path.conf`
...
rm -rf $SWROOT/bin
...

It turns out that /etc/vendor/path.conf is missing. Don't know why, don't know how, but it is. If I had run this lovely little script, it would have deleted the /bin folder, which would have had rather amusing implications. Of course this script required root to run!

I've dealt with this issue by just manually running all the install commands (guh) where sensible. This kind of sucked because I had to interpolate all the commands manually. In general, is there some sort of way I can "dry run" a script to have it dump out all the commands it would execute, without it actually executing them?

like image 268
James Elegan Avatar asked Apr 09 '14 04:04

James Elegan


1 Answers

bash does not offer dry-run functionality (and neither do ksh, zsh, or any other shell I know).

It seems to me that offering such a feature in a shell would be next to impossible: state changes would have to be simulated and any command invoked - whether built in or external - would have to be aware of these simulations.

The closest thing that bash, ksh, and zsh offer is the ability to syntax-check a script without executing it, via option -n:

bash -n someScript  # syntax-check a script, without executing it.
  • If there are no syntax errors, there will be no output, and the exit code will be 0.
  • If there are syntax errors, analysis will stop at the first error, an error message including the line number is written to stderr, and the exit code will be:
    • 2 in bash
    • 3 in ksh
    • 1 in zsh

Separately, bash, ksh, and zsh offer debugging options:

  • -v to print each raw source code line[1] to stderr before it is executed.

  • -x to print each expanded simple command to stderr before it is executed (env. var. PS4 allows tweaking the output format).


Combining -n with -v and/or -x offers little benefit:

  • With -n specified, -x has no effect at all, because nothing is being executed.

  • With -n specified, -v will effectively simply print the source code.

    • If there is a syntax error, there may be benefit in the source code getting print up to the point where the error occurs; keep in mind, though that the error message produced by
      -n always includes the offending line number.

[1] Typically, it is individual lines that are printed, but the true unit is however many lines a given command - which may be a compound command such as while or a command list (such as a pipeline) - spans.

like image 119
mklement0 Avatar answered Oct 31 '22 10:10

mklement0