Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

I had a repeat of a problem that I’ve probably had many times over the years. I wanted to write down the solution before I forgot it, because it had been long enough since the last time that I’d forgotten the fix.

Let’s set the stage: I wanted to SSH into a remote system. In my case, that remote system was a Mac OS Snow Leopard system. The client was also Mac OS X.

On that remote system, I had enabled sshd. This is done on Snow Leopard with System Preferences > Sharing > Remote Login. (In the Sharing System Preferences, you set up the users that are allowed to remote log in, either allowing all users or setting up an ACL that only allows specific users. If you set up the ACL, it should supercede whatever additional user/group login restrictions you’ve configured in /private/etc/sshd_config.)

Then, I tried to SSH from my client system. Instead of a successful login, I was told the following — before I was prompted for a password.

Scratching your head, you add verbosity to the SSH connection attempt.

I searched for other people having the same problem with “debug1: SSH2_MSG_KEXINIT sent,” because other people always have the same problem and some of them wrote about it and some of those solved it. Right?

Well, in this case, the other solutions I found were not helpful to my specific situation. But many people responding to pleas for help did mention the always-good advice to “check the server logs.” Which I could do, so I did.

In the secure.log, I found several groups of lines like this corresponding to the times I had tried to log in:

That reminded me of the common problem with SSH host keys on Radmind-managed computers. See, Mac OS X will try to create the host keys if they are missing, but not if they are zero-length. On Radmind-managed computers, it was trivially easy to get zero-length SSH host key files in /private/etc because the tendency was to manage them with negative transcripts. Files listed in negative transcripts would be created if they were missing, but they would be created as empty files (by design).

Empty SSH host key files will prevent you from logging into that system with SSH.

I checked the server and — sure enough — the host key files were zero length. I deleted them, then stopped and restarted Remote Login for good measure. This solved the problem, and I could log in from the client.

I was trying to install Dulwich on a Mac OS X Lion system this week and ran into difficulty. I kept getting installation failures that included a missing “python.h” and, eventually, llvm-gcc-4.2 failed to compile the module.

I found the situation frustrating, partly because I pretty much own the top search hits about how to install Dulwich and Hg-Git on Mac OS X Lion, thanks to some earlier article.

It turns out that I had reinstalled Lion about two weeks ago, and had not reinstalled Xcode 4. So, I updated to Xcode 4.2 and this completely eliminated my problem. Presumably, it would also work for you — and for future me, since I’m likely to repeat this — even if Lion hadn’t been reinstalled in between.

Things that didn’t work included but were not limited to:

• cursing under my breath
• stomping
• hand-waving
• complaining on Twitter
• the silent treatment
• waiting for 4, 12, and then 24 hours to see if it would fix itself
• installing the latest version of setuptools, v0.6c11, from an egg
• installing the current version of Distribute, new hotness or not
• any steps involving Linux distribution package managers like apt-get.

I had a need to read some settings from a Python script on Mac OS X recently. I wanted to be able to change selected parameters for the script — some of which could be site or implementation specific — without embedding them directly in the code. Since the script was Mac OS X-only, using a property list seemed like a good idea.

With customizable settings from a property list, a script could become useful and more customizable for a wider community — or even different internal audiences.

I thought reading preferences was going to take a lot of effort. I was, however, pleasantly surprised at how easily I was able to accomplish it.

Asking others who had been down this route before resulted in some links to Apple docs. I wanted a more concrete example of how it was done in Python, and I got a great one.

That example came from reading the source to munkilib from the open source project, Munki. Since Munki had its own preference file, it needed to read from it, and its example was very enlightening.

Frogor directed me to a specific spot in the Munki code. That spot demonstrated how to read a preferences file with CoreFoundation.

Munki also has its own internal defaults for preferences. The munkilib/munkicommon.py example showed how to implement default settings in their absence in a property list. That provides a fallback position so that you always have some value available. In Munki, setting the defaults was done within a function. It seemed that it would be more generic if those defaults were separated out of the preference-reading function.

My own example of how to read a plist is outlined below. This focuses on just what you need in order to read the preferences and provide default settings for a larger script. A single set of preferences can be shared between scripts, and each script can encode its set own defaults. While you can create your own keys and values, for the example below, I will use the keys “StringPreference,” “BooleanPreference,” “ArrayPreference,” and “DictionaryPreference.”

1. Create a new property list. There are several ways to do this, including the property list editor that has been rolled into Xcode (and is no longer a standalone application) in v4.
2. Save the file. The name will be used later.
3. Set up the basic shell of the script that will read the plist and import CoreFoundation.
   
   #!/usr/bin/env python
   
   from Foundation import CFPreferencesCopyAppValue
4. Add in a variable for the script’s bundle ID. The bundle ID uniquely identifies your script’s preferences. It is written in reverse DNS notation, which should be familiar to almost anyone who has dealt with property lists before. It’s handy to have this defined globally for your script so that you can refer back to it as needed.
   
   #!/usr/bin/env python
   
   from Foundation import CFPreferencesCopyAppValue
   
   this_bundle_id = ‘com.example.your-script-here’
5. Create a function to read a preference by its bundle ID. The business end of the function is the use of CFPreferencesCopyAppValue get a value for a key.
   
   #!/usr/bin/env python
   
   from Foundation import CFPreferencesCopyAppValue
   
   this_bundle_id = ‘com.example.your-script-here’
   
   def get_preference(preference_key, bundle_id=this_bundle_id):
       """
       Get the preference value for a given combination of preference
       key and bundle ID. Returns the requested preference value.
       """
       # Get the specified preference key from the specified preference
       # bundle ID using CoreFoundation
       preference_value = CFPreferencesCopyAppValue(preference_key, bundle_id)
       return preference_value
6. Tie the get_preferences function together with a default_preferences object. This way, any missing preferences will fall back to the defaults encoded in your script. Any preferences that are set in a property list will override the defaults.
   
   #!/usr/bin/env python
   
   from Foundation import CFPreferencesCopyAppValue
   
   this_bundle_id = ‘com.example.your-script-here’
   default_preferences = {
       ‘StringPreference’: False,
       ‘BooleanPreference’: False,
       ‘ArrayPreference’: list(),
       ‘DictionaryPreference’: dict(),
   }
   
   def get_preference(preference_key, bundle_id=this_bundle_id):
       """
       Get the preference value for a given combination of preference
       key and bundle ID. Returns the preference value.
       """
       # Get the specified preference key from the specified preference
       # bundle ID using CoreFoundation
       preference_value = CFPreferencesCopyAppValue(preference_key, bundle_id)
       # If the value is not set in the property list, get a default value
       # from the default_preferences objects
       if preference_value == None:
           preference_value = default_preferences.get(preference_key)
       return preference_value

The script won’t do anything yet, until we create a main() or other functions to call the get_preferences function. Since you’d be reading preferences as part of a larger script, this is fine for now. However, with what’s written already, you can test out reading preferences interactively with the shell and Python interpreter.

1. Start by checking the property list in the shell. In my case, I created an example property list that sets two of the four preferences.
   
   $ defaults read com.example.your-script-here
   {
       BooleanPreference = True;
       StringPreference = abc;
   }
2. Open Terminal, run “python” at the command prompt, and paste the script code above at the interactive Python “>>>” prompt.
3. Run the get_preferences function and print its output.
   
   >>> print(get_preference(‘StringPreference’))
   abc
   >>> print(get_preference(‘BooleanPreference’))
   True
   >>> print(get_preference(‘ArrayPreference’))
   []
   >>> print(get_preference(‘DictionaryPreference’))
   {}

That’s it, the expected results were returned. Notice that the output for StringPreference and BooleanPreference are taken from the property list, while the empty array and dictionary come from the default_preferences in the script.

Update: Greg pointed out that there is a certain degree of danger using #!/usr/bin/env python as the shebang line in the script. Should a system have a non-Apple installation of Python, then /usr/bin/env python might return that. Another Python is probably less likely to be able to bridge CoreFoundation, and thus wouldn’t be able to use the CFPreferencesCopyAppValue call to read preferences.

I think the overall shebang danger is small because few Mac OS X systems will have an alternative Python installed, but clearly your chances of that increase in certain situations. To eliminate this risk, do what Munki does and insert the #!/usr/bin/python shebang instead.

In previous articles, I described how to Install Mercurial 1.9, Dulwich, and Hg-Git on Mac OS X Snow Leopard and Install Mercurial 1.9, Dulwich, and Hg-Git on Mac OS X Lion. For either of those operating systems, we can further extend Mercurial with support for connecting to Subversion repositories. While we could enable the bundled Convert extension, the Hgsubversion extension adds live access to remote networked Subversion repos, so it sounds more interesting.

My personal goal in doing this is to be able to work with the InstaDMG repository. It is hosted on Google Code, uses a Subversion repo, and depends upon Subversion keyword substitution. It presents an interesting challenge.

So, let’s install Hgsubversion to add Subversion support to the Git support we’ve previously set up. We need to take the following additional steps, going beyond what is done in the previous articles. To continue, you must already have installed:

1. the Xcode tools (including Subversion), as appropriate for your operating system (probably either Xcode 3.2.6 or 4.1 at this point)
2. Mercurial 1.9.2 or later.

Hgsubversion also needs Subversion to be installed. The Mercurial extension then has two different ways of working with Subversion. The Hgsubversion docs I read indicated that Subvertpy is preferred over the other method — using Subversion’s SWIG bindings — so we’ll install this additional Python module first. The docs also recommend running tests on Hgsubversion before using it on projects, so we will try that, as well.

Start with installing Subvertpy:

1. Run the easy_install command in Terminal.
   
   $ sudo easy_install ‘subvertpy>=0.8.7’
   Searching for subvertpy>=0.8.7
   Reading <a href="http://pypi.python.org/simple/subvertpy/
   Reading" title="http://pypi.python.org/simple/subvertpy/
   Reading">http://pypi.python.org/simple/subvertpy/
   Reading</a> <a href="http://samba.org/~jelmer/subvertpy
   Reading" title="http://samba.org/~jelmer/subvertpy
   Reading">http://samba.org/~jelmer/subvertpy
   Reading</a> <a href="http://launchpad.net/subvertpy
   Best" title="http://launchpad.net/subvertpy
   Best">http://launchpad.net/subvertpy
   Best</a> match: subvertpy 0.8.7
   Downloading <a href="http://samba.org/~jelmer/subvertpy/subvertpy-0.8.7.tar.gz
   Processing" title="http://samba.org/~jelmer/subvertpy/subvertpy-0.8.7.tar.gz
   Processing">http://samba.org/~jelmer/subvertpy/subvertpy-0.8.7.tar.gz
   Processing</a> subvertpy-0.8.7.tar.gz
   Running subvertpy-0.8.7/setup.py -q bdist_egg —dist-dir /tmp/easy_install-hU1kY_/subvertpy-0.8.7/egg-dist-tmp-Qgbloj
   subvertpy/editor.c: In function ‘txdelta_call’:
   subvertpy/editor.c:133: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/util.c: In function ‘string_list_to_apr_array’:
   subvertpy/util.c:235: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/util.c: In function ‘path_list_to_apr_array’:
   subvertpy/util.c:258: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/util.c: In function ‘revnum_list_to_apr_array’:
   subvertpy/util.c:497: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/_ra.c: In function ‘auth_init’:
   subvertpy/_ra.c:2180: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/_ra.c: In function ‘auth_set_parameter’:
   subvertpy/_ra.c:2215: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/_ra.c: In function ‘py_ssl_server_trust_prompt’:
   subvertpy/_ra.c:2681: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/wc.c: In function ‘adm_process_committed’:
   subvertpy/wc.c:1205: warning: ‘svn_wc_process_committed4’ is deprecated (declared at /usr/include/subversion-1/svn_wc.h:3765)
   subvertpy/wc.c: In function ‘get_pristine_copy_path’:
   subvertpy/wc.c:2451: warning: ‘svn_wc_get_pristine_copy_path’ is deprecated (declared at /usr/include/subversion-1/svn_wc.h:4994)
   subvertpy/wc.c: In function ‘py_dict_to_wcprop_changes’:
   subvertpy/wc.c:1127: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/wc.c: In function ‘adm_process_committed’:
   subvertpy/wc.c:1205: warning: ‘svn_wc_process_committed4’ is deprecated (declared at /usr/include/subversion-1/svn_wc.h:3765)
   subvertpy/wc.c: In function ‘get_pristine_copy_path’:
   subvertpy/wc.c:2451: warning: ‘svn_wc_get_pristine_copy_path’ is deprecated (declared at /usr/include/subversion-1/svn_wc.h:4994)
   subvertpy/_ra.c: In function ‘auth_init’:
   subvertpy/_ra.c:2180: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/_ra.c: In function ‘auth_set_parameter’:
   subvertpy/_ra.c:2215: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/_ra.c: In function ‘py_ssl_server_trust_prompt’:
   subvertpy/_ra.c:2681: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/util.c: In function ‘string_list_to_apr_array’:
   subvertpy/util.c:235: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/util.c: In function ‘path_list_to_apr_array’:
   subvertpy/util.c:258: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/util.c: In function ‘revnum_list_to_apr_array’:
   subvertpy/util.c:497: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/editor.c: In function ‘txdelta_call’:
   subvertpy/editor.c:133: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/repos.c: In function ‘fs_root_file_length’:
   subvertpy/repos.c:747: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/util.c: In function ‘string_list_to_apr_array’:
   subvertpy/util.c:235: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/util.c: In function ‘path_list_to_apr_array’:
   subvertpy/util.c:258: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/util.c: In function ‘revnum_list_to_apr_array’:
   subvertpy/util.c:497: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/wc.c: In function ‘adm_process_committed’:
   subvertpy/wc.c:1205: warning: ‘svn_wc_process_committed4’ is deprecated (declared at /usr/include/subversion-1/svn_wc.h:3765)
   subvertpy/wc.c: In function ‘get_pristine_copy_path’:
   subvertpy/wc.c:2451: warning: ‘svn_wc_get_pristine_copy_path’ is deprecated (declared at /usr/include/subversion-1/svn_wc.h:4994)
   subvertpy/wc.c: In function ‘py_dict_to_wcprop_changes’:
   subvertpy/wc.c:1127: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/wc.c: In function ‘adm_process_committed’:
   subvertpy/wc.c:1205: warning: ‘svn_wc_process_committed4’ is deprecated (declared at /usr/include/subversion-1/svn_wc.h:3765)
   subvertpy/wc.c: In function ‘get_pristine_copy_path’:
   subvertpy/wc.c:2451: warning: ‘svn_wc_get_pristine_copy_path’ is deprecated (declared at /usr/include/subversion-1/svn_wc.h:4994)
   subvertpy/util.c: In function ‘string_list_to_apr_array’:
   subvertpy/util.c:235: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/util.c: In function ‘path_list_to_apr_array’:
   subvertpy/util.c:258: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/util.c: In function ‘revnum_list_to_apr_array’:
   subvertpy/util.c:497: warning: implicit conversion shortens 64-bit value into a 32-bit value
   subvertpy/editor.c: In function ‘txdelta_call’:
   subvertpy/editor.c:133: warning: implicit conversion shortens 64-bit value into a 32-bit value
   zip_safe flag not set; analyzing archive contents…
   subvertpy.__init__: module references __file__
   subvertpy.ra_svn: module references __file__
   Adding subvertpy 0.8.7 to easy-install.pth file
   Installing subvertpy-fast-export script to /usr/local/bin
   
   Installed /Library/Python/2.7/site-packages/subvertpy-0.8.7-py2.7-macosx-10.7-intel.egg
   Processing dependencies for subvertpy>=0.8.7
   Finished processing dependencies for subvertpy>=0.8.7
2. Clone the Hgsubversion repository from Bitbucket to a temporary location on your system. Under normal circumstances, I would use easy_install again to get hgsubversion. However, version 1.2.1 in PyPi didn’t work for me. So, to get a more current working version, I went to the source repository to get the latest software.
   
   $ cd /tmp
   $ hg clone <a href="https://bitbucket.org/durin42/hgsubversion" title="https://bitbucket.org/durin42/hgsubversion">https://bitbucket.org/durin42/hgsubversion</a> hgsubversion-work
3. Run the setup tool from the repository.
   
   $ sudo python setup.py install
   running install
   running bdist_egg
   running egg_info
   creating hgsubversion.egg-info
   writing hgsubversion.egg-info/PKG-INFO
   writing top-level names to hgsubversion.egg-info/top_level.txt
   writing dependency_links to hgsubversion.egg-info/dependency_links.txt
   writing manifest file ‘hgsubversion.egg-info/SOURCES.txt’
   reading manifest file ‘hgsubversion.egg-info/SOURCES.txt’
   reading manifest template ‘MANIFEST.in’
   warning: no files found matching ’*.rst’
   writing manifest file ‘hgsubversion.egg-info/SOURCES.txt’
   installing library code to build/bdist.macosx-10.7-intel/egg
   running install_lib
   running build_py
   creating build
   creating build/lib
   creating build/lib/hgsubversion
   copying hgsubversion/__init__.py -> build/lib/hgsubversion
   copying hgsubversion/__version__.py -> build/lib/hgsubversion
   copying hgsubversion/editor.py -> build/lib/hgsubversion
   copying hgsubversion/maps.py -> build/lib/hgsubversion
   copying hgsubversion/pushmod.py -> build/lib/hgsubversion
   copying hgsubversion/replay.py -> build/lib/hgsubversion
   copying hgsubversion/stupid.py -> build/lib/hgsubversion
   copying hgsubversion/svncommands.py -> build/lib/hgsubversion
   copying hgsubversion/svnexternals.py -> build/lib/hgsubversion
   copying hgsubversion/svnmeta.py -> build/lib/hgsubversion
   copying hgsubversion/svnrepo.py -> build/lib/hgsubversion
   copying hgsubversion/util.py -> build/lib/hgsubversion
   copying hgsubversion/wrappers.py -> build/lib/hgsubversion
   creating build/lib/hgsubversion/svnwrap
   copying hgsubversion/svnwrap/__init__.py -> build/lib/hgsubversion/svnwrap
   copying hgsubversion/svnwrap/common.py -> build/lib/hgsubversion/svnwrap
   copying hgsubversion/svnwrap/subvertpy_wrapper.py -> build/lib/hgsubversion/svnwrap
   copying hgsubversion/svnwrap/svn_swig_wrapper.py -> build/lib/hgsubversion/svnwrap
   creating build/lib/hgsubversion/help
   copying hgsubversion/help/subversion.rst -> build/lib/hgsubversion/help
   creating build/bdist.macosx-10.7-intel
   creating build/bdist.macosx-10.7-intel/egg
   creating build/bdist.macosx-10.7-intel/egg/hgsubversion
   copying build/lib/hgsubversion/__init__.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   copying build/lib/hgsubversion/__version__.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   copying build/lib/hgsubversion/editor.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   creating build/bdist.macosx-10.7-intel/egg/hgsubversion/help
   copying build/lib/hgsubversion/help/subversion.rst -> build/bdist.macosx-10.7-intel/egg/hgsubversion/help
   copying build/lib/hgsubversion/maps.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   copying build/lib/hgsubversion/pushmod.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   copying build/lib/hgsubversion/replay.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   copying build/lib/hgsubversion/stupid.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   copying build/lib/hgsubversion/svncommands.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   copying build/lib/hgsubversion/svnexternals.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   copying build/lib/hgsubversion/svnmeta.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   copying build/lib/hgsubversion/svnrepo.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   creating build/bdist.macosx-10.7-intel/egg/hgsubversion/svnwrap
   copying build/lib/hgsubversion/svnwrap/__init__.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion/svnwrap
   copying build/lib/hgsubversion/svnwrap/common.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion/svnwrap
   copying build/lib/hgsubversion/svnwrap/subvertpy_wrapper.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion/svnwrap
   copying build/lib/hgsubversion/svnwrap/svn_swig_wrapper.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion/svnwrap
   copying build/lib/hgsubversion/util.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   copying build/lib/hgsubversion/wrappers.py -> build/bdist.macosx-10.7-intel/egg/hgsubversion
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/__init__.py to __init__.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/__version__.py to __version__.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/editor.py to editor.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/maps.py to maps.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/pushmod.py to pushmod.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/replay.py to replay.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/stupid.py to stupid.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/svncommands.py to svncommands.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/svnexternals.py to svnexternals.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/svnmeta.py to svnmeta.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/svnrepo.py to svnrepo.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/svnwrap/__init__.py to __init__.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/svnwrap/common.py to common.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/svnwrap/subvertpy_wrapper.py to subvertpy_wrapper.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/svnwrap/svn_swig_wrapper.py to svn_swig_wrapper.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/util.py to util.pyc
   byte-compiling build/bdist.macosx-10.7-intel/egg/hgsubversion/wrappers.py to wrappers.pyc
   creating build/bdist.macosx-10.7-intel/egg/EGG-INFO
   copying hgsubversion.egg-info/PKG-INFO -> build/bdist.macosx-10.7-intel/egg/EGG-INFO
   copying hgsubversion.egg-info/SOURCES.txt -> build/bdist.macosx-10.7-intel/egg/EGG-INFO
   copying hgsubversion.egg-info/dependency_links.txt -> build/bdist.macosx-10.7-intel/egg/EGG-INFO
   copying hgsubversion.egg-info/top_level.txt -> build/bdist.macosx-10.7-intel/egg/EGG-INFO
   zip_safe flag not set; analyzing archive contents…
   hgsubversion.__init__: module references __file__
   hgsubversion.util: module references __file__
   creating dist
   creating ‘dist/hgsubversion-1.2.1_34_f28e0f54a6ef-py2.7.egg’ and adding ‘build/bdist.macosx-10.7-intel/egg’ to it
   removing ‘build/bdist.macosx-10.7-intel/egg’ (and everything under it)
   Processing hgsubversion-1.2.1_34_f28e0f54a6ef-py2.7.egg
   creating /Library/Python/2.7/site-packages/hgsubversion-1.2.1_34_f28e0f54a6ef-py2.7.egg
   Extracting hgsubversion-1.2.1_34_f28e0f54a6ef-py2.7.egg to /Library/Python/2.7/site-packages
   Adding hgsubversion 1.2.1-34-f28e0f54a6ef to easy-install.pth file
   
   Installed /Library/Python/2.7/site-packages/hgsubversion-1.2.1_34_f28e0f54a6ef-py2.7.egg
   Processing dependencies for hgsubversion==1.2.1-34-f28e0f54a6ef
   Finished processing dependencies for hgsubversion==1.2.1-34-f28e0f54a6ef
4. Check the version of Hgsubversion. Since we haven’t enabled it yet, it won’t report anything terribly useful.
   
   $ hg version —svn
   hg version: option —svn not recognized
   hg version
   
   output version and copyright information
   
   use "hg help version" to show the full help text
5. Add Hgsubversion to your ~/.hgrc to enable the extension. We previously enabled the “bookmarks” and “hggit” extensions.
   
   [extensions]
   hgext.bookmarks =
   hggit =
   hgsubversion =
6. Check Hgsubversion’s version again. Now that it is enabled, it should report information similar to what you see below, which is very different than what we saw above.
   
   $ hg version —svn
   Mercurial Distributed SCM (version 1.9.2+20110831)
   (see <a href="http://mercurial.selenic.com" title="http://mercurial.selenic.com">http://mercurial.selenic.com</a> for more information)
   
   Copyright (C) 2005-2011 Matt Mackall and others
   This is free software; see the source for copying conditions. There is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
   
   hgsubversion: 1.2.1+34-f28e0f54a6ef
   Subversion: 1.6.16
   bindings: Subvertpy 0.8.7
7. Run the Hgsubversion test suite. In my case, I had failures, a situation which appears to already have been reported in the Hgsubversions issue tracker.
   
   $ python tests/run.py
   ………………………………………….F………FF…………………………..FEF………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………
   ======================================================================
   ERROR: test_file_map_exclude_stupid (test_fetch_mappings.MapTests)
   –––––––––––––––––––––––-
   Traceback (most recent call last):
     File "/private/tmp/hgsubversion_work/tests/test_fetch_mappings.py", line 130, in test_file_map_exclude_stupid
       self.test_file_map_exclude(True)
     File "/private/tmp/hgsubversion_work/tests/test_fetch_mappings.py", line 125, in test_file_map_exclude
       self.wc_path, filemap=self.filemap)
     File "/Library/Python/2.7/site-packages/mercurial/commands.py", line 1041, in clone
       branch=opts.get(‘branch’))
     File "/Library/Python/2.7/site-packages/mercurial/hg.py", line 334, in clone
       destrepo.clone(srcrepo, heads=revs, stream=stream)
     File "/Library/Python/2.7/site-packages/mercurial/localrepo.py", line 1946, in clone
       return self.pull(remote, heads)
     File "/private/tmp/hgsubversion_work/hgsubversion/svnrepo.py", line 48, in wrapper
       return fn(self, *args, **opts)
     File "/private/tmp/hgsubversion_work/hgsubversion/svnrepo.py", line 63, in pull
       return wrappers.pull(self, remote, heads, force)
     File "/private/tmp/hgsubversion_work/hgsubversion/wrappers.py", line 346, in pull
       firstrun)
     File "/private/tmp/hgsubversion_work/hgsubversion/stupid.py", line 642, in convert_rev
       ui, svn, meta, b, branches[b], r, parentctx)
     File "/private/tmp/hgsubversion_work/hgsubversion/stupid.py", line 228, in diff_branchrev
       files_data = patchrepo(ui, meta, parentctx, cStringIO.StringIO(d2))
     File "/private/tmp/hgsubversion_work/hgsubversion/stupid.py", line 168, in patchrepo
       ret = patch.patchbackend(ui, backend, patchfp, 0, touched)
     File "/Library/Python/2.7/site-packages/mercurial/patch.py", line 1412, in patchbackend
       raise PatchError(_(‘patch failed to apply’))
   PatchError: patch failed to apply
   
   ======================================================================
   FAIL: test_many_special_cases_diff (test_fetch_command.TestBasicRepoLayout)
   –––––––––––––––––––––––-
   Traceback (most recent call last):
     File "/private/tmp/hgsubversion_work/tests/test_fetch_command.py", line 72, in test_many_special_cases_diff
       self._many_special_cases_checks(repo)
     File "/private/tmp/hgsubversion_work/tests/test_fetch_command.py", line 83, in _many_special_cases_checks
       ‘4e256962fc5df545e2e0a51d0d1dc61c469127e6’)
   AssertionError: ‘13c5dc1514ad8619c589a8929bfe0ece5c00f18e’ != ‘4e256962fc5df545e2e0a51d0d1dc61c469127e6’
   
   ======================================================================
   FAIL: test_oldest_not_trunk_and_tag_vendor_branch (test_fetch_command.TestStupidPull)
   –––––––––––––––––––––––-
   Traceback (most recent call last):
     File "/private/tmp/hgsubversion_work/tests/test_fetch_command.py", line 224, in test_oldest_not_trunk_and_tag_vendor_branch
       ‘1a6c3f30911d57abb67c257ec0df3e7bc44786f7’)
   AssertionError: ‘fa799f2781255dba874645e849d75af837472518’ != ‘1a6c3f30911d57abb67c257ec0df3e7bc44786f7’
   
   ======================================================================
   FAIL: test_stupid (test_fetch_command.TestStupidPull)
   –––––––––––––––––––––––-
   Traceback (most recent call last):
     File "/private/tmp/hgsubversion_work/tests/test_fetch_command.py", line 201, in test_stupid
       ‘4e256962fc5df545e2e0a51d0d1dc61c469127e6’)
   AssertionError: ‘13c5dc1514ad8619c589a8929bfe0ece5c00f18e’ != ‘4e256962fc5df545e2e0a51d0d1dc61c469127e6’
   
   ======================================================================
   FAIL: test_file_map_exclude (test_fetch_mappings.MapTests)
   –––––––––––––––––––––––-
   Traceback (most recent call last):
     File "/private/tmp/hgsubversion_work/tests/test_fetch_mappings.py", line 127, in test_file_map_exclude
       self.assertEqual(node.hex(self.repo[‘default’].node()), ‘b37a3c0297b71f989064d9b545b5a478bbed7cc1’)
   AssertionError: ‘81ae7af456c0e414ddc380ff641b37da84a9df8f’ != ‘b37a3c0297b71f989064d9b545b5a478bbed7cc1’
   
   ======================================================================
   FAIL: test_file_map_stupid (test_fetch_mappings.MapTests)
   –––––––––––––––––––––––-
   Traceback (most recent call last):
     File "/private/tmp/hgsubversion_work/tests/test_fetch_mappings.py", line 115, in test_file_map_stupid
       self.test_file_map(True)
     File "/private/tmp/hgsubversion_work/tests/test_fetch_mappings.py", line 112, in test_file_map
       self.assertEqual(node.hex(self.repo[‘default’].node()), ‘e524296152246b3837fe9503c83b727075835155’)
   AssertionError: ‘ecf9b521a1799ebb0e01c1d1e86305ea8b542d2e’ != ‘e524296152246b3837fe9503c83b727075835155’
   
   –––––––––––––––––––––––-
   Ran 492 tests in 1212.923s
   
   FAILED (failures=5, errors=1)

That’s it! Hgsubversion has been installed and enabled. Even though we got errors from the tests, we can proceed.

1. Clone a Subversion repository, like the InstaDMG one.
   • This gets you just the trunk and current state:
     
     $ hg clone <a href="http://instadmg.googlecode.com/svn/trunk" title="http://instadmg.googlecode.com/svn/trunk">http://instadmg.googlecode.com/svn/trunk</a> /tmp/instadmg_trunk_work
   • This gets you the full history.
     
     $ hg clone <a href="http://instadmg.googlecode.com/svn/" title="http://instadmg.googlecode.com/svn/">http://instadmg.googlecode.com/svn/</a> /tmp/instadmg_full_work
2. Enable the Mercurial Keywords extension in the cloned repo’s .hg/hgrc. (According to the documentation, you should not enable the Keywords extension on a global basis in your ~/.hgrc, but instead do so on a repo-by-repo basis in .hg/hgrc.) We’ll also set it so it only affects Bash scripts with the right filename extension, because we want keyword expansion on just the “instadmg.bash” file.
   
   [paths]
   default = http://instadmg.googlecode.com/svn/trunk/
   
   [extensions]
   keyword =
   
   [keyword]
   # expand keywords in all bash and python files in working dir
   **.bash =
3. Set your HGUSER environment variable. The next step will need this. The following steps will do it temporarily for your current terminal session, so when you get a chance, you’ll want to read about how to do this more permanently.
   
   $ HGUSER="anonymous"
   $ export HGUSER
4. Try kwdemo. You must be in the directory for the cloned repository and have enabled the Keyword extension.
   
   $ hg kwdemo —default
   
           configuration using default svn keywordset
   [extensions]
   keyword =
   [keyword]
   **.bash =
   demo.txt =
   [keywordset]
   svn = True
   [keywordmaps]
   Author = {author|user}
   Date = {date|svnisodate}
   Id = {file|basename},v {node|short} {date|svnutcdate} {author|user}
   LastChangedBy = {author|user}
   LastChangedDate = {date|svnisodate}
   LastChangedRevision = {node|short}
   Revision = {node|short}
   
           keywords expanded
   $Author: anonymous $
   $Date: 2011-09-26 14:32:06 -0400 (Mon, 26 Sep 2011) $
   $Id: demo.txt,v 5e86fb5c9fae 2011-09-26 18:32:06Z anonymous $
   $LastChangedBy: anonymous $
   $LastChangedDate: 2011-09-26 14:32:06 -0400 (Mon, 26 Sep 2011) $
   $LastChangedRevision: 5e86fb5c9fae $
   $Revision: 5e86fb5c9fae $
5. Edit the .hg/hgrc file for the cloned repository so that you can set up keyword substitution for the “Revision” keyword. In my experience, you’ll need to set up a map for this, unless you want to get the Hg revision number that you see in the default output of kwdemo above.
   
   [paths]
   default = http://instadmg.googlecode.com/svn/
   
   [extensions]
   keyword =
   
   [keyword]
   # expand keywords in all bash and python files in working dir
   **.bash =
   
   [keywordmaps]
   Revision = {svnrev}
6. Try the demo again. I never get this part to work, but you may have more luck. Actual shrinking/expansion, which we’ll see next, does work for me.
   
   $ hg kwdemo —rcfile .hg/hgrc
   
           configuration using custom keyword template maps
           extending current template maps
   [extensions]
   keyword =
   [keyword]
   **.bash =
   demo.txt =
   [keywordset]
   svn = False
   [keywordmaps]
   Revision = {svnrev}
   
           keywords expanded
   $Revision:  $
7. Expand the keywords in your local InstaDMG repository.
   
   $ hg kwshrink # Run after each keyword configuration change
   $ grep Revision instadmg.bash
   SVN_REVISION=`/bin/echo ‘$Revision$’ | /usr/bin/awk ’{ print $2 }’`
   $ hg kwexpand # Run to expand the keywords in the repository. Be sure to kwshrink before making and committing changes.
   $ grep Revision instadmg.bash
   SVN_REVISION=`/bin/echo ‘$Revision: 425 $’ | /usr/bin/awk ’{ print $2 }’`
   $ hg kwshrink

Notice that “Revision: 425” is returned when keywords are expanded, replacing the “$Revision” keyword. This is precisely what we need with InstaDMG, where the revision information is reported when the instadmg.bash script is run.

Hg-Git is the Mercurial extension to use if you want to connect to local or remote Git repositories. I exclusively use Mercurial and Hg-Git for all of my Github transactions, so I can personally vouch that it works.

Now that Hg-Git has been updated to better support Mercurial 1.9, let’s see if we can get an Hg toolchain working on Lion. Since I did that on Snow Leopard a few days ago, Hg-Git has made it into PyPI. The installation instructions this time are a bit more streamlined, because we can now use easy_install to get Hg-Git and its dependencies.

To get the toolchain set up, we’ll need Xcode. The Xcode suite includes tools we’ll need to make Python easy_install work, along with Subversion (a prerequisite for Hgsubversion, which I’ll talk about in a later article) and other useful tools.

The Xcode installation is a multi-step install process. Both current download methods — the developer download through connect.apple.com (if you have a paid Mac Developer Account) and the Mac App Store — give you an “Install Xcode” application. That application runs a second, real installer that you have to finish before you actually have the Xcode tools available in a ready-to-use state. This is very similar to the situation for Mac OS X Lion, so you may be developing a sense of familiarity with the situation.

To install Mercurial:

1. Download Mercurial 1.9.2 or later. The binary packages are standard Mac OS X packages; get the one for Lion.
2. Install Mercurial.

To add Hg-Git to Mercurial on Lion:

1. Download Xcode 4.1 or later if you don’t already have it. You can do this through connect.apple.com or via the Mac App Store.
2. Install Xcode if it is not already installed.
   • Open the developer disk image, run the installer inside it, and then run the “Install Xcode” application that was placed in /Applications.
   • Run the “Install Xcode” application that was placed in /Applications by the Mac App Store.
3. Open Terminal. Run the following command, which will install hg-git and its dependencies (including dulwich, of which you’ll want version 0.8.0 or later):
   
   $ sudo easy_install ‘hg-git>=0.3.1’
   Password:
   Searching for hg-git>=0.3.1
   Reading <a href="http://pypi.python.org/simple/hg-git/
   Reading" title="http://pypi.python.org/simple/hg-git/
   Reading">http://pypi.python.org/simple/hg-git/
   Reading</a> <a href="http://hg-git.github.com/
   Best" title="http://hg-git.github.com/
   Best">http://hg-git.github.com/
   Best</a> match: hg-git 0.3.1
   Downloading <a href="http://pypi.python.org/packages/source/h/hg-git/hg-git-0.3.1.tar.gz#md5=4b15867a07abb0be985177581ce64cee
   Processing" title="http://pypi.python.org/packages/source/h/hg-git/hg-git-0.3.1.tar.gz#md5=4b15867a07abb0be985177581ce64cee
   Processing">http://pypi.python.org/packages/source/h/hg-git/hg-git-0.3.1.tar.gz#md5=…</a> hg-git-0.3.1.tar.gz
   Running hg-git-0.3.1/setup.py -q bdist_egg —dist-dir /tmp/easy_install-_Uauza/hg-git-0.3.1/egg-dist-tmp-rERQMH
   zip_safe flag not set; analyzing archive contents…
   Adding hg-git 0.3.1 to easy-install.pth file
   
   Installed /Library/Python/2.7/site-packages/hg_git-0.3.1-py2.7.egg
   Processing dependencies for hg-git>=0.3.1
   Searching for dulwich>=0.8.0
   Reading <a href="http://pypi.python.org/simple/dulwich/
   Reading" title="http://pypi.python.org/simple/dulwich/
   Reading">http://pypi.python.org/simple/dulwich/
   Reading</a> <a href="http://samba.org/~jelmer/dulwich
   Reading" title="http://samba.org/~jelmer/dulwich
   Reading">http://samba.org/~jelmer/dulwich
   Reading</a> <a href="http://launchpad.net/dulwich
   Best" title="http://launchpad.net/dulwich
   Best">http://launchpad.net/dulwich
   Best</a> match: dulwich 0.8.0
   Downloading <a href="http://samba.org/~jelmer/dulwich/dulwich-0.8.0.tar.gz
   Processing" title="http://samba.org/~jelmer/dulwich/dulwich-0.8.0.tar.gz
   Processing">http://samba.org/~jelmer/dulwich/dulwich-0.8.0.tar.gz
   Processing</a> dulwich-0.8.0.tar.gz
   Running dulwich-0.8.0/setup.py -q bdist_egg —dist-dir /tmp/easy_install-bHRaTM/dulwich-0.8.0/egg-dist-tmp-MNy6RK
   dulwich/_objects.c: In function ‘py_parse_tree’:
   dulwich/_objects.c:101: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_objects.c: In function ‘cmp_tree_item’:
   dulwich/_objects.c:148: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_objects.c:152: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_objects.c: In function ‘py_sorted_tree_items’:
   dulwich/_objects.c:192: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_objects.c:224: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_pack.c: In function ‘py_apply_delta’:
   dulwich/_pack.c:98: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_pack.c:101: warning: implicit conversion shortens 64-bit value into a 32-bit value
   zip_safe flag not set; analyzing archive contents…
   dulwich.tests.__init__: module references __file__
   dulwich.tests.test_index: module references __file__
   dulwich.tests.test_objects: module references __file__
   dulwich.tests.test_pack: module references __file__
   dulwich.tests.utils: module references __file__
   Adding dulwich 0.8.0 to easy-install.pth file
   Installing dul-daemon script to /usr/local/bin
   Installing dul-web script to /usr/local/bin
   Installing dulwich script to /usr/local/bin
   
   Installed /Library/Python/2.7/site-packages/dulwich-0.8.0-py2.7-macosx-10.7-intel.egg
   Finished processing dependencies for hg-git>=0.3.1
4. Edit your ~/.hgrc to enable the Hg-Git Mercurial extension, as noted in the Hg-Git documentation.
   
   [extensions]
   hgext.bookmarks =
   hggit =

That’s it! Once Mercurial 1.9 plus Hg-Git 0.3.1 or later are installed and you’ve enabled Hg-Git in your ~/.hgrc, you are ready to use Mercurial with local and remote Git repositories.

Here is my current installation method for Mercurial 1.9 and Hg-Git on Mac OS X Snow Leopard. I use Hg-Git on a sporadic basis to work with projects on Github. That activity is frequent enough that it’s really helpful to be able to get Hg-Git set up and working quickly.

I had a rough time with Hg-Git after I upgraded to Mercurial 1.9 a few weeks ago. It was notable because that was the first time I can remember having incompatibilities between this stack of software. Since then, Hg-Git has changes available that allow it to install and work with newer versions of Mercurial, including version 1.9, and the most recent Dulwich release. These changes weren’t as readily available at the time I upgraded, so I thought it was worth writing this to remind me how to put the right pieces together.

1. Install Mercurial 1.9.2. The installers for Leopard, Snow Leopard, and Lion are available from the main Mercurial site.
2. Install Dulwich 0.8.0 using easy_install. Here is where I learned you could specify a minimum version or a specific version with easy_install. While doing so is not strictly necessary in this case, I am writing it down to remember the next time I need it.
   
   sudo easy_install ‘dulwich>=0.8’
3. Obtain hg-git 0.3.1 using Augie Fackler’s repository on Bitbucket.org. We will clone it into /tmp, so that it will exist there only until reboot. It’ll get cleaned up and removed, which is fine, because I typically don’t need this repository stored on my drive.
   
   cd /tmp
   hg clone ssh://hg@bitbucket.org/durin42/hg-git hg-git-work
4. Run the setup process for hg-git from your local clone.
   
   cd /tmp/hg-git-work
   sudo python setup.py install
5. Add hg-git to the “[extensions]” section of your ~/.hgrc file, creating the ~/.hgrc file if needed, as documented for Hg-Git.

I don’t yet have a working installation method for all of this software on Mac OS X Lion. I ran into a stumbling block getting Dulwich installed there, and Dulwich is a necessity for Hg-Git. Update: The situation changed a few days later, and I have instructions for Mac OS X Lion available now.

This may have been a problem isolated to the particular Lion system I was using. I haven’t had the chance to duplicate it elsewhere or troubleshoot the problem on the system where I encountered it.

Update: Since I wrote this, Hg-Git 0.3.1 became available through PyPI, which means you can install it via easy_install. You no longer need to clone the Hg-Git repository and run the setup process manually. Instead, you can run the following single command to get Hg-Git 0.3.1 and its dependencies (Dulwich 0.8.0 or later):

This simplifies the instructions quite a bit, but I leave the original steps above for reference.

There may be times when you want to obtain the number of the latest available version — not just the latest installed version — of a software package through automated means. If the vendor or project provides a syndication feed (either RSS or Atom) that describes new releases, then you may be able to parse that data and get the newest release from it.

As an example, let’s examine the RSS feed for Group Logic’s ExtremeZ-IP. Other developers provide RSS/Atom feeds for their releases, but the EZIP feed is a good one to start a demonstration with because it is generally structured well.

We can break apart the EZIP feed with the Universal Feed Parser module for Python, which you must obtain separately.

Update: Because of Mark Pilgrim situation (also described here), the Universal Feed Parser Web site is no longer available. There is an alternative source for the Universal Feed Parser at Google Code, and I have cloned the Universal Feed Parser repository to Bitbucket from there.

As you can see, the “ExtremeZ-IP Latest Releases” feed is automatically recognized as RSS 2.0. I prefer to use HTTPS for fetching these feeds whenever possible, so if the developer has an HTTP feed, I try to see if it also works with HTTPS.

Next, let’s find out where the version numbers are kept in the feed. It looks like they are in the entry title, based on reading the feed in Safari RSS. I can confirm that with the Universal Feed Parser. We’ll want to examine the title of every feed item so we can better handle both current and future entries from the feed. There are more entries to the EZIP than I will print out.

We get Unicode strings as output from the Universal Feed Parser. That’s why the quoted strings are preceded with a “u” character.

I’d like to strip out the version string from the title element in each entry. I’m going to do so by splitting on whitespace and getting the last group of characters from the string. (This doesn’t account for text like “Hot Fix,” as seen in the EZIP feed, but it is still a good enough starting point for my purposes.)

By stripping out the build number after “x” in the version string, you potentially lose some data. In the EZIP feed, there are entries where two consecutive version numbers are the same except for the build number after the “x.” However, depending on your needs, it may still be useful to eliminate that part of the version string, so we’ll do that next.

We really only need the most current or “top” item in the feed, since that should give us the newest release number. The newest version in this particular feed should be in the first entry. That’s “entries[0]” below, because we’re using Python and it zero references the first item in lists.

There, we now have the version number of the most current release, 7.1.1, for the product. We have drawn it straight from the developer’s syndicated feed, so it is as current as the developer makes it.

How could that be useful? The output can be compared against other data, like the currently-installed version. The comparison, in turn, could be made part of a monitoring workflow, so you could get alerts if you fall behind.

If we didn’t strip the build number after the “x,” we would be left with a complex version number. Some Python tools, like distutils, will not currently handle the trailing characters in the version number well.

I have found that you can improve upon distutils’ StrictVersion/LooseVersion version number handling by switching to parse_version in pkg_rsources (“from pkg_resources import parse_version as V”). More coverage of that topic appears in PEP 386. If you are comparing the original version strings from the EZIP feed with similarly complex output from elsewhere, then I would probably use the pkg_resources module.

The McAfee DAT update 5958 was issued on April 21, 2010, and created quite a situation. Heretofore, I will remember what transpired as “the events of April 21.”

I think that someday, examining what happened would make an interesting case study in crisis management. A lot of the incident unfolded on the Internet — and on Twitter, specifically. The company even became a trending topic, as seen in this screenshot I took after lunchtime (I think around 2 PM Eastern time, although I only saved later):

The 5958 DAT was available on McAfee’s publicly-accessible HTTP and FTP download repositories until at least 1 PM Eastern, when I was checking on them.

The Windows and Mac anti-malware products from McAfee share DAT updates, which provide virus definitions. I was able to update VirusScan for Mac OS X to 5958 with no ill effects in the midst of the developing situation. (The problem only appears to have affected Windows XP systems.) Later, when McAfee had posted a newer update as version 5959, I was also able to download that.

Based on reports I saw on Twitter and the Web, McAfee was overwhelmed by this — particularly its call center and its Web-based customer forums. This allowed a lot of speculation and misinformation — along with humor — to break out.

I’ve saved this undoctored screen shot for a while. I figure I’ll end with it, even though it’s unrelated to the events of April 21.

I came across this hint about display properties on StackOverflow and thought it was worthwhile to write down for later. If you want to get the screen or Desktop resolution of a Mac via Python, you can do so with PyObjC.

First, let’s get the information about the main screen:

If you want just the horizontal and vertical resolution from that blob of data, you can pull the width and height out:

This might be useful in situations where you don’t have any of the “hundred of portable libs in Python that give you access to that information” — such as in your stock Mac OS X Python installation. To clarify: I’m in no way meaning to belittle that there are portable libraries that would let you do the same thing, but you also have to program for your audience and its constraints. One of the reasons I appreciate Python over some scripting languages is that you get so much capability in the Standard Library. However, on Mac OS X, you don’t get modules like pygame by default (yet … and maybe never) while you do get PyObjC.

Jesper Noehr explains why {l,r}strip are considered harmful for removing extensions from filenames with Python. I think he’s absolutely right on that score, and I would agree. The lstrip() and rstrip() methods shouldn’t be used for this purpose.

However, like the only commenter on that post, I’d also recommend os.path.splitext() as the proper tool for the extension-removing job.

Let’s take some example filenames you might come across on Mac OS X Snow Leopard:

If we had a list of filenames (or file paths) like this — perhaps created by os.walk() or some other generator-based process — we couldn’t easily use Jesper’s recommended solution. The replace() string method would give us a much harder time dealing with the range of filenames and extensions in that list. In the case where you don’t know the filename extensions in advance, replace() breaks down. The replace() method would have to be looped with many possible filename extensions.

What we need is a way to split filename from extension, even if we don’t know the extension beforehand. The os.path.splitext() alternative does just that, returning a tuple. Here, I’ll import the os module and then use a list comprehension to run os.path.splitext() through every filename in the list above.

It becomes a simple matter to get just the filename from the tuple, as I do here by modifying the list comprehension to just get the zeroth item from it:

Note that several interesting conditions are handled by os.path.splitext():

• long filename extensions, including “.pages” and “.networkConnect”
• spaces in filenames, as in “Property List.plist”
• parentheses, as in “VPN (Cisco VPN).networkConnect”
• periods within the filename, as seen in “Dated Spreadsheet 2010.02.17.xlsx”