bobpeers -> blog

I came across this article on Linux Journal today about using Python to run a very simple HTTP server from any directory. I tested in on a standard install on Windows and it works perfectly.

As one of the comments says there’s loads of great command line tips to be found at commandlinefu.com, including the one I mention here.

I’ve been trying to create a python script runs on shutdown or reboot. First I tried using the init system by placing the script into the /etc/init.d directory and then creating symlinks to the rc0 and rc6 directories so it runs shutdown and restart (all as root).

# cp myscript.py /etc/init.d
# ln -s /etc/init.d/myscript.py /etc/rc0.d/K10myscript.py
# ln -s /etc/init.d/myscript.py /etc/rc6.d/K10myscript.py

This doesn’t work, at least on Fedora, I think due to the fact that the init system checks for the presence of a file in /var/lock/subsys. Essentially the system checks whether a service is running (the lock file exists) before deciding to run the script.

In this case I would have to add my script as a service using chkconfig -add that starts on boot and creates the lock file. This is fine but what if I just want to run a simple script and not a service.

Next I looked at Upstart, the replacement for init scripts developed by Ubuntu but now the default in Fedora 9. This is compatible with the old init system but much more flexible. Following this great guide I tried to implement this using Upstart. Here’s my script saved in the /etc/event.d/ directory.

# Run my script on shutdown, reboot and runme events
start on runlevel 0     # Shutdown
start on runlevel 6     # Reboot
start on runme          # testing event
script
exec "/home/username/network_usage.py"
end script

I tested the script by emitting the runme event.

# /sbin/initctl emit runme
runme
network-usage (start) waiting
network-usage (start) starting
network-usage (start) pre-start
network-usage (start) spawned, process 3673
network-usage (start) post-start, (main) process 3673
network-usage (start) running, process 3673
network-usage (stop) running
network-usage (stop) stopping
network-usage (stop) killed
network-usage (stop) post-stop
network-usage (stop) waiting
initctl: runme event failed

Basically the script fails. I tried to run a bash script that calls the python script but that also fails. Upstart seems really easy to use and it’s much easier to test since you can create fictional events but I’m frustrated by my inability to run a simple python script.

I realise that I could write a bash script instead of a python script and it will probably work, or I could put my script in .bash_logout but that would run on user logout and not only on shutdown and reboot.

If anyone has a solution I’d be happy to hear.

I’ve been working on a few python files in WIndows and then moving them to Linux but whenever I try to run them I get an error about ‘directory not found’.

I soon discovered that the Windows carriage return messes up the files for Linux so we need to remove them all. If you open the offending file using vi you’ll see lots of ^M characters spread through the file. Fortunately these are pretty easy to remove using vi. Open the file in vi, press escape so we can enter a command, type this command press enter and save the file.

%s/^M/ /g

It’s very important that you create the ^M character by typing alt+v then press m while still holding down alt+v, do not paste straight from this page.

While playing around with my wireless connection it occurred to me that there’s no way to see which channels are the busiest in my area. I know the command shown below lists all the scan details including the channel number for each router, but to see the most heavily congested channels I have to search the list manually.

$ /sbin/iwlist eth1 scan

It occurred to me that a simple python script could do the job, so here it is.

#! /usr/bin/python
# set to the number of channels available
MAX_CHANNEL=14
# enter your wireless device name
DEVICE="eth1"
import os
f=os.popen("/sbin/iwlist " + DEVICE + " scan")
str=f.read()
channel=range(1,MAX_CHANNEL+1,1)
for i in channel:
 if i<10:
  ch="0" + `i`
 else:
  ch=`i`
 sChannel="(Channel " + `i` + ")"
 print "Channel " + ch + ":" + `str.count(sChannel)`
f.close()

It simply runs the Linux command using popen, parses the output and counts the channels producing an output like this.

Channel 01:3
Channel 02:2
Channel 03:2
Channel 04:0
Channel 05:0
Channel 06:2
Channel 07:1
Channel 08:0
Channel 09:1
Channel 10:0
Channel 11:0
Channel 12:0
Channel 13:4
Channel 14:0

As far as desktop systems go, for email, internet and basic office functionality, there’s no denying that Windows rules the roost. I would argue that Linux is actually not difficult to set up and use, it’s just different and probably has a perception problem, but therein lies the problem.

But from a developers point of view using Linux as the platform has many advantages over Windows. Try writing a simple “Hello world” program in C or C++ on a fresh Windows install an then compile and run it. You can’t.

Simply put, most Linux distributions come with compilers (gcc in this case) installed out of the box and many more are available with an ‘apt-get’ or ‘yum install’ command. You don’t even have to do this from the command line these days as most distributions have friendly graphical install programs that put anything Windows has to shame.

Want Python or Perl, Apache or MySQL again it’s a few clicks away along with hundreds (thousands?) of other tools. Plus once they’re installed the OS takes care of notifying you (and optionally installing) any updates so you’ll never be left with 3 year old, unpatched software on your computer.

The last time I checked my Windows install I had many applications that were way out of date but the effort required to check up and manually update each one individually was just too much effort.

On a related note I have been using Eclipse as my IDE of choice, mainly because of it’s support of both Python and C++ using the Pydev and CDT modules. So I thought I’d give it a try on Windows.

After downloading and installing Python then installing the Pydev module, getting Python to work was not too difficult. Next came C++ support, it involves installing MinGW following the instructions on download page, then configuring Eclipse using these instructions.

If you’re very lucky it will all work first time, but don’t count on it. And god help you if you decide to update any packages at a later date.

Compared to all this the development tools on Linux are a breeze. Linux may or may not be ready for the desktop for the average user (if there is such a person) but when it comes to the power user or developer it’s already ahead in my books.

I was recently writing some code to be run from a command line that recursively walks through a network folder and all sub folders compiling a list of all the files, their last modified date and their size.

Since writing VBScript is quick and dirty I tend to start with that and in most cases it works just fine. However when speed really matter it’s just not up to the job.

The network directory contains about 35,000 files in 3,200 folders consuming 45.4GB of disk space. The script should simply gather the data required and write it to a flat text file (delimited with semi-colons). When I ran the VBScript it took 306 seconds (5 minutes and 6 seconds) to gather the data.

Not too bad but not fast enough. So I decided to write the same script both in Python and C++. Python is a very high level scripting language, so nowhere near as fast as a complied language like C++, but I wanted to see how it compared to VBScript. Here’s the results for the 3 programs.

Of course, as expected, for real performance C++ outstrips the scripting languages by a mile but Python also fairs pretty well.

When I also consider how simple the code is and how long it took to develop I think Python is the clear winner unless every ounce of performance is vital. Developing real world programs in Python is extremely easy and the code is fast.

I use another short script in Python to parse Apache log files and it amazes me how fast it runs. The current log is over 122,000 lines (27.1MB of data) long but the script parses the file and outputs the results to a text file in just over a second! Very impressive for an interpreted language.