Thats right. You’ve all read tutorials. They range all over the place: boring, brief, detailed, useless, inspiring, the list goes on. There are those that are too technical, that you don’t understand until you look back at them at a later date. In the case of Unix and Linux the majority of the tutorials are like that. They are just reworded man pages. Many people turn away from *nix because of this gap in technical familiarity. My Unix tutorial aims to change this.

I have read a number of tutorials and I find the best are the ones that include you, the reader, in them. You are participating in the tutorial. Often there is a story, or some creative aspect that brings you into the tutorial. You are learning in an entertaining way. For first timers this can make all the difference.

My tutorial also gives tips and tricks for using the terminal. They are the kind of tricks that make using the console much easier, but they are the tricks that you often don’t know unless someone shows you. I hope that my tutorial at least gives insight to newer Unix/Linux users as they take the leap into a new realm.

Please take a look and offer your feedback to help me improve the tutorial. I now present my Unix Tutorial.

I would like to point out that the tutorial happened to be a college project that I recently decided to turn into a reality. I have been and will be refurnishing the tutorial with improvements (sIFR), more rich content, while still maintaining my original goals and objectives.

Inspiration: A rather stimulating Ruby tutorial that wraps you inside a rather creative story, with “synergy and cartoon foxes.”

Programmers are notorious for solving puzzles and games. Essentially code golfing was born from that mind set. The goal of golfing is to get the lowest score. Code golfing as defined from the Code Golf home is:

Based on the original perl golf, Code Golf allows you to show off your code-fu by trying to solve coding problems using the least number of keystrokes.

Essentially the goal is to make your program as small as possible. The fewest bytes, the fewest characters, the smallest it can be. I am rather new to the sport but from what I have gathered it really kicking into action when scripting languages like Perl became popular. The original golf was Perl golf, as mentioned in the quote. Perl is a really cool programming language. Its powerful and robust but most importantly its fun to program. Its syntax is simple and its special variables and dynamic typing make it a joy to use. Interested in learning? However, recently languages like Ruby, PHP, and Python have shown they are just as effective.

How about an example? Lets start with something really basic. Lets add all of the numbers from 1 to N, where N is the number the user provides on the command line. A traditional approach might look like:

#!/usr/bin/perl
use warnings;
use strict; 

my $N = $ARGV[0];  # The given upper limit
my $sum = 0;       # To hold the summation

# Perform the summation
for ($i = 1; $i < $N; $i++) {
  $sum += $i;
}

# Print the result
print $sum, "\n";

Here was my Perl solution weighing in at 28 bytes complete with the terminating newline:

map$i+=$_,1..pop;print$i,$/

Example output:

$ perl sumToN.pl 15
120

It is completely possible that there might even be a smaller solution using a different approach, but you can see what is happening. The code is massively condensed to the point where there is nothing extraneous, nothing but pure code.

For those of you who are wondering why would anyone ever want to do this… you are forgetting that this is merely a game. Its a challenge, a puzzle to occupy your time and entertain your brain. As with all games you get better with practice, you learn new tactics and tricks, my original solution weighed in at 29 bytes using a for loop until I experimented with the map function to cut two characters. Golfing tests your knowledge of the language and helps you learn the secrets at the same time. When is a space or a semicolon necessary? Do I need to create an extra variable? It may not look like it from above, but you will become a better programmer.

More challenges include:

1. Converting Roman Decimals to Decimal Numbers
2. Drawing an Egg Timer of size N (Very Cool)
3. Prime factorizing numbers

The list of games are endless, and the solutions equally immense. So what are you waiting for, take a swing at this challenge inspired by Worse Than Failure (the DailyWTF). Generate a random password of N length of alphanumeric characters (lowercase, uppercase, and numbers). Simply state your language of choice. Remember that the input length N, is provided on the command line as if you were to run the command from your terminal. My solutions weighed in at 59 bytes but I have a very cool 61 byte solution. Here is some example usage for you to work off of:

$ perl genpassword.pl 35
Pm0vfue12fWB45Ctr4Zc2zXNt5wkREGHQan

I had always wanted to learn Perl. I had a few brief encounters with it, using my php knowledge to drive my Perl programming in a very php styled way. However, I knew Perl could do so much more. I had nearly one week free and decided to give Perl a serious chance. I happened upon a great book available free from perl.org and was more than pleased.

Beginning Perl is available in PDF form for free from the Perl website. The book gives a very high quality, engaging, and through description of Perl. If you have been interested in learning Perl give this book a go and I assure you that you will get hooked into how the author daftly portrays subjects and concepts with excellent concise code examples and explanations. This is the kind of programming book that every programmer searches for. It is so engaging you will find that you will go through a chapter a day. The author has a gift for breaking subjects down to simple concepts, which is after all the real core of programming.

Make sure that you print out the appendixes. Read them over if you really want to grasp the full power of Perl and its endless options, special variables, and famous regular expressions. The actual chapter on regular expressions even tipped me off to certain tricks that I was even unaware of (lookaheads and lookbehinds). However if you are looking for a more general explanation of regular expressions I still recommend the links that I posted at the bottom of this article.

Many have considered Perl to be a confusing language. The book’s introduction declares that it means to dispel that rumor. Here is the direct quote from the introduction, hopefully it will motivate some of you to grab the PDFs and take a look:

However, since Perl is so easy to learn and to use, especially for quick little administrative tasks, ‘real’ Perl users tend to write programs for small, specific jobs. In these cases, the code is meant to have a short lifespan and is for the programmer’s eyes only. The problem is, these programs may live a little longer than the programmer expects and be seen by other eyes too. The result is a cryptic one-liner that is incomprehensible to everyone but the original programmer. Because of the proliferation of these rather concise and confusing programs, Perl has developed a reputation for being arcane and unintelligible - one that I hope we can dispel during the course of this book.

I will admit that the book is flawless in its persistence of providing full quality Perl scripts. I always strive to optimize my code, normally trying to increase efficiency and readability in my algorithms. However, Perl’s incredible flexibility does allow programmers to do some rather unbelievable tasks in well under 100 bytes (1 byte = 1 character). I will soon write an article about the dark side of every programmer… code golfing.