So, in the process of organizing photographs, I wanted to examine my deeply-nested hierarchy to figure out how it’s possible I have 30,000 images (Aperture only wants me to have 10,000 in a project, so I need to re-organize the hierarchy even before I import).

So, I figured it’d be easy to use find to list all my directories, and how many images they contain. It turns out that (at least for me) it’s not.

My best stab so far is to use find and a loop, which gives me almost what I want (it not only includes the count of images in the each directory, but subdirectories as well). It fails if there are too many directories. It’s good enough. But it’s not elegant.

So CLI Deities — how would you make this pretty?

find . -type d | while read dir; do echo `ls -1 "$dir" | wc -l` $dir; done

Potential type-face issue disambiguation: after the ls, that first argument is a one, not an ell, although I suppose an ell would work too. The wc option is an ell.

As I described back in this article, I was getting segfault errors from eAccelerator.

I’m experiencing it on another, similarly-equipped GoDaddy VPS server. Same software versions, even, for Apache, PHP, eAccelerator, and OS, although this is not a old CMS Made Simple install.

Still, no good solutions out there, as far as I can google.

Here’s the clues I have found:

• The syntax function fun_name ($arg = array (blah)) is fatal.
• The order in which PHP extensions are loaded might matter.
• There are issues with files that get included or required multiple times via different paths.
• Software versions are just Too Old.

This is teh suckage.

Next thing I’ll try, when I have the time, is to upgrade the VPS to Fedora Core 6, and see if pushing those version numbers up a bit helps.

Windows update just told me it was installing a “Malicious Software Removal Tool.”

Gosh, I hope that the virtual hyphen is between the first two words, rather than the second.

*sigh*

So, it’s Saturday night, 10pm on a three-day Holiday Weekend. And another important server decides to have a fatal disk error.

How do they f*ing know?

It’s uncanny.

This is just another in a long series of similar failures. The power supply failed in my security-system a few years ago — hours before we were going to leave for a vacation. The previous time the security system crashed (due to unfortunate automatic software update) was — yup — the afternoon Elizabeth and I were leaving for a weekend cruise. And Elizabeth’s Mac had its hard drive fail the day I left for Bulgaria.

Of course, we all know why this is. There have been half a dozen other failures that happened during more mundane times, which evoked the standard rage/repair response. But that was par for the course, and soon forgotten.

So here I am. Saturday night … fixing machines. I should have been a ditch digger or something.

So, I’m working on an old RoR application, and was having a hard time getting it to work on my newer development machine.

The error dump was not at all clear:

C:\project\foo_bar_baz_quux>rake migrate --trace
(in C:/project/foo_bar_baz_quux)
** Invoke migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute migrate
rake aborted!
wrong number of arguments (1 for 0)
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `initialize'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `new'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `scramble41'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:141:in `real_connect'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:316:in `connect'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:87:in `initialize'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:37:in `new'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:37:in `mysql_connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:145:in `send'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:145:in `connection_without_query_c
ache='
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/query_cache
.rb:54:in `connection='
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:106:in `retrieve_connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:20:in `connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/migration.r
b:178:in `migrate'
c:/ruby/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/tasks/databases.rake:3
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `call'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `synchronize'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7
c:/ruby/bin/rake.bat:20:in `load'
c:/ruby/bin/rake.bat:20


I went through a lot of work to use older versions of Rails, etc, but none of it worked. I didn’t find much out
there that helped, either, until I finally happened across this page.

Turns out it’s one of those pernicious password / old style password hash issues with MySQL. Simplest solution for now: use no database password on the dev box.