Resizing Images from the Command Line

I love the power of the Linux command line. I am working on resizing images and I was able to resize only the ones I wanted with a few commands. Here is what I came up with:

    
# Get only the files with a vertical or horizontal resolution of 4320px;
# the output is the file name followed by the resolution:
find . -name "*.JPG" -exec identify -format "%d/%f %wx%h" {} \; | grep 4320 > files.txt

# Get just the file name:
awk -F ' ' '{ print $1 }' < files.txt > files2resize.txt

# Resize the photos:
for i in `cat files2resize.txt`; do 
    mogrify -verbose -resize '2816x2816>' "$i"; 
done

SSH Match Errors

I could not start ssh after adding the following lines to my sshd_config:

Match Address 192.168.0.0/24 
GatewayPorts yes

The only clue are the following lines from syslog:

Apr 26 21:03:11 desktop kernel: [264746.428869] init: ssh main process (8486) terminated with status 255
Apr 26 21:03:11 desktop kernel: [264746.428942] init: ssh main process ended, respawning
Apr 26 21:03:11 desktop kernel: [264746.437024] init: ssh main process (8489) terminated with status 255
Apr 26 21:03:11 desktop kernel: [264746.437099] init: ssh main process ended, respawning
Apr 26 21:03:11 desktop kernel: [264746.446559] init: ssh main process (8492) terminated with status 255
Apr 26 21:03:11 desktop kernel: [264746.446627] init: ssh respawning too fast, stopped

After searching Google I found this bug report.
The final entry gave the solution in my case, the Match directive must come after the Subsystem directive. After moving things around, everything began to work again.

CyanogenMod Recovery

The other day I picked up my phone and it was sitting at the CyanogenMod 7 boot screen. The blue arrow just going around and around and around. Completely out of the blue, considering it had been running apps when it was put down.

It was quite a saga to get it back up and running again. I went through lots of flashing and many different types of boot loops. The problem was, I could not get into recovery mode. So, I tried flashing ClockworkMod recovery. That caused a boot loop. Installed Froyo, boot loop. Then I installed a different Froyo, cwm and tried flashing CM7 again. Boot loop. Finally, I got it with Froyo, SuperOneClick root, ROM Manager, cwm recovery, CM7.

I thought I was done, but this is really where things got interesting. ROM Manager would no longer boot into recovery, so I couldn’t install the Google Apps. No google apps means you don’t get Android Market, etc… I tried upgrading ROM Manager via a apk downloaded from their site, but that didn’t work. Next I tried flashing cwm again, but that wouldn’t work.

Here are the things I learned along the way that would have shortened the trip considerably:

1. Getting into recovery mode via the 3 button method is subtly different than download mode. Hold down Power, Volume Up and Home until the Samsung screen comes up, then let go of the Power button. Continue to hold the other two buttons until you are in recovery. It appears I may have been letting go of the power button a little too quickly, assuming it worked just like download mode. It does not. I believe the two are available at different periods of the boot up sequence.
2. CM7 installs its own version of cwm recovery. This breaks the existing one you have and makes it unavailable from ROM Manager. You can access it via the Power button menu. Select Reboot then Recovery.
3. You can re-enable the ROM Manager recovery menu by going into the “Flash ClockworkMod Recovery” menu item, selecting “Samsung GalaxyS i9000 (MTD)”, click Yes to the question asking if you’ve installed a cwm based recovery manually (you have, the cm7 one), then select ClockworkMod 2.x. You can now reboot into it from the “Reboot into Recovery” menu.

Of course, all of this advice is pretty specific to my model of phone, but I had to cobble it together from a bunch of sources, so hopefully I can save someone some time.

Loading Your SSH Key at Login

I have two Linux machines that I periodically use ssh and scp between. Tonight I finally got tired of having to repeatedly enter my key’s passphase. So I looked up how to ssh-add my key to ssh-agent when KDE starts. On Kubuntu, KDE automatically loads ssh-agent with the session, so you only have to do a couple things to get everything set up:

1. Generate your keypair if you haven’t already done so.
2. Install ksshaskpass (aptitude install ksshaskpass)
3. Create file called askpass.sh in ~/.kde/Autostart and add the following:
   

   #!/bin/sh
   export SSH_ASKPASS=/usr/bin/ksshaskpass
   /usr/bin/ssh-add < /dev/null
   

4. chmod 755 ~/.kde/Autostart/askpass.sh
5. Logout and back in, again.

Ksshaskpass will ask you for your kwallet passphrase. It will then ask for your private key’s passphrase. At the bottom of the dialog it has a checkbox for it to remember your passphrase. Now when you log in (assuming you checked the box) you will only have to enter your wallet password. You can make your ssh key passphrase ridiculously complex this way because only kwallet needs to remember it. Now my machines trust each other and I can zip between them.

Enter Qt

So, what ever happened to my little .NET application that fell apart when it hit Mono?

Since I run KDE, I was hoping to get something written with Qt such that it looked native on my desktop. In looking around I found that there appears to be two main languages that Qt developers use: Python and C++. Both are languages that I am quite comfortable developing in and both are cross-platform. However, Python has two drawbacks:

1. it’s not compiled, which makes releasing on Windows somewhat troublesome, and
2. I was not able to find a Python IDE that had a visual designer.

Interestingly, since the application was a mix of Boo and C# half of it would port nicely to either language. In the end I decided on C++, and QtCreator for my IDE. QtCreator is a nice lean IDE with QtDesigner integrated in for UI creation.

Mono Woes

And finally we get to what is wrong with Mono. Aside from the tool-chain and various other issues, I found several problems with the framework itself.

First, and probably the most annoying thing is that when one of my apps crashes and the stack trace is printed, the mono framework seems to go AWOL. Running the application again produces nothing. It just immediately returns to the prompt with no error or any suggestion as to why. After waiting for appoximately two minutes Mono will start to work again. This is a major impediment to the edit/compile/debug cycle and happens consistently.

Another major issue is the Console.Readline() only intermittently echos the character you typed back to the screen. You never know if you have typed what you think you typed. Did the character not appear because you did not hit the key hard enough or because it did not get echoed back?

Finally, I also found that long running programs regularly exit without any errors. Just run a simple GUI app from the console and return a few hours later. The app will be closed and there will be nothing on stdout to suggest why.

Poor development tools are something that I can work around, but a frame*work* that does not work is something I cannot tolerate.

Aliases in Screen

What a headache!
GNU Screen on Cygwin was not getting my aliases. Searching all over the internet yields that screen runs ~/.bashrc since it is not a “login shell”. This was not happening. Everybody says to add shell -$SHELL to run an interactive shell and that will source your ~/.bash_profile which will usually source ~/.bashrc (as is my case). Now this works, but it does not explain why my ~/.bashrc is not running without shell -$SHELL. What does the documentation say?

shell command
Set the command to be used to create a new shell. This overrides the value of the environment variable $SHELL.

So what is my $SHELL variable set to?

$ echo $SHELL
/bin/bash

But if I run /bin/bash and run alias, all my aliases are there. Clearly screen is not doing what it says. So is that it? The documentation is just plain wrong? When I add shell $SHELL (notice the absence of the ‘-‘) my aliases do show up. But if shell _command_ “overrides the value of the environment variable $SHELL” wouldn’t shell $SHELL do nothing? Yet it does. It fixes my problem. Screen runs ~/.bashrc where it otherwise does not.
In summary:

• with nothing in ~/.screenrc: neither ~/.bashrc nor ~/.bash_profile run
• shell $SHELL: only ~/.bashrc is run (non-login shell)
• shell -$SHELL: ~/.bash_profile is run, which typically also sources ~/.bashrc (login shell)
• the GNU screen documentation is wrong. Or at least, unclear.