tar -z vs tar -j

tar -j uses bzip2
tar -z uses gzip

bzip2 compresses more but slower.

http://jeremy.zawodny.com/blog/archives/000953.html
http://en.wikipedia.org/wiki/Bzip2

tar -cvjf  new.tar dir_or_files

tar -xvjf new.tar

 Or should there be a "j" in the ".tar" so people know they need 'j' to extract?  Like: 

tar -cvzf new.tar.Z dir_or_files

tar -xzvf new.tar.Z

DOS scripting: nesting if's in place of AND

I want to say 'IF EXIST file1 AND EXIST file2'... but there's no AND.

But I can nest the if EXIST's:

if EXIST file1 (if EXIST file2 echo Both There)

For the ELSE, it gets more complicated:

if EXIST file1 (if EXIST file2 (echo Both There) ELSE echo Nope)

 Will echo Nope if file1 exists and not file 2, but not if file2 exists but not file1.  So you need:

if EXIST file1 (if EXIST file2 (echo Both There) ELSE echo Not 2) ELSE echo Not 1

 That will tell you either "Both There", or "Not 1" if only file1 isn't, or "Not 2" if only file2 isn't.

python: function with optional/default argument

>def testf(foo="blah"):
... print foo
...
>testf("hi there")
hi there
>testf()
blah

When Python shows you where the shared object is and says it doesn't exist

We had this error and it was driving me crazy:

    ImportError: [/.../..]/python2.4/lib/python2.4/lib-dynload/datetime.so: cannot open shared object file: No such file or directory
    [01,003839]PYTHON Error : Undefined Python Module :

When I did an ls for that directory, the shared object was in fact there.  It didn't even help to move the shared object into the same directory as my code.  I googled and looked on the python.org website and couldn't find any other mention of it.  That is, besides making sure the python path and load path were set and that the .so was executable, but that didn't solve the problem.

It turned out that the problem was that calls to the python module were embedded in a larger C program that had compiled and linked pointing to a 32-bit version of python2.4.  But the script that was trying to run the compiled code was pointing to a 64-bit version of python2.4.

Make sure all your python symbolic links are pointing to the same python.

To see if this is your problem, run the Linux "file" command on the .so and on the c-executable that's linked to the python module that's importing the .so.

 $file /[..]/python2.4/lib/python2.4/lib-dynload/datetime.so
/[..]/python2.4/lib/python2.4/lib-dynload/datetime.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped

$file cpgm
cpgm: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped

To solve this, re-compile cpgm in 64 bits, or point to the 32-bit version of python to run it.

$ file cpgm
cpgm: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped

You can get into this trouble on a 64-bit machine or VM since it will run 32-bit compiled code (whereas a 32-bit machine won't run 64-bit compiled code.)