Part 1

Today, we talked about revision control, and the variations it has gone through since its induction. We then proceeded to set up our own repositories on Lab 46's servers, using Mercurial. I have previously used Mercurial in Structure and Object Oriented Problem Solving with Joe, and I also use it in his C/C++ course. In his course, however, we use Bitbucket as a hosting service. I already feel proficient in using Mercurial on Linux systems, but using it on a dedicated server is new to me.

Today in class, we finished exploring the UNIX/Linux file system, and moved on into using the VI text editor. I've been using VI personally for about a month now, but I was still amazed at some of the new commands I started to learn. I had thought I was quite proficient in it, but a few of the new commands made me realize that I'm still just a starter to VI. Likewise, I had felt very productive in it before, but with some of the new commands I know that my productivity with it will increase even more. Specifically, using 'o' or 'O' to start inserting on a new line before or after a line, as well as using 'd' to select a line and 'd' a second time to delete that line. I look forward to learning even more tips and tricks to increase my productivity in VI.

Today in class, we started going over data streams and redirecting input and output.

A few of the main things we touched on were:

cat <filename>: Displays the content of a text file in the terminal echo: Returns a string to the terminal $: Indicates that what follows is a variable here strings: Inputs a variable into a command pipes (|): Allows you to use the output of one command as the input to another

We combined a few of these things into the command:

/usr/bin/who | grep $USER

This command returned to us our login sessions for Lab46

Today we began by talking a little bit more about scripting. I feel a little more comfortable about scripting now, after having worked with it a little for my first experiment. The first thing we talked about was that the shabang can point to different directories than /bin/bash. One of the main reasons for this would be if the script was written with a different language, such as perl, Python, or LUA. We then wrote a very basic script, which echoed a string, asked for an input, then echoed another string which contained the input.

Next, we wrote a second bash script. This script first picked a random value, then prompted the user to guess the value. The two numbers were then evaluated in an if statement which determined whether they were equal or not, and then printed a string telling the result.

Is it possible to create a bash script file on my local machine which will automatically connect to Lab46 over SSH and log me in?

http://askubuntu.com/questions/61963/can-i-create-an-ssh-login-script
According to this question asked on askubuntu.com, it is possible to not only create an SSH login script, but it's possible to set a terminal to automatically connect through SSH when it is opened. While this would be nice, I would much prefer creating a bash script, as I usually always have a terminal open and would find it much easier to type ~/filename.sh

Also, this website handles a passwordless SSH connection. This would not work, because Lab 46 obviously requires a password.

http://unix.stackexchange.com/questions/31071/shell-script-for-logging-into-a-ssh-server
According to this question thread on stackexchange.com, the expect command can be used to do exactly what I'm attempting to do. By creating a script file to first send the SSH command, then wait for a password prompt, and when the prompt is received send the password to the server.

Based on what I've read in regards to my question, I'm very confident that a bash script file can easily be written to automatically connect to Lab 46. It seems that other people have had success using the expect command in a script to do so.

To test my hypothesis, I will create a two .sh bash script files. The first file (461.sh) will be created solely using my preexisting knowledge of scripting, in an attempt to create the script in a way which I feel should logically work. Based on what I know, I feel that I could create a script file with the following code that will work (substituting the variable “mypassword” for my actual password. Ain't nobody stealing my logins!)

#!/bin/bash
#
# 461.sh - A script file to automatically connect to Lab 46
#
`ssh smeas@lab46.corning-cc.edu`
sleep 3
`mypassword`

In the second step of my experiment, I will use what I read from the http://unix.stackexchange.com/questions/31071/shell-script-for-logging-into-a-ssh-server question thread. I will first have to use apt-get to download the expect package. Then, basing my script completely off of the first answer in the question thread, I will create a second script file (462.sh). This script file will contain the following (again using “mypassword” instead of my actual password, to protect my sensitive materials!“)

#!/usr/bin/expect
#
# 462.sh - A script file to automatically connect to Lab 46
#

spawn ssh smeas@lab46.corning-cc.edu
expect "password"
send "mypassword\r"
interact

Based on my basic knowledge of scripting, this would first send the ssh command, then wait 3 seconds (which I figured to be an appropriate wait time to receive the password prompt), then send my password. I used the command `chmod +x 46.sh` to allow me to execute the script. Unfortunately, this script failed. It connected to Lab 46 and received the password prompt, but did not enter the password. I attempted to raise the sleep timer to 10, just in case it needed some more time, but it also still stalled out at the password prompt. I feel like my logic was correct, but my syntax was not.

Again, after saving this file as 46.sh, I first ran a `chmod +x 46.sh`. I then executed the script, and as I expected, it worked flawless. In a matter of seconds, I was sitting on the home screen of Lab 46.

Based on the data collected, my hypothesis was correct. It was possible to create an ssh connection/login script for Lab 46. There was more going on than I originally though, because I had to download a package which allowed me to use some more commands in a bash script.

One shortcoming of my experiment is that there may have been another way to do it. If so, however, I don't think it would have been any more optimized than my script was. My script involved downloading one very small package, and writing a four line script file. I feel there wouldn't be a more succinct way to achieve this.

Based on the experiment I performed and data I collected, I can ascertain that scripting is a very powerful tool to have in my arsenal. While the amount of time saved between logging in normally, and logging in with my script (which requires only five keystrokes) may only be a few seconds, but I feel like those few seconds will add up over time and make the initial investment more than worth it.

My biggest discovery in this experiment is that the bash scripting language is expandable. It is not limited to the commands available initially. Downloading the “expect” package gave me access to a number of other commands to increase the versatility of my bash script.