Linux Aliasing: Short and sweet examples

Here is a dump of my most frequently used aliases when I'm in my shell (.bashrc):

		# quick and easy edits to shell without having to restart session
		        vi ~/.bashrc;
		        . ~/.bashrc;
		# because I use Cygwin a LOT these get me to my Windows files 
		# faster...
        		cd /cygdrive/c/Users/jwmcdill/Desktop/;

        		cd /cygdrive/c/Users/jwmcdill/Downloads/;

		alias shelledit=envEdit
		alias desk=cdDesk
		alias dload=cdDown

You'll notice I define my aliases as funtions which I 'call' further down in .bashrc. I do this because it just makes sense to me. I COULD define and call them all at once, but I prefer breaking the two motions apart. You are free to do as you wish in your shell :)

Next, I wanted to show a little work I've done with Expect within .bashrc:

        		expect -c "
        		spawn ssh -o LogLevel=ERROR $1
        		set send_human {.1 .3 1 .05 2}

        		expect {
                		\"password: \" { send -h \"password\r\" }
                		\"Password: \" { send -h \"password\r\" }
                		\"No route to host\" { exit 1 }
        		expect {
                		\"N]?\" { send \"y\r\"; send -h \"password\r\" }
                		\"no)?\" { send \"yes\r\"; send -h \"password\r\" }

First, the elephant in the room: "PASSWORD???!!". Yes, that is a hard coded password placeholder. Ideally the most secure connections use keys to avoid the issues of passwords. In some cases though if keys aren't an option due to SSH configurations, you have to use passwords. When I find a better way to hash a password like this, you all will be the first to know. Until then, this is a workable solution for pseudo automating your SSH connections without keys. In a secure environment (private network, encrypted disks, etc), you have bigger problems if such a file gets snagged.

Now to the explaination. This expect script obviously makes an SSH connection. Big woop. Nothing too special, just take note of the "set send_human" param at the top as well as the 'interact' param at the bottom.

The former basically gives expect a more human timeframe in which to send the "key strokes" over SSH. Without it your login will likely fail due to the computer firing the commands off faster than the connection can be established.

The later makes the spawned SSH session interactive so you stay logged into the target machine.

My next example shows another SSH example that in NON-interactive: