This page is READ-ONLY. It is generated from the old site.
All timestamps are relative to 2013 (when this page is generated).
If you are looking for TeX support, please go to

Bash: a bad test that made a system corrupted

simple, funny but terrible
Added by ruby about 1 year ago  »  Votes: 2/2

What's wrong in this portion of code?

 1 if /bin/false; then
 2   echo "Yes it's false" 
 3 else
 4   $command 2> $logfile  \
 5     | $compress_bin -f -q -9  \
 6     > $file_to_create.$ext 2> $logfile  
 7   file_to_create="$file_to_create.$ext" 
 8 fi
10 if [[ $? -gt 0 ]]; then
11   warning "Unable to exec \$command; check \$logfile" 
12   rm -f $file_to_create
13 else
14   rm -f $logfile
15 fi

Update 2012 July 23rd: This portion of code comes from the favorite tool Backup Manager . (I couldn't access to this page to report the problem.) The biggest trouble is that the script always returns successfully even if the backup command failed: As you can see, the 10th line checks if there is any error in the last execution. Ufortunately, (in Bash) the last execution is an assigment file_to_create="$file_to_create.$ext", which will always return 0 (no error found.) Any errors in the 4th - 6th are simply ignored by this assigment.

In a system of my customer, using this buggy code really caused a problem: Backup Manager was used to back up database system. For some reasons, backup manager couldn't connect to the mysql server, but as it didn't there is a error, it still generated an empty backup file. Damn it. In a nice day, system shut down permanently, and then the sysadmin found that hey hadn't any backup left. (FYI, the customer used a stable version of Backup Manager on Ubuntu 10.04 LTS Server edition)

After this issue, we completey forget Backup Manager. A backup tool shouldn't be so buggy.