theconsultant.net

One of things I occasionally do at work is to grab every url for a client’s domains/sites and open them up to eyeball them and see if anything obvious needs fixing.

First I go and copy a list of all the active domains, and clean it up with a “search and replace” script. I end up with a list of url’s, one per line.

After that I copy it all and go over to the Terminal and run a nice little script which I call “tab”. My current default browser then starts sprouting tabs galore.

Here’s the script:


#!/bin/bash
pbpaste | tr "\r" "\n" | xargs -n 1 open


How does it work?

pbpaste provides the contents of the clipboard to the command line (see pbcopy to put things into the clipboard). tr translates characters, in this case from one kind of line end (or return character) to another. An issue with pbcopy from what I can tell! Then the cleaned up clipboard gets pushed to xargs which take the command -n 1 open and builds one open per line of data being fed to it. Yes, xargs is very cool. The open command will then “open the URL in the default browser”.

I am sure this can all be done in Applescript or Automator.. but typing tab and return on the command line is the fastest and simplest for me!

If you want to use the script and are not sure how to take the shell code above and turn it into an actual script.. let me know and i’ll provide instructions (gee, another blog post!).

I spotted this trick on macosxhints.com: An easy way to run multiple instances of any program

Apple’s Developer Resources has a copy of the man page for open and explains it like this:

-n  Open a new instance of the application(s) even if one is already running.

So what can you do with it, and why?

I had no real use for it until this morning when I wanted to test the CPU load on Safari of a web site, without having to close all my windows and their tabs. So I fired up the terminal and did;


open -n /Applications/Safari.app


… and then there were two Safari icons in my Dock!

The MacOSXHints article warns that there is some danger having multiple copies of an application open, as they will all be trying to read/write to shared files like preferences.

Let me know if you have any cool uses for it!

I will only quote part of the announcement regarding the Workshop Tom and I are offering next weekend… all the details are on Tom’s site: Introduction to Mac course, in Ottawa, Ontario, on January 26th, 2008.

As you can guess from the course title, we will be doing an introduction to the Mac, from the outside in!

Some of the major applications which will be covered include; Mail, Safari, Address Book, iCal, iChat, and the iLife suite of applications. There will be time at the end to address specific questions, which we expect will arise!

As Tom says:

Now that the details are (finally) worked out, I can safely announce that Dave Rostenne and I are offering our first combined course for users who are new to Macs, or have just "switched". The course will take place over at the School of the Photographic Arts: Ottawa (SPAO), and you can find details on their special events page or in this printable PDF file.

When

Saturday, January 26th, 2008 from 1:00 PM to 4:00 PM, with an additional hour afterwards (4:00 PM to 5:00 PM) for questions and answers.

The cost and how to register

The cost is a very reasonable $79, and to register, you can either call (613) 562-3824 or email ADMIN@SPAO.CA. Register soon, because seating is limited to 20 people!

We hope to see you there!

Thanks to df for pointing out that Apple has posted release notes for AppleScript in Leopard.We can now ask if an application is running, without AppleScript launching it to find out. ;-)Some nice additions to running AppleScript on the Command Line:

• use # to comment out a line
• start the script with #!/usr/bin/osascript, and make it executable, will enable it to be run in the shell
• osadecompile is a command line script to display compiled scripts as text

Now osascript also supports additional arguments on the command line, so now you can run a script and provide strings for it to use. see the osascript man page for details, and an example. This feature was available in Tiger, I just never noticed until now!

StuffIT, that became Allume, that became digital river is becoming less and less relevant on Mac OS platform. Part of the reason for that, of course, is the policy of the manufacturer, that requires signing up, buying things, etc. It’s nearly impossible to find the free StuffIT expander, for those rare moments when you need it.

In any event, here is a direct link to the StuffIT download page. I had to give out a throw-away e-mail address to get it.

Select a word, do command-ctrl-d, and it invokes pop-up window with data from the dictionary. Thanks Tom!

Does anyone know how to merge multiple Keychains in Mac OS X?

I know I can copy items from one keychain to another, but that involves authenticating twice.

I tried going in and adding those other keychains to be part of my list, but they don’t stay. Frustrating.

Why am I doing this? I replaced my computer, and was not able to transfer my account at setup time, so I ended up with some old keychains that got copied over.

Suggestions, comments, rants?

All are welcome!

Dave

Platform independent endinanness check:

#include <stdio.h>
union foo
{
  char p[4];
  int k;
};

int main()
{
  int j;
  union foo bar;
  printf("$Id: endianness.c,v 1.1 2006/07/09 17:48:14 stany Exp stany $nChecks endianness of your platformn");
  printf("Bigendian platform (ie Mac OS X PPC) would return \"abcd\"n");
  printf("Littleendian platform (ie Linux x86) would return \"dcba\"n");
  printf("Your platform returned ");
  bar.k = 0x61626364;
  for(j=0; j<4 ; j++)
  {
  printf("%c",bar.p[j]);
  }

  printf("n");
  return 0;

}

Platform dependent tell me everything check:

/*
 * $Id: cpuid.c,v 1.2 2002/08/03 23:38:39 stany Exp stany $
 */

#include <mach-o/arch.h>
#include <stdio.h>

const char *byte_order_strings[]  = {
        "Unknown",
        "Little Endian",
        "Big Endian",
};

int main() {

  const NXArchInfo *p=NXGetLocalArchInfo();
  printf("$Id: cpuid.c,v 1.2 2002/08/03 23:38:39 stany Exp stany $ n");
  printf("Identifies Darwin CPU typen");
  printf("Name: %sn", p->name);
  printf("Description: %sn", p->description);
  printf("ByteOrder: %sn", byte_order_strings[p->byteorder]);
  printf("CPUtype: %dn", p->cputype);
  printf("CPUSubtype: %dnn", p->cpusubtype);
  printf("nFor scary explanation of what CPUSubtype and CPUtype stand for, nlook into /usr/include/mach/machine.hnn
ppc750t-tG3nppc7400t-tslower G4nppc7450t-tfaster G4nppc970t-tG5n");

return 0;

Purposefully oblique description, I know.

Basically there are two ways of not supporting a platform.

One way is to not support the architecture. If I compile something as ppc64, noone on a G3 or G4 CPU will be able to run it natively, nor will x86 folks be able to run it under Rosetta. I can try to be cute, and compile something for x86 arch, cutting off all PPC folks. I can compile something optimized for PPC7400 CPU (G4). G5 and G4 systems will run it and G3s will not (This is exactly what Apple did with iMovie and iDVD in iLife ‘06). Lastly, I can compile something in one of the “depreciated” formats, potentially for Classic, and cut off x86 folks, and annoy all PPC folks who would now have to start Classic to run my creation. Oh, the choices.

The other way is to restrict things by the configuration, and check during runtime.

Procedure for checking that the architecture you are using is supported by the application.

bash$ cd Example_App.app/Contents/MacOS
bash$ file Example_App
Example_App: Mach-O fat file with 2 architectures
Example_App (for architecture ppc):  Mach-O executable ppc
Example_App (for architecture i386): Mach-O executable i386

or

bash$ cd Other_Example/Contents/MacOS
bash$ file Other_Example
Other_Example: header for PowerPC PEF executable

Step 2a) If application is Mach-O, then you can use lipo to see if it’s compiled as a generic or as a platform specific:

bash$ lipo -detailed_info Example_App
Fat header in: Example_App
fat_magic 0xcafebabe
nfat_arch 2
architecture ppc
    cputype CPU_TYPE_POWERPC
    cpusubtype CPU_SUBTYPE_POWERPC_ALL
    offset 4096
    size 23388
    align 2^12 (4096)
architecture i386
    cputype CPU_TYPE_I386
    cpusubtype CPU_SUBTYPE_I386_ALL
    offset 28672
    size 26976
    align 2^12 (4096)

If you see CPU_SUBTYPE_POWERPC_ALL, application is compiled for all PowerPC platforms, from G3 to G5.

What you do not want to see on a G3 or G4 system is:

bash$ lipo -detailed_info Example_App
Fat header in: Example_App
fat_magic 0xcafebabe
nfat_arch 1
architecture ppc64
    cputype CPU_TYPE_POWERPC64
    cpusubtype CPU_SUBTYPE_POWERPC_ALL
    offset 28672
    size 8488
    align 2^12 (4096)

Then you need a 64 bit platform, which amounts to G5 of various speeds.

It is possible that the application is in Mach-o format, but not in fat format.
otool -h -v will decode the mach header, and tell you what cpu is required:

Step 2b) If application is PEF (Preferred Executable Format) or CFM (Code Fragment Manager) things might be harder.  I've not yet encountered a CFM or PEF app that would not run on PPC platform in one way or another, so this section needs further expantion. 

In case of a runtime check, most commonly it is the platform architecture that is checked. 

Some Apple professional software has something like this in AppleSampleProApp.app/Contents/Info.plist

        AELMinimumOSVersion
        10.4.4
        AELMinimumProKitVersion
        576
        AELMinimumQuickTimeVersion
        7.0.4
        ALEPlatform_PPC
        
                AELRequiredCPUType
                G4
        
        CFBundleDevelopmentRegion
        English

Getting rid of

        ALEPlatform_PPC
        
                AELRequiredCPUType
                G4
        

tends to get the app to run under G3.

Lastly, if application says something similar to “Platform POWERBOOK4,1 Unsupported”, maybe running strings on SampleApplication/Contents/MacOS/SampleApplication combined with grep -i powerbook can reveal something.

bash$ strings SampleApplication | grep POWER
POWERBOOK5
POWERBOOK6
-
 POWERBOOK6,3
POWERMAC7
POWERMAC9,1
POWERMAC3,6
           POWERMAC11,2
-
 POWERMAC11,1

So if you want to run this application on 500Mhz iBook G3 for some reason (hi, dAVE), it might make sense to fire up a hexeditor, and change one of the “allowed” arches to match yours.

For example to this:

bash$ strings SampleApplication | grep POWER
POWERBOOK4
POWERBOOK6
-
 POWERBOOK6,3
POWERMAC7
POWERMAC9,1
POWERMAC3,6
           POWERMAC11,2
-
 POWERMAC11,1

But don’t mind me. I am just rambling.

If you did a clean install of MacOS X 10.4, part of out of box experience is filling out a bunch of things about what your name and address is, where you work, what your e-mail is, etc.

CMD-Q bypasses that screen, and continues as normal without asking for irrelevant information.

Thanks to Jon Rentzsch for the hint.