December 2008 Archives

There are two Emacs commands (that I've learned) which you can use while working with files that are under subversion version control:

(C-x v v) commit your changes - This will open a window allowing you to enter a comment. Press C-c C-c when you are done entering the comment.

(C-x v l) view the version change log for that file - This opens the change log in a second window, which you can scroll through. Use (C-x o C-x 1) to go back to your one window view.

These subversion commands, and about twenty others, are accessible from the 'tools' menu, under 'version control', which you can get to with the mouse in a X emacs session, or (M-`) in a console-only session.

I ran into an odd problem with the Alpine mail client, but was able to find the solution, so I felt it would be worth documenting for anyone who might run into this problem in the future.

I have been using Alpine for some time now to access the IMAP account that came with my web-hosting package. It had worked well on almost all my systems. However, I attempted to use Alpine on one system where my username on the local system (username@localhost) did not match the prefix part of my e-mail address (prefix@anexample.com).

I was suddenly unable to send e-mails (though I could receive them). I initially thought this had something to do with certificate-validation.

However, I found out that if I specifically specified what my "From: " header should be (instead of making Alpine guess), the problem went away. I believe the reason for this is that Alpine was using my local username in the From address. So when the e-mail was sent to my up-to-standard SMTP server, the e-mail was rejected as not having the correct sender name. (That's my theory, anyway.)

To set this yourself, go to (S)etup >> (C)onfig from the main menu, and set the "Customized Headers" field like so:

From: Full Name <youraddress@anexample.com>

So, you think you're good at 3D space arcade games? Well, try four dimensions.

I was meandering my Debian repos and found a game called Adanaxis. The games is basically like a 3D space arcade shooter, with one major difference: your targets also move across a fourth dimension of space. As a result, they are constantly moving in and out of phase with you, and you must move into phase with them in order to destroy them. (Or more precisely, your weapons must...)

The game is commercially developed, but the author released a GPL version of the game with the commercial media content stripped out.

Here's a screenshot: http://www.mushware.com/album_pic.php?pic_id=6&full=true

I recently started my first real C project. It is going to be a curses-based program launcher for *nix systems. It is meant to be an attractive and easy-to-configure tool for launching programs for those of us who prefer to work outside of a true GUI or windows manager.

This is something I would really like to have, and I have heard of other people interested in having such a tool.

Seed code for the project, and a screen-shot, are available from the main page: http://www.indicium.us/cgi-bin/pages/get?view=minmenu.

This hopefully clarifies another post regarding directory permissions. I don't think I wrote anything technically inaccurate, but some aspects of how directory permissions work were still a bit confusing to me.

I was playing around with test files and experimental permission settings to make sure I understood how permissions were inherited. Things didn't seem to be working how I thought they should, so I tried to research Unix permissions inheritance through google searchs. But I could seem to find very much info.

The reason for this, I eventually found out, was that Linux/Unix permissions are not inherited! Each regular file or directory file maintains its own permissions separately from the hierarchy.

So, when you assign permissions to a directory, you aren't passing down permissions to all the contained files and sub-directories and their sub-directories. You're just deciding what kind of access (permissions) are granted to that directory file.

The result is often the same, because if you deny someone the privilege of traversing the tree of a directory file and listing that tree, then obviously he doesn't have a way to gain access to the files in the directory.

Here's a snippet from wikipedia:

• The read permission, which grants the ability to read a file. When set for a directory, this permission grants the ability to read the names of files in the directory (but not to find out any further information about them, including file type, size, ownership, permissions, etc.)
• The write permission, which grants the ability to modify a file. When set for a directory, this permission grants the ability to modify entries in the directory. This includes creating files, deleting files, and renaming files.
• The execute permission, which grants the ability to execute a file. This permission must be set for executable binaries in order to allow the operating system to run them. When set for a directory, this permission grants the ability to traverse its tree in order to access files or subdirectories, but not see files inside the directory (unless read is set).

Not overly trusting of wikipedia, I tried an experiment on my Linux box. I went su, and then created the directory "testing" with the permissions 777. Then I created a sub-directory in "testing" called "testing2", and gave the sub-directory the permissions 755.

Then I switched back to my normal user. I tried to create a file in "testing2" called "blah", but was denied permission. However, I attempted to delete the subdirectory "testing2", and suceeded. This is because I had permission to modify the directory entries of "testing", but not the directory entries of "testing2".

If you made even a few visits to a Linux shell, you are familiar with program 'less'. This program is a terminal-based text viewing tool. Ironically, less has greater functionality than it's sister program, 'more'.

When I finally got around to viewing the man page for less, I realized that less has a host of advanced functionality beyond simply scrolling the text up and down on the screen. I was particularly helped when I found out it supports regular expressions.

If you enter a forward slash, followed by a regular expression, less will immediately move from your current position in the file to the next match. Unfortunately, the less man page does not indicate which regular expression system is being used, only that it uses the one installed on your system. However, I tried the following expressions and they worked fine (I was working with Bible text):

• /In the beginning -- matches the text 'In the beginning'
• /Jesus.*the -- matched text on a line where 'Jesus' was followed eventually by 'the'
• /1{2} -- matched text where the number 1 was repeated twice
• /6{1,3} -- matched text where the number 6 was repeated one, two, or three times
• /^when -- matched text that started a line with 'when'

My hats off to the developers of less. (According to the man page, that would be at least Mark Nudelman). It has helped me in my continuing quest to revert as much functionality as possible out of the GUI, and into the virtual console. One application of less is that now I can read the Bible in ASCII text format from a virtual console, using the regular expression functionality of less to quickly find the chapters and verses I am looking for. My 1 GHz web server (which has no GUI installed) is now also doubling as a Bible study station (along with its regular functionality as an e-mail client and an IRC client).

I knew that Linux directory permissions served a different purpose than they do for files, but I was a little confused as to how. Here is a brief snippet from http://articles.techrepublic.com.com/5100-10878_11-1047531.html.

• Execute permission is required for a user to cd into a directory.
• Read permission is required for a user to use a command such as ls to view the files contained in a directory.
• Execute-only permission allows a user to access the files in a directory as long as the user knows the names of the files in the directory, and the user is allowed to read the files.
• Write permission allows the user to create, delete, or modify any files or subdirectories, even if the file or subdirectory is owned by another user.

So if I understand correctly, the command 'chmod 755 directory_name' should give the owner of the directory full access, while allowing everybody else to list the contents of the directory and use individual files if the individual file permissions allow.

'chmod 700 directory_name' would completely lock out anybody but the owner of the directory.

'chmod 777 directory_name' would let anyone do whatever they want inside that directory, even if the individual file permissions and sub-directory permissions wouldn't normally allow it.

Also, regarding the sticky bit and sgid bit: If you set the sticky bit on a directory, this prevents all users from removing files from the directory, except for the file owner and the super user. If you set the sgid bit on a directory, then new files and sub-directories created within this directory will automatically inherit the group ID of the directory (rather than that of the user who created the file.)

I read that setting the directory bits can be useful in some settings for sharing files or making files publicly accessible.
 

I wrote a regular expression like this:

/^(.*)$sub_string(.*)$/

So that I could pull $1 and $2 from the string . However, I was expecting the regular expression would match the earliest instance of $sub-string. Actually, it always matched the last instance.

I found out from perlretut that this because regex quantifiers are by default greedy. In other words, the first .* in my regex will attempt to match the greatest number of characters possible, before passing the rest of the string onto $sub_string and the other .* combination.

So to utilize an earlier match of $substring, you need to make the first one non-greedy:

/^(.*?)$sub_string(.*)$/

A snippet from perlretut:

• a?? means: match 'a' 0 or 1 times. Try 0 first, then 1.

• a*? means: match 'a' 0 or more times, i.e., any number of times, but as few times as possible

• a+? means: match 'a' 1 or more times, i.e., at least once, but as few times as possible

• a{n,m}? means: match at least n times, not more than m times, as few times as possible

• a{n,}? means: match at least n times, but as few times as possible

• a{n}? means: match exactly n times. Because we match exactly n times, a{n}? is equivalent to a{n} and is just there for notational consistency.

Busy weekend. Spent all Saturday coding trying to meet a deadline for a project that was due.

Here's a few things I learned:

I installed mediawiki from the Debian repositories onto my testing web server, was easy. Then I figured out how to configure it, which was not quite as easy. If you don't know, mediawiki is the open-source software that runs sites like Wikipedia. (As usual, FOSS proves to the backbone of yet another of the most useful tools on the planet...) You can download mediawiki, or install it from your Linux repos, and run your own public or private wiki.

From my experience installing from Debian Linux repos, I have a few tips for the other newbies: for one, be sure to check out the online docs written specifically for Linux repo installations. Also, depending on how you've set up apache, you may need to add the option to your site file in /etc/apache for following symbolic links. For example:
       <Directory /var/www/>
                   AllowOverride AuthConfig
                   Options FollowSymLinks (and all the other options you need...)
                   (and all the other stuff that is supposed to be here...)
       </Directory>
Cause if you are doing a repo installation, the directory for the mediawiki files will not actually be in /var/www, only a symbolic link to it.  I put the 'AllowOverride' part in there as well because I wanted it to detect and use my .htaccess file, since I wanted the directory password-protected (a personal wiki).

That brings me to another thing I learned (or rather, re-learned) -- how to create my own .htaccess and .htpasswd files.

I also learned how to install CPAN modules from source packages into custom locations. The most important paragraph was near the beginning, where the instructions show how to specify to Makefile.PL where you want the module installed.

And I implemented CGI::Session and learned how to use it. It's pretty cool, and not too difficult to learn, though it did take me nearly an entire day to figure out how to implemented in my own code. Once you have some code written for creating and maintaining the session, it is pretty easy to copy the 'maintaining' part over to the rest of your scripts that will depend on that session. Here is the must-read tutorial in the docs.

Been crazy stinking busy lately. Finals week at school. Spent most of the last few days either at work, or trying to catch up on last minute late homework. (I hope I don't flunk that class, considering all the work I put into trying to hold things together...) Major project due very soon...

Did get some more work done on the admin side of my music database. Was able to get redirection to work:

# using the CGI module
# instead of a regular CGI header(), use...
print $cgi->redirect(-uri=>"$uri_to_page", -status=>303);

The -status part is the HTML status code. From what I understand, 301 is for a permanent redirection, 302 for a temporary redirection, and 303 if a resource hasn't actually been moved. That would fit my case, because the script is simply designed to point to another page after it has done it's job of creating a session.

The CGI docs say that $uri_to_page shouldn't be a relative address, and should even have the 'http:' part of the URI. I'm using a relative URI in my code, and it seems to work fine so far, at least on my server. I hope it doesn't cause anyone else a problem.

I wanted to post something I figured out about subversion the other day, for the rest of you version control newbies. After you add a file to your repository, if it is meant to be executable you should be sure to turn the svn executable property on for it. For example:

svn propset svn:executable ON filename.cgi

That way, if you revert back to a old copy, or check out a new working copy, you won't have to reset the file permissions on those files.

Oh, and here's a cool lecture I found on Youtube for Perl newbies... covers the basics well, if you don't mind the accent. (I like his accent, actually.) I'm not really a newbie anymore, but I still learned two or three things. Here's the link to part 1:

http://www.youtube.com/watch?v=1pVolaKhxVM&feature=related

You think you're a Perl fanantic? Well, maybe. But it takes a true fan to write a song about it, and put it to music:

http://www.youtube.com/watch?v=Mxk5RMQF6Js

Apparently the words were put to the tune of some well-known song. But since I listen to almost zero pop music, I'll just take his word for it.

I started work on the admin side of the music database. I began created the top-level structure for the CGI that will allow the user to enter his password and create a session. I hope this CGI::Session module works as well as advertised, because it seems pretty to cool and easy way to implement session management.

Side note: I thought I was something of a geek, but I realized I was only a geek-wanna-be after I watched this video:

http://www.youtube.com/watch?v=WVTWCPoUt8w&feature=related

It is a talk with Linus Torvalds, the original creator of the Linux kernel.

Here's a few Youtube videos you Linux fans mights enjoy:

Another battle between Tux and Microsoft:
http://www.youtube.com/watch?v=MYXZIbm4XTQ&feature=related
http://www.youtube.com/watch?v=GDSpP405O00&feature=related

How Linux gurus sometimes feel about Linux newbies:
http://www.youtube.com/watch?v=bPlDP8vlrRs&NR=1

I did more research into the CGI session management issue, and I found this nifty-looking Perl module called (brace yourself) CGI::Session. (More accurately, someone on the Seattle Perl User's Group mailing list pointed it out to me.) Basically, the module handles a lot of the bothersome details involved in maintain a web session, including creating and maintaining the session files, creating the session IDs, and passing the session ID around via cookie or parameter.

Biggest downside of the module so far is that it (very suprisingly) is not part of the core distribution.  And I haven't really seen it in action yet.  But I should know soon enough how well it works.

Had to do my first reverse-merge in subversion today. Basically, I committed some bad code to the repository, so I had to back up a reversion. Here was the command I used:

svn merge -r 53:52 manynotes.cgi

That did a reverse merge of the manynotes.cgi file from version 53 to version 52. Then I did a normal commit, and everything was great! Thanks goes to a guy on the #svn channel on irc.freenode.net, who showed me the command.

You know what the coolest thing about using Movable Type blogging software? Nearly the entire program (or rather, collection of scripts) is written in Perl! (There is also PHP and Javascript incorporated in.)

Actually, that's the second coolest thing. The coolest thing is that it's open source, so I can browse through the code. They also embedded POD documentation in a lot of the modules, although not quite as much as a novice like me would have appreciated. :)

I'm considering how I want to handle the security for admin side of the music database. All I've used in the past are those nifty .htaccess files. I wanted this time to make things a little easier for the end user. I was thinking to either a) make part of the admin interface able to write .htaccess files, or b) maintain a real session over CGI, with the session ID in the cookie, and the password hidden in some file.

I'd prefer to do that latter, so I'm trying to figure out what would be the easiest way to do that. I'm hoping to find a module or something that handles a lot of the details.

I did a fair amount of Perl coding today, but it wasn't actually for anything meant to run on the site. It is actually this very simple web interface I am designing to help my church view sermon audio files.

Basically, the interface simply allows the visitor to request a list of files in a directory, with some filtering  based on the labeling of the file. This really should be done with MySQL, so I'll probably work on implementing that after I get something up and running on their site -- right now I'm more concerned about getting together an administrative interface that they can use to upload the files.

I could probably get something up faster if I searched for currently available FOSS software to meet the need... But I'd really like another practical coding experience to help me improve my skills. Since this is all volunteer work, I don't think they would mind if it takes an extra week or two to get the archive up and running.

I put some (non-functional) starting code on my source page. If any Perl gurus would like a chance to beat up a novice over his bad coding habits, then take a look through the basicarchive package and the latest manynotes package. Drop any nasty comments you might have into the comments section of one of my blog posts.

I released the code for a version 0.4.0 and version 0.5.0 on the site. (Version 0.5.0 was a fix of some obvious problems I noticed when I put the software on my site). I installed the software on my site, and everything seems to be running okay.

Next step will be to add some kind of admin interface.

I just discovered the coolest thing about Perl since regular expressions: Perl POD. POD stands for Plain Old Documentation, and its a way to embed your documentation into your Perl scripts. What's really cool about it is that, once you've embedded the POD code, you can use an external program to instantly auto-generate text, HTML, or Latex documentation! (Those programs are pod2text, pod2html, and pod2latex, respectively.)

If you can spare five minutes, check out Plain Old Documentation in 5 Minutes.

So I spent a lot of time today getting rid of a lot of yucky, disorganized comments, in favor of embedded POD code.

I got quite a bit done today. In fact, I think I've finished the front-end interface. If I have time tommorrow, I'll go ahead and upload the front-end to indicium.us, and configure it for public use.  I'm going to release the source code too, though it will be version 0.5.0, since I haven't created any administrative interface.