patrick schneider

Google claims that "searches are NOT case sensitive". However, I have empirical evidence to believe otherwise.

I was recently seeing how well a fairly long, extremely specific blog title was indexed by Google. My general thinking has been that niche titles will appear high in search indices when Googled word-for-word. That is, even without surrounding the query in quotation marks, I would expect that a Google search for:

moving maven repository metadata files

…would pull up my blog posting, simply because it matches the title exactly. Here are the surprising results:

As you can see, the upper-case search returns a link to my blog as the second entry. The lower-case search returns a completely different page. To be fair, I recently upgraded my blog from MovableType to WordPress. In doing so, I changed the URL structure. The link that Google found with the capitalized words has a Permanent Redirect (HTTP 301 status code).

What is going on here? I can think of only two possible explanations:

• Google is case sensitive, or at least has recently become so, and their documentation is incorrect.
• Google is not case sensitive. The URL change, regardless of the HTTP 301 Permanent Redirect, has caused the index ranking of the page to change. Perhaps the capitalized version of the query was sent to a server that did not have the updated index.

In either case, the results are confusing. I would expect that a Google search behave as per their documentation. Maybe someone from Google could trackback and let me know

I was getting this error when attempting to restore a checkpointed and journaled backup of Perforce:

[perforce@source restore]$ p4d -r /data/p4root -jr checkpoint.659 journal
Perforce db files in '/data/p4root' will be created if missing...
Recovering from checkpoint.659...
Perforce server error:
        open for read: checkpoint.659: No such file or directory
[perforce@source restore]$ ls -lah
total 5.8G
drwxrw-rw-  2 perforce perforce 4.0K Jul 24 14:28 .
drwx------  5 perforce perforce 4.0K Jul 24 14:11 ..
-r--r--r--  1 perforce perforce 5.8G Jul 24 14:16 checkpoint.659
-rw-rw-rw-  1 perforce perforce 4.1K Jul 24 14:28 journal

As it turns out, the -jr flag expects absolute paths for the names of these files. Once I made this switch, everything worked fine.

We have an internal Maven repository at my company. This allows us to have an official repo of “approved” artifacts that developers can use. (For example, GPL’ed projects might not be legal to use for our purposes.)

Anyway, we use a script to pull down artifacts from the official Maven repository (http://repo1.maven.org/maven2/). However, the script does not overwrite, and sometimes metadata files are duplicated. The resulting directory listing for an artifact might look like this:

$ ls -1
1.0
1.0-rc1
maven-metadata.xml
maven-metadata.xml.1
maven-metadata.md5
maven-metadata.md5.1
maven-metadata.sha1
maven-metadata.sha1.1

Obviously fixing the script to overwrite would solve the problem of these “.1″ files. But, I was curious as to how I could easily move the “.1″ files to their appropriately named counterparts. My newfound love for xargs made me think that I could do this in one cool command-line statement. Here’s what I came up with:

ls -1 *.1 | sed 's/.1//' | xargs -i mv {}.1 {}

Broken down:

1. I pass the “-1″ flag to ls, which tells it to print each item on a separate line. I filter ls to only show files that match the “*.1″ pattern.

2. Each line of output from ls is piped into sed, which just simply substitutes nothing for “.1″. We have constructed the desired file name.

3. Now, I can pipe each of these desired file names into xargs, and use the -i flag to substitute the standard input to the {} token.

Maybe there’s a completely obvious way to do this that I haven’t run across, but, like I said — newly discovered love for xargs, and everything looks like it can be piped into it

Unix and its chain-commands-through-pipes always comes through. Recently I had a need to do some recursive permission changes. The permissions needed to be changed carefully, though: I needed files to have permissions of 664 (-rw-rw-r–) and directories to have permissions of 2775 (drwxrwsr-x). (The “2″ sets the sticky bit for the group.) Anyway, the find command allows you to find directories and files easily with the -type flag. And, as usual, xargs helps out a ton.

So, changing permissions for all directories below the current directory:

$ find . -type d | xargs chmod 2775

Changing permissions for all files below the current directory:

$ find . -type f | xargs chmod 664

The ‘xargs’ command is invaluable. It appends the incoming data from the pipe (in this case, the line-by-line results from the ‘find’ command) to the end of the command. So the above commands get translated to:

chmod 664 ./some/file/or/directory

…for every file and/or directory. Obviously you should change the permissions to whatever is appropriate in your situation.