crb3's cgi stuff

These are small scripts I've written to run on one or more of the Linux servers on our local network. Some of them depend explicitly on Apache. All of them are in Perl, but none depend on mod_perl. They're almost all CGI, which means that they run on an HTTP server, at localhost or anywhere on the planet, and the results show up in your browser.

ascalpost

ascalpost presents a CGI calendar page consisting of a month-plus of planetary events, including most Void-Of-Course moons, assuming you have Walter Pullen's astrolog installed on your Unix-type computer as well as Apache. It uses astrolog as a back-end to generate all the angles, then massages the data into shape for calendar presentation. Now it even includes graphic eyecatches for the lunar quarters, as well as a first stab at a "powered by Astrolog" badge (credit where credit is due).

dirls

This is a convenience script, designed to be used as a server-side include (which means that your Apache configuration has to have "Includes ExecCGI", not "IncludesNoExec", in the settings for the directory where you want it to run). Called by an #exec-cgi statement as the heart of an index.shtml, it lists all the HTML files found in that directory. It also opens each one and reads in the title, so those are part of the lines of display.

In action, this is most useful when you are in the process of producing HTML pages (stories, travelogues, technical writing... prose). You can whip up a standard index page for the directory where they will go as you complete them, and then they will automatically be listed when you next browse that directory. It's even more useful if that directory is cluttered with a bunch of working files other than *.html, because those will be ignored. The one script is an indexer for however many such SSI index pages you put on your system. If you have writers on your system, all wanting to proofread with fresh eyes by viewing their work in a browser, this is for you.

gunz

gunz goes into a far corner of the cgi topic, because it takes over the server's response for a whole filetype: 'gz'.

In pursuing my various interests, I've downloaded a lot of html files; they end up on LAN-local servers where anybody on my network can read them. In pursuing sanity in storage, I want to gzip them (a 50% savings in space, typically, for HTML)... but then nobody can browse them across the network, because Apache 1.x has a problem with gzipped html. A mimetype can't have a dot, so Apache can't hand off processing of, say, html.gz, to a script or program. The workaround in the O'Reilly Apache book is to change everything to use a new filetype like htmlgz, and delegate handling of that, but that means renaming all those files, and remembering to rename the new ones as they come in...

Never mind all that. With this line in httpd.conf:

  Action application/x-gzip /cgi-bin/gunz.cgi

It all happens as you would expect, unless the specified file can't be found, in which case the only way I was able to get Apache to declare a 404 was to redirect to the following nonexistent file: /RepointToNonexistentPage-TriggersA404.html. (If that name isn't explicit enough to keep helpful admins from fixing it, I don't know what is.) Users with browsers will see that name in the text of the default 404 page, but they'll see the original filename they were trying to fetch in the address bar, at least with the Mozilla-type browsers I used to test it. More important to my purposes, wget gets its 404.

A Perl script like gunz.cgi isn't the most efficient way for a production server to manage things, but then, it's not intended for that environment. It's intended for a lightly-loaded intranet situation, such as a home network or a department LAN, where filespace matters.

next

The givens: a directory of pictures on a server. The directory's contents in my case are dynamic: fetched periodically during the day from servers on the Internet by one cron job, and tarballed nightly for archiving by another cron job.

The problem: viewing the contents of a naked directory gets old fast. It's slow, because it requires two page-loads per view and periodic reloads of the directory to catch updates. There should be a convenient way to manually step through the current images from first to last, and bookmark them if possible.

The solution: next.cgi and next.html. The starter page next.html is copied into place in any directory where such browsing is wanted; if you don't want to see the naked directory there, rename the copy index.html. It does an immediate javascript redirect to /cgi-bin/next.cgi, which runs the show from then on. The script knows from the environment provided by Apache just what directory is being browsed, and what image has just been viewed, if any, and furnishes dynamic HTML pages such that you just have to keep clicking the "next" link in order to see every picture in sorted order. The cgi method is GET, so you have visible args you can save to bookmark.

The script will display one type of picture (jpg, gif, png). It has picture-type selection logic to choose the type that has the most pictures in that directory. This is so that, if the directory contains a few downloaded page-layout graphics (say, gifs), they won't show up in the stream of interesting pictures (say, jpgs) to be stepped through on every once-through viewing.

showmepostenv

Pieces of showmepostenv.cgi came from various other peoples' work, and I cobbled it all together into the kind of tool I use a lot when I'm debugging CGI. Here it is, in case you don't have one. It shows just what information is being presented to it by the HTTP server. In use, I swap it into place instead of the script I'm debugging, long enough to see if the GET and POST and ENV args are what I think they are. Note: This is not the kind of tool you leave lying around on a public server: it may hand out environment information you really should be keeping to yourself. Disable it by chmod -x, or renaming it to something the server doesn't think is a CGI file, when you're not using it. It's better suited to debugging on a local trusted network.

wikipage_injector

Maybe this program should have been put in the cli area, because it's not a CGI program itself, instead it talks to a CGI program, a UseMod Wiki. It's in here, though, trading on topicality. wikipage_injector does what it sounds like: injects a prepared text file into a wiki across the network. Unlike most of my Perl programs, which tend to steer clear of CPAN modules because of their heft, this one uses LWP and GetOpt modules to do the job. It's best used in batch mode when you're bringing up a new wiki and priming it with topic materials, or transferring the contents of one wiki to another.