WeBWorK Resources

WeBWorK Scripts

Here are a variety of scripts I use in administering our system.

• clean-tmp: this is for deleting images, and any other temporary files, created by WeBWorK. It needs to know a top directory to start looking in, and a "delay time" in seconds. It then recursively searches down from the top directory looking for paths .../html/tmp. Each file below that combination is checked for the last time it was accessed. If the time is more than the preset "delay time", the file is deleted. The delay time and top directory can be set near the top of the file. I run this as a daily cron job. Under slackware, this requires putting the file in /etc/cron.daily.

• log-loads: this logs the system load to a file. The path to the file is set inside the script. We run this as an hourly cron job. It makes it easier to monitor the system, and to answer questions like "was webwork slow or down at 3am last night?". Under slackware, I put it in /etc/cron.hourly.

• parse-load: this is a companion to log-loads. Run it with one argument, namely the path to the log file, and it prints only the lines with "high" loads (greater than 2.1 for us).

• buildProbSet: build a problem set from the command line. This is a slightly modified version of Bill Ziemer's script. You can give it two arguments, the course and the name of the set definition file, or just the set definition file. In the latter case it will try to deduce the right course based on the current directory. This works best from a templates directory. Then the script can guess the course and you can use tab-completion to get the spelling right of the set definition file. The location of cgi/cgi-scripts needs to be set at the top to match your system.

• dandrprobset: analogous to the previous script, but it does a destroy and rebuild. It ignores course settings which don't "allow" destroy-and-rebuild. The location of cgi/cgi-scripts needs to be set at the top to match your system.

• ins-string: this takes the name of a set definition file and a string as input. It then inserts the string at the beginning of the path for each problem file. Useful when moving from problem files which are "local" to a course, to ones which are in a common library.

• cnt: there must be a basic utility for this, but I couldn't find it. It outputs positive integers, in order, with one per line. In other words, it counts. cnt 5 counts from 1 to 5. With two arguments, such as cnt 3 7, it counts from 3 to 7. I use it in shell loops. For example, to make 100 copies of a skeleton problem file for someone called p1.pg, p2.pg, etc., I use

    for j in `cnt 100` ; do cp skeleton.pg p${j}.pg ; done
  

  Then, I make a set definition file, build the set, and the person has a big work area for writing problems.

• getfilename: if someone says they like problem 37 of setManyProblems.def and you want to know the path to that file, you can get it with getfilename setManyProblems.def 37. In giving the name of the problem set, the initial "set" and the ending ".def" are optional.

• showActive: adaptation of a standard WeBWorK script to show currently logged in users to run on the command line. The first argument is the name of the course. The second argument, if present, signals that it should only report the number of active users. The path to WeBWorK has to be set near the top of the script.

• allShowActive: wrapper for calling the previous scripts on lots of courses. The course names are given on the command line. The output is the name of each course with the number of current users. As a bonus, it adds these numbers up for you. If all of your current courses are in the current directory, use allShowActive * to get an overview of system activity.

• checktrees: do you have two copies of the same sets of problem files. Are you sure they are the same? Now you can check with checktrees path/to/first path/to/second. It will ignore set definition files, emacs backup files, and backup files of problems created by WeBWorK. It reports when files in the two trees differ, telling you which one is the newer one.

WeBWorK Library and Browser

This has been superceeded by the problem browser built into WeBWorK 2, and the problem library above.

Local Documentation

Anyone is welcome to read our local documentation for WeBWorK. Keep in mind that it is tuned to local needs in a few ways. It assumes one has local customizations discussed below, and it focuses on the things of particular interest to our effort.

More Answer Evaluators

This has been removed because it is part of the most recent release of WeBWorK.

The work represented here was produced with partial support from a grant by the National Science Foundation (DUE-0125369).