Perl is great for making small tools for small tasks. I think grabrandom.pl really exemplifies this. Perl also lets you do some great things that are tough in other languages. By hashing flags to function references in password_test.pl , I was able to easily parse flags independent of what their special meaning was, but could easily extend a special meaning through defining a function and mapping it to its flag in the hash. In addition to hashes and function references, perl stands out from previous scripting styles by being able to multitask and handle signals, as shown by phork_pak.pl .

numbersq_sudoku.pl

I really like this little program. With it, I can quickly solve those number squares. Or I could create a new one. If you don't know, this number square is a 9x9 matrix where each row must contain all the digits from 1 to 9, and similarly with each column. Additionally each subsquare must only contain the digits 1-9. A subsquare is a 3x3 (non overlaping) square inside the main square. Previously someone told me they were called euler squares, but that's a case of latin squares, most english speaking westerners call them sudoku. Wikipedia claims the US invented them, but then Austrailia claimed it invented the gateless cow enclosure that had long been in use in switzerland... so people arn't normally right about uncredited inventions.

In this program I use a bunch of arrays of arrays as well as a little trickery on the terminal; thus it should only be run on a vt100 compliant terminal (i.e. xterm etc). The display shows what digits are possible in each location. You enter the column, row and value that you wish to set a location to. The program will calculate the interactions with the other squares. This eventually leads to a solution. Thus you can enter the known squares of a given puzzle to get a solution (sort of dull, but good for checking your work) or you can give someone else your hand picked squares as a puzzle that they could solve.

update July 26th 2005: I just fixed the script so that you couldn't lock it with this sequence: 1,1=9; 2,4=9; 4,7=9; 7,8=9; 3,9=8. Instead, it now implies properly: 1,1=9; 2,4=9; 4,7=9; 7,8=9; ->3,9=9. However it still doesn't backtrack, which I just realized is going to be important. Maybe I can use the simplex linear programming solver to check squares. But then its a totally different program.

This program uses vt100 codes to output 3 different styles of random characters. Either by row, columns, or in random locations. It doesn't look as cool as "The Matrix"'s screen saver, but it is neat. I've been thinking of adding a higher percentage of blank output to keep the screen a little more lightly filled.

This is a perl script written for use by shell scripts or configuration files. I wrote it to select a random desktop image for my window manager under solaris (which was blackbox). Its basic operation is as follows:

• Create a list of files and return a random selection from that list.
• The list will include every file in a directory specified as an argument to each -f flag. [subject to any -g or -G flags (see below)]
• The list will similarly include every file in a directory and its sub-directories specified as an argument to each -r flag. [subject also to -g and -G]
• Only files matching every pattern specified as an argument to a -g or -G flag will actually be added to the list. Patterns given through a -g flag are case insensitive, whereas those given with -G are case sensitive. [for more pattern info 'man perlre' ]
• The selection made will be output as text with the path of the directory prepended as it was given as an argument.

xv `$HOME/bin/grabrandom.pl \
	-f $HOME/images/nasa \
	-f $HOME/images/oni \
	-f $HOME/images/rkpost \
	-f $HOME/images/otherart \
	-f $HOME/images/ACiD/fave -g jpe?g$` \
	-rmode 5 -root -maxpect -quit &

Notice how the command's output was embedded as a parameter to the command which actually used the random file.

If you're into perl, you might have a chuckle at how simple it is to process these kinds of multiple arguments. Take a look at the "EXPLAIN"ed bit after line 34. It is about 3 lines of code to parse the arguments for easy internal use [reverse, foreach, push]. It takes more code to pretty print the result, which is actually commented out.

A friend had forgotten the password to the configuration page of their NAT box (DSL router). I sort of whipped up this here program to try all the possible permutations of the password. It's quite brute force. Because HTTP is stateless, it cannot directly track failed (or successful) login attempts. This allows the program to quickly go through many permutations without being locked out for 1-5 seconds at a time like some other passworded protocols. I had high hopes of success.

Of course I knew that at 20 passwords a second (which was my best rate for this box) and with an 8 character password, 94^8 / 20 / 3600 / 24 / 365, leads to about 9.66 thousand millennia of trying to guess a password.

Luckily my friend knew what the password might be, but purposely misspelled it with numbers in place of some but not all letters. This allowed me to limit each character set to a small set of about 4 characters, and the password was found in half an hour.

Special things to note about this program are that it parses its arguments very nicely once again (but in a different fashion from grabrandom.pl ) by using function references. Also it can generate a scrambled set of characters to allow the user to try longer passwords, and most importantly allow the user to logically progress through fairly random trials. This way an interrupted job may be started up from where it left off, as the program outputs the required arguments to pass in order to do just that. In addition this helps multiple machines progress through different trials of the same set without overlapping (much). Lastly, the user may limit password trials to only those matching a pattern, such as 3 consecutive alphabetic characters.

The --file and --display options were added because running multiple instances of this program on a netgear box, caused the poor thing to panic and occasionally just give you the requested file even though you didn't have the right password. Which isn't all that good for you, since you only get one file, and need to wait for each successive file you try until the box gives up again. Still this is a bad netgear defect.

This is a small framework to allow you to fork processes, track their exit values, and handle the results. It features an anti-zombie child reaper scythe [no joke], and will reap all its children when it recieves a SIGINT (^C) to prevent them from becomming zombies.

At one time I had an FAQ for this, but it must be sitting on that CD with all the contents of my EMC account that never made it to me. In lieu of this, I will try to explain the framework simply.

Put your program mostly between the 'main' and 'end main' comments. To fork a child process, call phork(), and pass it all the agruments you would to an exec() call [command arg1 arg2 ...]. It returns the child's PID, or die's if forking isn't working (I consider it that rare). Use the PID as a key into the hash %scythe, and set the value to a function that will handle the child's exit value. It will recieve the PID and exit value as arguments (in that order). If you don't care to handle the exit value, you may pass in \&bait as a the dummy function reference.

You should note that currently the child process has its STDOUT and STDERR suppressed for asyncronous background operation. Thus I wholey relied on the exit value to make decisions. However, I did consider that with modification to the phork function the parent process could read from the STDOUT or STDERR and write to the STDIN of the child. But at the time such functionality was not necessary.