Now, I made up a similar script to do the same on OS X.

The basic idea, now and then, was that I would not want to send all traffic through the VPN.
Thus the script will assist in restoring your local default route after the VPN connection is established.
Furthermore, it’ll add some specific routes directed to the VPN.

This way, all your usual traffic (internet, surfing, skype, whatever) is sent through your default gateway, while more specific routes (your business stuff) is sent through the VPN.

Below’s the code for the initial release. It may lack some details yet, like auto-detecting the tunnel device name, but it does the job already.

Just copy the code into Apple Script Editor and save it to a convenient location. Make sure you save it as “Application” and not as “Script” (which is the default). You you don’t, double-clicking the script will open the Script Editor instead of executing the script. Surely, not what you want.

Pay attention to the variables on the top, which need to be edited before you save the Script: _vpn_name, _default_gw, _networks, and _sudo_password (optional).
I hope directions are clear enough from the comments sections.

# VpnInit
# ---
# an AppleScript utility to connect your vpn,
# restore local default route and add selected
# routes directed to the VPN only
# thus you'll end up sending only selected
# traffic through the VPN, while the rest
# goes through your local default gateway
# as usual
# ---
# released "as is" under the terms of GPL v2.
# Copyright © 2011 Gianpaolo Del Matto
# 
# r0.1 initial release 2011/12/29
#
# ToDo:
# - hardcoding the "sudo" password is a bad idea, maybe
#	need a better way to get away with it
# - vpn tunnel (utun0) is still hardcoded,
#	should be auto-detected
#

# the name of your vpn connection
#
set _vpn_name to "My VPN"

# your local default gateway
#
set _default_gw to "192.168.1.1"

# your remote networks to pass via VPN, separate multiple with comma
# like so: {"1.2.3.4/30", "5.6.7.8/30"}
#
set _networks to {"192.168.2.1/24"}

# your super-user (root) password
# actually needed to bypass the prompts
# leave empty to get prompted
#
set _sudo_password to ""

# ##################################################################
# DO NOT CHANGE ANYTHING BELOW
# ##################################################################

# kindly borrowed from
# http://www.macosxautomation.com/applescript/uiscripting/index.html
# make sure that support for assistive devices is enabled
#
tell application "System Events"
	if UI elements enabled is false then
		tell application "System Preferences"
			activate
			set current pane to pane id "com.apple.preference.universalaccess"
			display dialog "This script requires access for assistive devices be enabled." & return & return & "To continue, click the OK button and enter an administrative password in the forthcoming security dialog." with icon 1
		end tell
		set UI elements enabled to true
		if UI elements enabled is false then
			display dialog "This script cannot run while access for assistive devices is disabled." & return & "Exiting now." buttons {"OK"} with icon 2
			return "user cancelled"
		end if
	end if
end tell

# now dive into the VPN setup part
#
tell application "System Events"
	set _if_tunnel to "utun0" #	do not change, will be auto-detected, just giving a reasonable default
	tell current location of network preferences
		if exists service _vpn_name then
			# try to connect the VPN service if it's disconnected
			#
			if current configuration of service _vpn_name is not connected then
				connect service _vpn_name
			end if

			# give it some time to settle
			#
			set _retval to false
			repeat until (_retval) is true
				set counter to 0
				repeat while counter is less than 16
					# exit if we get connected
					#
					if current configuration of service _vpn_name is connected then
						set _retval to true
						exit repeat
					end if

					# opt for exit if still not connected after 15 seconds
					#
					if counter is equal to 15 then
						display dialog "VPN '" & _vpn_name & "' is still not connected after 15 seconds. Do you want to keep waiting?" with title "VPN still not connected" buttons {"Yes", "No"}
						if button returned of result is "No" then
							# bail out if user decided not to wait any longer
							#
							set _retval to true
							return
						else
							# otherwise reset the counter so we can trigger again
							#
							set counter to 0
						end if
					end if

					set counter to counter + 1
					delay 1
				end repeat
			end repeat

			# now go to post processing and to the following:
			# - delete default route via vpn
			# - restore original default route
			# - add specific routes to vpn
			#
			if current configuration of service _vpn_name is connected then
				# restore local default route
				#
				do shell script "route delete default" password _sudo_password with administrator privileges
				do shell script "route add default " & _default_gw password _sudo_password with administrator privileges

				# inject custom routes via VPN
				#
				repeat with _network in _networks
					do shell script "route add -interface " & _network & " utun0" password _sudo_password with administrator privileges
				end repeat
			end if
		else
			# bail out if the VPN service does not exist
			#
			display dialog "Given VPN '" & _vpn_name & "' does not exist. Please check the name"
		end if
	end tell
end tell

Now I was digging around if I could do some automation on the GUI part, which indeed turned out to work … at least to a certain degree.

Let’s face it: Ripping DVDs with MakeMKV is simple and easy, however its scripting abilities s***

There is actually some limited CLI support available. If you dive into the application package, you’ll find the /Applications/MakeMKV.app/Contents/MacOS/makemkvcon program, which can be scripted somehow.

In the first place, I was perfectly able to rip off a complete DVD using the CLI command. But that was not what I had in mind, because I wanted to select only the main movies, and there only a limited set of audio streams and subtitles.
As I seemed to be unable to figure out, how that would be possible (some rare comments on the MakeMKV forums mentioned, that it would NOT be possible), I ended up using the GUI.

Well, after I wrote the auto-selector script, I started thinking on how to make this a bit more practical.
I know Apple released support for GUI (graphical user interface) scripting already years ago, but I had never really looked into until today

After some reading over there at macosxautomation.com I started on extending my script.
Please consider that you need to enable support for assistive devices, as mentioned on macosxautomation.com — otherwise the script will simply fail.

With help of UI Browser, a utility to explore GUI elements of any application, I was able to identify the relevant items.

So with the latest additions, the script does the following:

• Runs whenever a DVD is inserted
• Automatically run DVD Player if no action is taken – or -
• run MakeMKV if requested to do so
• Wait for the DVD TOC (table of contents) to be read initially
• As soon as the TOC is read, open the DVD in MakeMKV
• Wait until the tracks selected were ripped and try to eject the DVD afterwards

And here’s the code:

# dvd-action
# ---
# an AppleScript utility to select DVD Player or MakeMKV
# upon inserting a DVD
# ---
# released "as is" under the terms of GPL v2.
# Copyright © 2011 Gianpaolo Del Matto 
# 
# r0.1 initial release 2011/12/09
# - simple selector with default action after timeout
#
# r0.2 2011/12/15
# - added limited GUI scripting functionality for MakeMKV
#
# r0.3 2011/12/16
# - added support to check for assistive device access
#	(code borrowed from http://www.macosxautomation.com)
# - added simple progress indicator while waiting for drive
#	do become available for access
#

# initialization
#
# true : show progress dialogs, false: hide progress dialogs
set verbose to true

# kindly borrowed from
# http://www.macosxautomation.com/applescript/uiscripting/index.html
# make sure that support for assistive devices is enabled
#
tell application "System Events"
	if UI elements enabled is false then
		tell application "System Preferences"
			activate
			set current pane to pane id "com.apple.preference.universalaccess"
			display dialog "This script requires access for assistive devices be enabled." & return & return & "To continue, click the OK button and enter an administrative password in the forthcoming security dialog." with icon 1
		end tell
		set UI elements enabled to true
		if UI elements enabled is false then
			display dialog "This script cannot run while access for assistive devices is disabled." & return & "Exiting now." buttons {"OK"} with icon 2
			return "user cancelled"
		end if
	end if
end tell

# check if DVD Player or MakeMKV are already running
# if not, present a little menu, that allows to select
# which application should be run
#
if not appIsRunning("DVD Player") and not appIsRunning("MakeMKV") then

	with timeout of 3600 seconds
		display dialog "Please choose your desired action:" with title "Action for DVD" buttons {"Cancel", "play DVD", "rip DVD"} cancel button "Cancel" giving up after (5)
	end timeout
	if button returned of result is "rip DVD" then
		if verbose then display dialog "Starting MakeMKV" buttons {"OK"} giving up after 2
		tell application "MakeMKV" to activate
		repeat
			if application "MakeMKV" is running then exit repeat
			delay 5
		end repeat

	else if button returned of result is "Cancel" then
		return
	else
		if verbose then display dialog "Starting DVD Player" buttons {"OK"} giving up after 2
		tell application "DVD Player" to activate
		return
	end if

end if

# check again if MakeMKV is running
# this time, attempt to automate these steps:
# - automatically open the DVD as soon as the drive is ready for access
#
if appIsRunning("MakeMKV") then
	# now tell MakeMKV what to do
	tell application "System Events"
		tell process "MakeMKV"
			# in some rare cases, the menu bar items will stay "greyed out"
			# even if a DVD was inserted
			# the culprit: "AXEnabled" property of the menu will be TRUE even then,
			# although the menu items are not clickable
			# There seems to be no way to check, if they're actually active or inactive
			# However, as a workaround, sending CMD+O to fire up the "File - Open" dialog
			# seems to work, and yet: just opening and closing it will enable the menu bar
			#
			set _retval to false
			repeat until (_retval) is true
				try
					tell application "MakeMKV" to activate
					keystroke "o" using {command down}
					delay 1

					if (exists window 1) and (exists window 2) and (value of attribute "AXRoleDescription" of window 1) = "dialog" then
						click button "Cancel" of window 1
						set _retval to true
					end if
				end try
				delay 1
			end repeat

			# note on the dvd drive selection and menu handling:
			#
			# because we don't know the name of the DVD device,
			# we simply address it by the id of 'menu item 1'
			# so we're just selecting the first device found there.
			# we might have more than one DVD drive, but this is out of scope for now
			#
			# this script was initially triggered by inserting a new disc
			# thus we need to wait until the disc is initially read
			# while this is in progress, our 'Open disc' menu item will be disabled
			#
			set _retval to false
			repeat until (_retval) is true
				try
					repeat while (value of attribute "AXEnabled" of menu "Open disc" of menu item "Open disc" of menu "File" of menu bar item "File" of menu bar 1) is false
						get value of attribute "AXEnabled" of menu "Open disc" of menu item "Open disc" of menu "File" of menu bar item "File" of menu bar 1
						set counter to 5
						repeat while counter is greater than 0
							if verbose then display dialog "Waiting for dvd drive to become ready for use ..." with title "Please wait …" buttons {"" & counter & ""} giving up after 1
							set counter to counter - 1
						end repeat
					end repeat
					set _retval to true
				on error
					display dialog "error"
				end try
				delay 1
			end repeat

			# seems that the dvd drive is now ready for use, now try to load the disc
			#
			if verbose then display dialog "Trying to load DVD in MakeMKV now …" giving up after 1

			# now load the drive
			#
			tell application "MakeMKV" to activate
			click menu item 1 of menu 1 of menu item "Open disc" of menu 1 of menu bar item "File" of menu bar 1

			# now stay and wait until another window appears
			# this should be "completed" dialog at the end
			#
			repeat until ((exists window 1) and (exists window 2))
				delay 15
			end repeat

			# check the type of window 1, which should be a dialog
			# if so, let's close it and try to eject the disk
			#
			if (exists window 1) and (exists window 2) and ((value of attribute "AXRoleDescription" of window 1) = "dialog" or (value of attribute "AXRoleDescription" of window 1) = "standard window") then
				click button 1 of window 1

				click menu item "Eject disc" of menu 1 of menu bar item "File" of menu bar 1
			end if

		end tell
	end tell
end if

# func:appIsRunning
#	appName	: string : name of application (e.g. "DVD Player")
#
# helper to check if application is running or not
#
on appIsRunning(appName)
	tell application "System Events" to (name of processes) contains appName
end appIsRunning

This, as far as it goes, saves at least the additional button click to load the DVD in MakeMKV.
However, there is one drawback after all …

While examining the MakeMKV GUI, I figured that the main panel was not recognized by UI Browser. It was just reported as unknown (UI element #4). Unfortunately there was no obvious way to get access to the elements within that panel.
This – as of today – effectively limits the use of GUI scripting, as it is not possible to interact with the elements within that panel.
Otherwise, I’d be happy to sit down and write the part, which does auto-selection of the track elements according to some given criteria.

So I sought a way to have my OS X give me the choice to either start DVD Player or MakeMKV upon inserting a DVD.

First I wrote a little AppleScript which gives me the choice. If I’m not taking any action, it will play the DVD automatically after 5 seconds, so it’s very similar to the default behaviour of OS X.

So just run Apple Script-Editor and store this code to a convenient location you like (usually it’s ~/Library/Scripts).

if not appIsRunning("DVD Player") and not appIsRunning("MakeMKV") then
	with timeout of 3600 seconds
		display dialog "Bitte wählen Sie gewünschte Aktion:" with title "Aktion für DVD" buttons {"Cancel", "DVD abspielen", "DVD rippen"} cancel button "Cancel" giving up after (5)
	end timeout
	if button returned of result is "DVD rippen" then
		display dialog "Starte MakeMKV" buttons {"OK"} giving up after 2
		tell application "MakeMKV" to activate
	else if button returned of result is "Cancel" then
		quit
	else
		display dialog "Starte DVD-Player" buttons {"OK"} giving up after 2
		tell application "DVD Player" to activate
	end if
end if

on appIsRunning(appName)
	tell application "System Events" to (name of processes) contains appName
end appIsRunning

Then go to system properties and select CDs & DVDs properties. Beneath “When you a insert a Video-DVD” choose “Run Script” and locate the script file you created before.

From now on, you’ll be presented with a selection prompt. Doing nothing will automatically start the DVD Player, or the DVD Ripper, if you choose to do so.
Quiet cool, isn’t it?

Well, yes, most of the time, they do. Though in my case, I run that nice and decent System47 LCARS-style screen saver. And while it provides indeed a mute switch, it yet refuses to honor that flag and will always revert to non-muted operations. This drives me crazy, at least during the night time.

So here’s my solution to shut it quiet — really handy when I’m not along and forgot to turn volume down …

The key to it lies with a small Automator script, which I hacked up and which you can download here.

It basically consists of an endless loop, which will sleep some time, wake up, check if the screen saver is running and mute the speakers if that’s the case.
It will also unmute the speakers if the screen saver is not running, e.g. when you return to the work place.

So first download the file and extract it to your desktop.
Then double click the file to import it to Automator.

You’ll end up with the script being added to your “Services” menu.

Now open up your control panel and go the the Users & Groups preferences. Select your account and navigate to Startup Items.

Click the + icon to add a new startup item. Use Finder to navigate to the Library folder below your home directory and then locate the Shutting Speakers on Screen Saver automator script beneth the Services folder.

Note for OS X Lion Users: You may not see the Library folder in the first place due to restrictive defaults on Lion. If that’s the case, open a Terminal and type this command in there:


chflags nohidden ~/Library


This will enable the Library folder to be seen within Finder.

Now select the Shutting Speakers on Screen Saver. It will be added to your startup item preferences.

The script will now run everytime after logon, so you won’t need to care about having the system muted or not.
If you want to run it now without logoff/logon, just go to Finder menu and click on Shutting Speakers on Screen Saver on the Services submenu.

Enjoy the silence

Here’s how to do it with a PIPE:


[gianpaolo@localhost ~]$ cat filename | perl -e 'print reverse <>;'


You can also run it directly on a filename like this:


[gianpaolo@localhost ~]$ perl -e 'print reverse <>;' -f filename


You can do it with ‘sed’ as well:


[gianpaolo@localhost ~]$ cat filename | sed -n '1!G;h;$p'
[gianpaolo@localhost ~]$ sed -n '1!G;h;$p' filename


Personally I favor the Perl method as it’s easier to memorize, despite having more to type
Enjoy!

Before you start digging around using some fancy conversion in Perl, check out the ‘date’ command first.

Here’s a little snippet on how to do it on Linux:


date -u --date="1970-01-01 1285250916 sec GMT"


This will convert your timestamp 1285250916 into it’s date representation of Thu Sep 23 14:08:36 UTC 2010.

As always, there’s slight variations with Linux and BSD userland. To achieve the same on OS X and FreeBSD (maybe other BSDs as well), here’s the appropriate command:


date -j -f %s 1285250916


And for Perl lovers anyway, here is the Perl command


perl -e "print scalar localtime (1285250916)"


As such it’s very easy to capture the output using backticks and use it further on in your scripts. The date command comes in as a last resort especially if you’re working in a restricted environment where higher level languages such as Perl may be unavailable. Though one notices Perl is more versatile than the date command – the later having slight syntactical variations between distributions and vendors propably causing some headache. This opts for the use of Perl if you want to be more platform independent with your script.

<? eval(gzinflate(str_rot13(base64_decode(‘DZe3DsTWEV —-shortened—- Z9//g8=’)))); ?>

The De-Scrabmler works on obfuscated blocks containing eval()’ed code created through gz_deflate(), base64_encode() and str_rot13() functions.

It’s very simple to use even for non-pro’s. Just copy-paste the scrambled text block into the form and let the De-Scrambler do the rest.

Sample view of scrambled code in a WordPres Theme:

some arbitrary command
if [ "$?" = "0" ]; then
   do something
else
   do something else
fi

Or even more simplistic:

some arbitrary command && { do something; } || { do something else; }

There are more ways to do this. But they all have in common, that it is hard to trap and trace unknown errors, especially if the script runs unattended.
If you want to do some logging and tracing, then you would need to implement a routine which you would need to add to each and every block, to ensure you don’t miss some particular important information.
Even if it is a simple function for error reporting, let’s call it error_reporter, you would end up with something like this:

some arbitrary command
if [ "$?" = "0" ]; then
   do something
   error_reporter args
else
   do something else
   error_reporter args
fi

But sometimes it’s better to have an error handler, which is able to catch errors and do some special actions, while still allowing your script to continue within the normal flow. Even better if that particular error handler also catches and notifies upon yet-unknown and never discovered errors.

Let’s assume a script, which is trying to delete a directory. For the sake of this example, the directory MUST NOT exist, so the script effectively fails upon execution.
We handle the error simply by checking on the non-zero exit code.

Please note: The following code serves as an example of bad script programming. Never (as in NEVER) try to delete something without checking for it’s existence first! You’ll find a proper code sample at the end of this article

#!/bin/bash

# try to delete non-existing directory
#
rmdir /ksdjhfskdfkshd
if [ "$?" = "0" ]; then
        echo "ok: directory deleted."
else
        echo "failed: directory not deleted."
fi

This script will try to delete the non-existing directory. As ‘rm’ will not find it, it will return a non-zero exit status, leading to this program output:

$ bash test.sh
rm: /ksdjhfskdfkshd: No such file or directory
failed: directory not deleted.

So far, so good. The error was caught and nothing really bad happened, we even got kinda useful error message from the script itself.
Now, let’s think about scripts, which usually run unattended, maybe invoked through cron.
Any halfway serious admininstrator would at least try to capture the error output from cron by redirecto STERR and STDOUT to a logfile.

*/5 * * * *	root	/var/scripts/somescript > /var/log/somescript.log 2>&1

But, to be serious, how often would you really check on these logfiles?

Of course, you can have cron configured to send you the script output after every run.
If you use an output redirection as shown above, you could even write another script, which sends these logfiles to you.
This is good enough, you’ll end up with dozens if not hundreds mostly useless emails, which you’ll most likely never ever get to read.

Wouldn’t it be great to have the script report any runtime errors to you by email, directly into a database or via SNMP traps, but only in the event of some real importance to look at?
In this case, you’ll end up with error reports driven by occurence. So you KNOW that it’s important and some action needs to be performed.

Luckily enough Bash provides us with a very simple TRAP interface, which allows to run additional, event-driven code, upon occurence.
We can trap nearly every thing, from EXIT to CTRL-C, over SIGNALS up to ERROR status (you’ll find more about this in the Bash info page).

To trap an ERROR status, we need two things: A trap handler and a trap command.
The first is some code, which does any particular action, for example assemble error information and send it by email, while the trap command itself specifies, under what condition it needs to be invoked.

A trap handler could look something like this:

function my_trap_handler()
{
        MYSELF="$0"               # equals to my script name
        LASTLINE="$1"            # argument 1: last line of error occurence
        LASTERR="$2"             # argument 2: error code of last command
        echo "${MYSELF}: line ${LASTLINE}: exit status of last command: ${LASTERR}"

        # do additional processing: send email or SNMP trap, write result to database, etc.
}

To have the trap handler executed, you need to add a “trap” statement to the script. As we want the trap_handler to be invoked only upon a command failure, we consider only the ERR trap, which catches non-zero exit codes only.

trap my_trap_handler ${LINENO} ${$?}' ERR

Let’s have a look at the completed script now.
To demonstrate how accurately the trap handler works, I added some further commands. These commands have been designed so that they WILL fail for the sake of documentary purposes.

#!/bin/bash

# trap handler: print location of last error and process it further
#
function my_trap_handler()
{
        MYSELF="$0"               # equals to my script name
        LASTLINE="$1"            # argument 1: last line of error occurence
        LASTERR="$2"             # argument 2: error code of last command
        echo "${MYSELF}: line ${LASTLINE}: exit status of last command: ${LASTERR}"

        # do additional processing: send email or SNMP trap, write result to database, etc.
}

# trap commands with non-zero exit code
#
trap 'my_trap_handler ${LINENO} $?' ERR

# let's do some rubbish
#
rm /ksdjhfskdfkshd
if [ "$?" = "0" ]; then
        echo "ok: directory deleted."
else
        echo "failed: directory not deleted."
fi

# next is line 30
format c:                       # ;-)

# next is line 33
ls /fdkjhfskdhfks

This sample code will result in the following output at runtime. I added the line numbers in front on my own for better illustration.

$ bash test.sh
1:  rm: /ksdjhfskdfkshd: No such file or directory
2:  test3.sh: line 22: exit status of last command: 1
3:  failed: directory not deleted.
4:  test3.sh: line 30: format: command not found
5:  test3.sh: line 30: exit status of last command: 127
6:  ls: /fdkjhfskdhfks: No such file or directory
7:  test3.sh: line 33: exit status of last command: 1

Now, the first line of output shows the error thrown by the ‘rm’ command.
The second line shows the output from the trap handler, stating exactly WHERE the error occured (test.sh / line 22 / last exit status).
The third line shows the output of the local error handling routine.
Line four gives us the “format” command not found, while line five is the message from the trap handler.
Line six and seven are the “ls” for the non-existing directory and the trap handler message corresponding to it.

Looking into this outline it quickly becomes clear, that a trap handler can help us a lot in event-driven debugging with just adding a few lines to existing scripts without tampering with existing error handling code.
This script design even permits you to track and trace errors on single-line commands, which you almost never believed to fail.
Even if they fail one day due to unlikely events, you can at least point out WHERE it failed, which makes debugging a lot faster and easier.

And now, finally, the completed script code, as any decent script writer should be propably doing it using some pre-action checking as well.

#!/bin/bash

# trap handler: print location of last error and process it further
#
function my_trap_handler()
{
        MYSELF="$0"               # equals to my script name
        LASTLINE="$1"            # argument 1: last line of error occurence
        LASTERR="$2"             # argument 2: error code of last command
        echo "${MYSELF}: line ${LASTLINE}: exit status of last command: ${LASTERR}"

        # do additional processing: send email or SNMP trap, write result to database, etc.
}

# trap commands with non-zero exit code
#
trap 'my_trap_handler ${LINENO} $?' ERR

# we need to process the DIRECTORY at /ksdjhfskdfkshd
#
my_directory=/ksdjhfskdfkshd

# test if the directory exists
#
echo -n "check if directory exists: '${my_directory}': "

if [ -d "${my_directory}" ]; then
        echo "ok."

        # try to delete the file
        #
        rmdir "${my_directory}"

        # try to handle delete failure (exit != 0)
        #
        if [ "$?" = "0" ]; then
                echo "ok: directory deleted."
        else
                echo "failed: directory not deleted."
        fi
else
        echo "failure, directory does not exist or is not a directory."
fi

# we're done
#
exit

This would result in the following output. The trap is completely circumvented by testing the directory for it’s existence before deleting it.

$ bash test.sh
check if file exists: '/ksdjhfskdfkshd': failure, directory does not exist or is not a directory.

One more thing to consider is what happens, if a trap is caught within a control structure block (IF, WHILE, etc).

To illustrate this, I create the directory I wanted to delete, so the script will dive into the IF-THEN-ELSE-FI block.

$ mkdir /ksdjhfskdfkshd

I then changed the “rmdir” command within the script to “rmdiir” (misspelled), so it WILL fail upon execution.
Please note the script output we get this time:

$ bash test.sh
check if file exists: '/ksdjhfskdfkshd': ok.
test.sh: line 34: rmdiir: command not found
test.sh: line 45: exit status of last command: 127
failed: directory not deleted.

While Bash itself states the misspelled command being on line 34, the trap catches the error on line 45.

Now, why is this?

The reason for this is very simple: Any control structure is regarded as some sort of multi-line command within the script.
So when the trap catches the erronous command on line 34, it sees it’s origin on line 45 because the “IF-THEN-ELSE-FI” clause ends on line 45.

The same happens if you use any other control structure.

The trap in this case is only capable of outlining the “general direction” to where the error happened, but it cannot pin-point to it.
So it’s still recommended to also capture the script output, either by redirecting the script output manually from the shell, or more elegantly by adding some lines to the script, which always redirect the output (STDERR and STDOUT) to a logfile automatically.

In the end, the trap handler could be setup to send and email using both information from the intercepted trap and the logfile.

So the final script may look like this:

#!/bin/bash

# initialize upon startup
#
my_temp_dir=`mktemp -d /tmp/test.XXXXXX`		# we want a unique temp dir
my_log_file=${my_temp_dir}/output.log
my_out_pipe=${my_temp_dir}/output.pipe

# initialize output redirection
#
mkfifo ${my_out_pipe}                                   # we need a FIFO for the output pipe
exec 3>&1                                               # assign a new file descriptor 3 to STDOUT
tee ${my_log_file} &3 &               # background redirect file descriptor 3 throught the FIFO
tee_pid=$!                                              # store the PID for 'tee'
exec 2>&1 > ${my_out_pipe}                              # redirect STDERR and STDOUT to the output pipe

# do some final cleanup upon exit
#
function my_exit_handler()
{
     exec 1>&3 3>&-                                    # restore file descriptors
     wait ${tee_pid}                                   # wait for 'tee' to exit

     # remove temp dir upon exit
     #
     #[ -d ${my_temp_dir} ] && rm -rf ${my_temp_dir}
}

# trap handler: print location of last error and process it further
#
function my_trap_handler()
{
        MYSELF="$0"               # equals to my script name
        LASTLINE="$1"            # argument 1: last line of error occurence
        LASTERR="$2"             # argument 2: error code of last command
        echo "script error encountered at `date` in ${MYSELF}: line ${LASTLINE}: exit status of last command: ${LASTERR}"

        # do additional processing: send email or SNMP trap, write result to database, etc.
	#
	# let's assume we send an email message with
	# subject: "script error encountered at `date` in ${MYSELF}: line ${LASTLINE}: exit status of last command: ${LASTERR}"
	# with additional contents of ${my_log_file} as email body
}

# trap commands with non-zero exit code
# trap script EXIT
#
trap 'my_trap_handler ${LINENO} $?' ERR
trap 'my_exit_handler' EXIT

# we need to process the DIRECTORY at /ksdjhfskdfkshd
#
my_directory=/ksdjhfskdfkshd

# test if the file exists
#
echo -n "check if file exists: '${my_directory}': "

if [ -d "${my_directory}" ]; then
	echo "ok."

	# try to delete the file
	#
	rmdir "${my_directory}"

	# try to handle delete failure (exit != 0)
	#
	if [ "$?" = "0" ]; then
	        echo "ok: directory deleted."
	else
	        echo "failed: directory not deleted."
	fi
else
	echo "failure, directory does not exist or is not a directory."
fi

# we're done
#
exit

To conclude this: Adding some further logic to a script using output redirection and traps adds some great debugging aid, especially when it comes to unknown and yet-undiscovered errors.
The implementation requires just a few additional lines to work with any script and will save countless hours worth of debugging.
Also, the sample trap handler presented herein can be extended to do virtually anything, from adding additional information like the environment, to submitting errors into a MySQL database, sending SNMP traps, or whatever you could imagine.

Dough! Bad Idea! Bad command or filename. Smash your head here to continue {(x)}!

So I winded up my memories from stoneage. Wasn’t there the choice command!?

Yeah, after some lurking around with the ‘/?’ feature I had stuck it together:

choice /c 1 /d 1 /t 1 > nul

While

• “/c 1″ sets the choice values (1 is my value)
• “/d 1″ sets the default choice value (which is 1 from above)
• “/t 1″ sets the timeout to 1 second (or whatever is appropriate)
• “> nul” means the same as “>/dev/null”: send output to nirvana (notice there being only one ‘l’ however)

Of course this may be bothersome to type if you use it often, so a “batch function” may be better, especially when you need other batch tricks to get around DOS command limitations (lazy man’s approach: create a second batch file for it).

@echo off

rem *******************
rem check args
rem *******************

:checkargs

if "%1/" == "func/" goto callfunc
goto main

:_checkargs

rem *******************
rem call functions
rem *******************

:callfunc
 shift

 rem we could do "goto %1" instead
 rem if there is a lot of functions
 if "%1/" == "sleep/" goto sleep

 goto exit

:_callfunc

rem *******************
rem function sleep
rem *******************

:sleep
 shift

 choice /c 1 /d 1 /t %1 > nul

 goto exit

:_sleep

rem *******************
rem main body
rem *******************

:main
 echo hello, going to sleep now
 call %0 func sleep 1

 echo sleep is over, good bye

 goto exit

:_main

rem *******************
rem exit handler
rem *******************

:exit
 rem if there is anything left to do, do it now.

:_exit