Scripts

Since some of my scripts should be used system wide (i.e. multiple users, the system itself, etc.), I'll be writing a script that will move all of the pertinent scripts to their system directories if they've been changed. This way, other users wont need access to my home directory to run certain scripts, like the wireless connection tool.

Slackware 13.1

Installed Slackware on my server today. Still working on configuring. Wrote a script to step through and vim every file within a given directory, which I'll be posting soon. Then it's on to learning the package build and installation process.

[update]gmail python script

The problem reminded me of my python script, which retrieves to number of unread e-mails in my mailbox. They also had some syntax errors. So, in ~/.conkyrc I changed the 'exec python gmailscript' to 'exec python2 gmailscript' and it worked out just fine.

[bug]chocolate-doom package build

A bug in the build for the chocolate-doom AUR package was brought to my attention recently:

1. ./docgen -m manpage.template ../src > chocolate-doom.6
2.   File "./docgen", line 392
3.     print line.rstrip()
4.              ^
5. SyntaxError: invalid syntax
6. make[2]: *** [chocolate-doom.6] Error 1
7. make[2]: Leaving directory `/home/arin/Downloads/chocolate-doom/src/chocolate-doom-1.4.0/man'
8. make[1]: *** [all-recursive] Error 1
9. make[1]: Leaving directory `/home/arin/Downloads/chocolate-doom/src/chocolate-doom-1.4.0'
10. make: *** [all] Error 2

Archlinux recently swiched from Python2 to Python3 as the default python. It uses symlinks to point /usr/bin/python to the actual Pythonx package. While Python2 is still installed, the /usr/bin/python symlink now points to Python3. The docgen script was using the default python (now Python3). The opening line for the script read: '#! /usr/bin/env python'. So, I will look into this, but the syntax used, which threw the error, was probably deprecated (or there's a bug). The salution thus being to edit the file to use Python2. Thus, the line "sed 's/python/python2/' -i man/docgen" was added to the PKGBUILD. The Python2 package also had to be added to the list of dependencies.

recurperms

I wrote a script to remove the executable flags from all files within a directory but directories themsevles. It will also descend into sub-directories.

#!/bin/bash

# This script will chmod -x every file within a
# directory recursively, without removing the
# executable nature of the directories contained
# within.
################################################

do_recursion() {
    files=`ls`
    file=
    for i in $files; do
        file=$file$i
        if [[ ! -e $file ]]; then
            file=$file' '
            continue
        fi
        if [[ -d "$(pwd)/$file" ]]; then
            echo "descending into directory $(pwd)/$file"
            cd "$(pwd)/$file"
            do_recursion
        fi
        if [[ -d "$(pwd)/$file" ]]; then
            echo "ascending to directory $(pwd)/$file"
        else
            echo "chmodding $(pwd)/$file"
            chmod -x $file
        fi
        file=
    done
    cd ..
    return
}

do_recursion

exit 0

pacdown

Since I'm going to be running testing full-on, I'm going to need a script that can downgrade recently upgraded packages. I'll want to be able to pass the script a single package name that it can then downgrade, or tell it to downgrade all packages recently upgraded from testing. This may also lead to my package management script that will look at a blacklist file of packages that had to be downgraded, so that they won't be re-upgraded unless removed from the blacklist.

Testing Packages

Suprisingly, I haven't run into any conflicts until now. I guess some packages in testing require other packages in testing to be installed. Therefore, when using the testing repos, it is necessary to update the machine soley from the testing repo, rather than pick and choose packages to be tested. I will thus be scrapping the pactesting script and installing all packages from testing. I e-mailed the mailing list and it was advised that I do the aforementioned and simply use a script to revert to the stable package incase a testing package does not work propperly.

[bug]pactesting

When passing an option to pacman, i.e. pactesting -w package, pactesting will treat the option as a package while validating. While the script still works as it should, options and all, it's not correct. An update is in the works.