Linux/Unix: Redirecting Output Using ">" with sudo

Problem: In Linux/Unix, you want to redirect output of something to a file with > you don't have write permissions for:

local$ ls -la > test.txt
-bash: test.txt: Permission denied

You think "I can solve this by using sudo"! But, alas:

local$ sudo ls -la > test.txt
-bash: test.txt: Permission denied

The shell won't even ask for your password. This indicates to me that somehow sudo only applies to the ls command here. What seems to happen is that first, the shell tries to open the file and only then runs the ls command to feed it with input. But since you don't have write permissions for this file, the execution of the whole expression is stopped. The way to solve this, as I found out in this blog post, is to run bash (or any other shell) as sudo and then give it the entire expression as a parameter:

local$ sudo bash -c "ls -la > test.txt"
Password:
local$ more test.txt
total 16
drwxr-xr-x  18 root  wheel   612 Oct  8 16:23 .
drwxr-xr-x@ 13 root  wheel   442 Dec  6  2007 ..
drwxr-xr-x@ 13 knud  staff   442 Sep  8 11:45 arc
drwxr-xr-x  61 root  wheel  2074 Apr 17 12:30 bin
drwxr-xr-x  14 root  wheel   476 Dec  4  2007 gwTeX
drwxr-xr-x  33 root  wheel  1122 Feb 17  2009 include
drwxr-xr-x  56 root  wheel  1904 Feb 17  2009 lib
-rw-r--r--   1 root  wheel     0 Oct  8 16:23 test.txt

Note that test.txt is already in the this list, proving that the file was created before the ls command was run!

WordPress Blank Screen of Death

I'm using subversion to keep my WordPress installation updated. This always worked perfectly fine, but recently I did an update and wasn't able to access any php driven part of the blog anymore (so, basically everything). All I would get is the dreaded WordPress Blank Screen of Death.

I looked in the error logs (WP had a special error log in the Apache log folder) and saw that there was a Parse Error: parse error, unexpected T_SL reported for one of the php files. After some googling, this post here made me realise that the problem could be related to a subversion conflict, which will lead to < signs showing up in the source files, rendering them invalid. I checked the offending files and really, it turned out that my last svn update had introduced a conflict. To resolve it, I simply deleted the offending files, executed svn update again, and all my troubles were gone!

Login Problems on Mac OS X

After upgrading to OS X 10.5.5, I could no longer log in to my main account. No PRAM zapping or safe booting, as suggested in many places, helped. Luckily I had another account with admin rights set up and found out that the source of the problem could lie the user's directory service entry. It needs to be deleted and rebuilt like so:

1. Delete the corrupted entry: sudo rm /var/db/dslocal/nodes/Default/users/short-user-name.plist
2. The user has now dissapeared from the user list in the system preferences, but its home folder (i.e. all the data) is still there.
3. To rebuild the ds entry, create a new user with the same short user name as the old.
4. You'll be asked if you want to use the existing home folder for the new user. Agree to that.

Of course I didn't find out about all that myself. It was all nicely described somewhere down in this post on Apple's discussion boards.