Development
Notes and stuff related to software development.
Tuesday, August 27, 2019 10:25 PM
Recently I had to work with some Python code which needs to be compatible with both the hopefully-soon-to-be-finally-deprecated Python 2.7 and recent 3.x versions.
String handling can be a tricky issue, particularly if the string in question needs to be cast to a Unicode object. Take the following example:
#!/usr/bin/env python
import ipaddress
addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));
for address in addresses:
print(address)
This does of course fail in Python 3.x with an error like:
Traceback (most recent call last):
File "./python.py", line 5, in
addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));
NameError: name 'unicode' is not defined
Remove the unicode()
wrapper and it fails in Python 2.x with:
ipaddress.AddressValueError: '192.168.1.0/24' does not appear to be an IPv4 or IPv6 network. Did you pass in a bytes (str in Python 2) instead of a unicode object?
The solution is to use the "six
" compatibility layer and add the following directive, which reassigns unicode()
to a mutually compatible function:
#!/usr/bin/env python
import ipaddress
from six import u as unicode
addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));
for address in addresses:
print(address)
Note that the "six
" compatibility layer may need to be installed separately, in RedHat et al via the packages python2x-six
and python3x-six
respectively.
Useful links
Monday, November 17, 2014 5:08 AM
I was setting up a cronjob and it kept failing with the very unhelpful util.c: No such file or directory. After much headscratching it turns out this is a gnuplot error message, meaning it is unable to read from or write to a file (in this case the latter). The file in question is not of course util.c.
Saturday, September 27, 2014 1:42 AM
I was bemused by the below error when attempting to run an Ansible playbook on a new (Linux) server for the first time:
PLAY [someserver] *****************************************************************
GATHERING FACTS ***************************************************************
failed: [someserver] => {"failed": true, "parsed": false}
SUDO-SUCCESS-fdhntaxupgygzrcocwghbosdkgbgguvy
/bin/sh: 1: powershell: not found
This happened with gather_facts set to true. Setting it to false worked around the issue, however I'm pretty sure powershell hasn't been ported to Debian... Ansible version:
$ ansible-playbook --version
ansible-playbook 1.8 (devel ffee9a8fe0) last updated 2014/09/27 14:24:58 (GMT +900)
The actual cause was the absence of python on the target server; this will need to be manually installed before Ansible can be of much use.
Friday, March 30, 2012 12:57 AM
After upgrading my development environment to openSuSE 12.1, I started getting a bunch of notices like the below after every Subversion operation which uses SSH:
...
A /tmp/svn25825/public/favicon.ico
Exported revision 16786.
Killed by signal 15.
The issue is discussed here; in a nutshell, the solution is to add "-q" to the ssh command invoked by SVN, which is defined in the configuration file (typically ~/.subversion/config). In my case, the line in question now looks like this:
ssh = $SVN_SSH ssh -q -o ControlMaster=no
Note: ensure this line is in the [tunnels]
section of the config file.
Monday, September 21, 2009 1:25 AM
Having moved a bit recently and being busy at the same time, I still haven't got round to setting up my home network quite the way I'd like it. With the result that a while back I checked out some code from a Subversion repository to a laptop, and when I came to check it back in the LAN IP of the box with the repository on it had changed. Of course the working copy was still pointing to the old IP, making it impossible to commit my code changed, and the cheap consumer-grade router which looks after the network doesn't seem capable of assigning IP addresses based on MAC address. How to get the working copy pointed at the changed IP address?
Castig about in the .svn
directories in the working copy, each contains a text file named "entries
" which in turn contains two lines which look like this:
svn+ssh://192.168.0.5/path/to/svn/project/trunk
svn+ssh://192.168.0.5/path/to/svn
Manually updating the IP address seemed to work for that directory, so a simple
sed -i 's/svn+ssh:\/\/192\.168\.0\.5\//svn+ssh:\/\/svn.local\//'
took care of the entire working copy. Rather than just update the IP address I created an entry in /etc/hosts
for svn.local
, so should the repository IP address change again before I get things sorted, all I need to do is update the IP address here rather than mess about with SVN internals.
(Another workaround would be to make a tarball of the working copy without the .svn directories, delete the working copy, check it out again and untar the code over the new working copy.)
Thursday, September 17, 2009 4:32 AM
A quick shell script to make an atomic copy of a Subversion repository using svn hotcopy
:
#!/bin/bash
SVNDIR=/home/svn/
BACKUPDIR=/tmp/svn.`date +%Y-%m-%d`/
BACKUPFILE=/tmp/svn.`date +%Y-%m-%d`.tgz
mkdir $BACKUPDIR
svnadmin hotcopy $SVNDIR $BACKUPDIR
tar -C $BACKUPDIR -czf $BACKUPFILE .
scp $BACKUPFILE someuser@somewhere.example.com:svnbackup/ \
&& rm $BACKUPFILE && rm -rf $BACKUPDIR