Recursively Count File Types and Files in a Directory

Written by Sean Ryan on . Posted in Uncategorized

I was tired of writing this every time I needed to so I’m blogging.

Copy/paste this onto a command line and it will print the name of the file extension and the number of files that have that file extension.

for f in `find . -type f | awk -F/ ‘{ print $NF; }’ | awk -F. ‘{ print $NF; }’ | sort -u` ; do echo  -n $f:; find . -type f -iname “*${f}” | wc -l;  done

Making Symlinks to a Directory Work in Dreamweaver CS5.5 on Snow Leopard: Hard Link Style

Written by Sean Ryan on . Posted in Uncategorized

NOTE: This post is about symlinks and hardlinks as they relate to Adobe Dreamweaver CS 5,5 running on Mac OS X 10.6+ but also applies to very earlier version of Dreamweaver.

ALSO NOTE: This technique totally works but be super careful. There is a reason links are treated in special way.

They work in every other IDE, but symlinks do not work in Dreamweaver. I’m sure there must be a reason, but I almost don’t care. I want them to work so I can deal with directory structures that use them.

Scroll down to the SOLUTION to bypass all my comentary.

In general, symlinks can result in circular dependencies that can really mess things up but then again, programmers write infinite loops sometimes and seem to resolve them, so what gives Dreamweaver?

I came across this issue when researching sencha touch and making my way through a webinar. The presenter recommended a symlink for linking to the main API and it clicked – how perfect. So I stopped and configured my directory structure the same way and then looked at it in Dreamweaver 🙁

Dreamweaver hated this and instead of showing me the directory’s content, it told me it couldn’t find an editor for the file. Ugh.

Hard Linking vs. Symlinking / Shortcuts

A symlink is like a shortcut in Windows without the terribleness of Windows. Windows adds .lnk to the shortcut and doing so prevents the usefulness of treating the shortcut as if it were the actual file or directory.

To create a symlink, run a command like the one below:

$> ln -s /Users/scoobydoo/lib/apache-commons/commons-lang-1.2-4.jar commons-lang.jar

This creates a symlink (notice the -s) to commons-lang-1.2-4.jar named commons-lang.jar. This allows me to swap out different versions of commons-lang yet always refer to it as commons-lang.jar. For the record, that’s probably a terrible idea, but you get my point.

Dreamweaver doesn’t like this. In fact, it’s quite hillarious what Dreamweaver actually does. If you open this link in Dreamweaver, it actually shows you – in a text file – the path to the linked file. Well, that is just cute. Useless, but cute.

SOLUTION

Hardlinks: A hardlink isn’t really a shortcut but rather a direct link to a file’s actual inode. Generally speaking hardlinks are not possible to directories, but Mac OSX allows it. Unfortunately it provides no means to actually make the link…big sad face.

With a hardlink, if you delete the “original” file, any hardlinks that were created still point to the inode, which means that the location in memory can still be accessed.  That’s because deleting a file really translates to “unlinking a file.” This is referred to as “awesome.”

Let’s try it out:

$> mkdir t

$> cd t

$> mkdir lib

$> touch original.txt

$> cd lib

$> ln ../original.txt copy.txt

$> cd ..

$> rm original.txt

$> cf lib

$> ls

You’ll still see copy.txt because copy.txt does not link to original.txt, it “points” to the inode that original.txt pointed to. Typically, this only works with files and not directories.

Dreamweaver is fine with hardlinks because hardlinks in a way, aren’t links, they are just files that point the same location as another filename.

The problem we are left with is how can we create a hardlink to a directory so that Dreamweaver won’t flip out?

Easy, write a tiny C program. For real.

Greg Miller wrote pretty cool article Exploring Leopard with DTrace: How to use DTrace for debugging and exploration that includes the code I’m about to show you.

Copy/paste this code into a text editor and save it as hard-linkd.c (or something else).

#include <unistd.h>
#include <stdio.h>
int
main(int argc, char *argv[])
{
   if (argc != 3)
      return 1;
   int ret = link(argv[1], argv[2]);
   if (ret != 0)
      perror("link");
   return ret;
}

To compile it:

$> gcc -o hard-linkd hard-linkd.c -Wall
$> cp hard-linkd /usr/local/bin

Now you can use hard-linkd to hard link to a directory and make Dreamweaver happy.

$> hard-linkd src-directory dest-directory

I did this. It works. All is right again.

 

SFTP Connection Problems from Dreamweaver: Cannot Make Connection to Host

Written by Sean Ryan on . Posted in Uncategorized

If you were once able to connect to your SFTP server from Dreamweaver but now suddenly you cannot and the error message is something useless like “An FTP Error Occurred – Cannot Make Connection to Host” then the likely cause is that the servers ssh host key changed.

Why?

In my case, our hosting company built us a new VM and when we were ready to start using it, they reassigned the same IPs from the old VM to the new VM. We took this approach instead of changing the DNS entries because it would be less disruptive to our clients.

The problem is the SSH host is different and therefore the SSH host key is different. You can verify this by opening your SSH client and connecting to the new server (with the same IP address or host name). When the SSH client sees that the host file is changed, it presents you with a message asking you to accept it. As always, once you accept it, it adds an entry to your known_hosts file located in .ssh/known_hosts if you’re on a Mac/*nix and somewhere else if you’re on Windows.

This enables all SSH clients to work fine with your new host…except Dreamweaver. Dreamweaver, as it turns out, maintains it’s own ssh_hosts file that needs to be updated and it WILL NOT tell you. It will simply “fail to connect” when it sees that the host keys don’t match and like a freshman programmer, gives you no reason as to why.

On Mac/*nix the file is located in:

/Users/user.name/Library/Application Support/Adobe/Dreamweaver CS5.5/en_US/Configuration/ssh_hosts

Or, if you’re using an old version of Dreamweaver somewhere in the Application Support folder. Look around, you’ll find it.

DELETE IT! Or, remove the offending entry, like I did.

All better. Hope this helps. I plan on submitting a bug to Adobe.

Struggling with Splash Screens for IOS Devices: Making HTML5 Apps Act as Native Apps

Written by Sean Ryan on . Posted in Uncategorized

Lately, I’ve found myself writing apps that run on mobile devices.  JQuery Mobile is a great way to get your feet wet, so that where I eased into it. After playing around with it, I’m a huge fan and am aware of it’s proper use / limitations. For the most part though, HTML5 can do some awesome things.

I’m a Mac guy so when I write JQuery Mobile apps, iOS devices are the first ones I test on. Since iOS supports some really neat HTML5 features, I set out to take advantage of them. In particular, the splash screen.

Make Your HTML App Look Native

You probably already know, that with the following two lines, you can make your HTML5 app look more like a native app on iOS.

<meta name=”apple-mobile-web-app-capable” content=”yes” />
<meta name=”apple-mobile-web-app-status-bar-style” content=”black” />

These meta tags only have an effect if the user “Adds To Home Screen” after entering your application, but it’s still cool.

When the user does save a link to your app on their Home Screen, the icon can be customized by supplying custom images with some more tags.

<link rel=”apple-touch-icon” sizes=”57×57″ href=”/images/icons/calzone-57×57.png” />
<link rel=”apple-touch-icon” sizes=”72×72″ href=”/images/icons/calzone-72×72.png” />
<link rel=”apple-touch-icon” sizes=”114×114″ href=”/images/icons/calzone-114×114.png” /> 

Apple uses the correct size icon for the particular device the user is on. 57 for iPhone non-retina display, 74 for iPads, and 114 for iPhone retina display.

Apple also provides a way to assign the splash screen too – except as of this writing, it doesn’t work and there is NO DOCUMENTATION anywhere that explains this.

The Fix: A Media Query

You still stack the apple-specific tags like above, but you add a media query to the iPad link to make the iPhone ignore it.

<link rel=”apple-touch-startup-image” href=”/images/startup/calzone-320×460.png” />

<link rel=”apple-touch-startup-image” sizes=”640×920″ href=”/images/startup/calzone-640×920.png” />

<link rel=”apple-touch-startup-image” sizes=”768×1004″ href=”/images/startup/calzone-768×1004.png” media=”screen and (min-device-width: 321px) and (max-device-width: 1024px) and (orientation:portrait)” />

The first two links satisfy the iPhone but without the media query on the third, the iPhone gets confused and decides it doesn’t want to play any more and shows the user nothing at all. Well, they do get a big white screen while your app loads but it’s not pretty.

The iPad appears to recognize the media query without a problem and uses the third link nicely. You can even specify the orientation. If you put the media query on the first two, the iPhones show nothing. Again though, if you remove the media query from the third, the iPhone show nothing – but the iPad works.

There’s really nothing wrong with the iPad (other than it’s hard to hold).

There you have it. Doing this will allow splash screens to display on the iPhones and iPads.

One problem I found is that the iPhone needs to the load the app one time before it will show the splash screen, but it works every time after that.

 

Resolving WinSSHD Connection Problem on Mac OSX 10.7 Lion

Written by Sean Ryan on . Posted in Uncategorized

If you’ve had problems connecting to servers over SSH after upgrading to Lion, you aren’t alone and thankfully, there’s a simple fix.

Problem

From the command line, the following command will initiate an SSH connection to some server on port 60001.

$> ssh user.name@someserver -p 60001

There is nothing wrong with this command. It works, unless the SSH server you are connecting to doesn’t recognize the terminal that is requested.

The error you get back isn’t terribly helpful if you aren’t sure how the SSH connection is formed. The terminal that you are using is sent along so that SSH knows how to interact with your SSH client. This comes the TERM environment variable.

In Snow Leopard, the requested terminal is xterm-color. In Lion, the requested terminal is xterm-color256.

You can verify this by echoing the TERM out:

$> echo $TERM

I discovered this by looking at the SSH server logs on the Windows box I was trying to connect to. I love reading server logs. So straight forward…

WinSSHD doesn’t recognize xterm-color256. At least mine doesn’t, and I just installed it on a couple of shiney new VMs. If you do the Google on this problem, lots of folks will tell you to just copy the terminal config files to the SSH server. Well, that’s not the recommended way of doing it. In fact, the makers of WinSSHD request that you send the unsupported terminal info to them and they’ll include support for it in their next release. How helpful.

Fix

Before running your connection command, set your TERM environment variable to xterm-color and you’ll be just fine.

$>TERM=xterm-color

Or, whatever syntax your shell requires.