Root is the uber system account. Although handy at times (for example when installing applications), it’s generally recommended that root not be used as your everyday login. What follows are some options for working as root.

If you need to run a command as root, you can use the sudo command. For example, to run the script for daily system maintenance, you can run this command (the $represent the terminal prompt):

$ sudo periodic daily

Now that’s all well and good, however, it’s generally applicable only for one command. What if you are in a terminal and want to login as root to do some larger scale maintenance or system work? Try this:

$ sudo -s

This command will enable the root account and update your prompt as shown in the figure below:

The above screenshot assumes you are using the bash shell and have admin rights on the account you are logged in with. The $ typically represents a user account whereas # represents root.

The last option is to create/enable a root account, thus you can login (when restarting/rebooting) as root. This approach offers the most flexibility and power, however, use with caution as there are no limits to what (damage) you can do.

Root account option #1: Enter the following from a terminal:

$ dsenableroot

You’ll be prompted for your (current) password, as well as the new root password.

Root account, option #2: Enter the following from a terminal:

$ sudo passwd

You’ll be prompted for the same series of passwords as above.

Root account, option #3: Follow the steps below:

- Start the Directory Utility application (/Applications/Utilities/Directory Utility)
- Click the lock icon in the lower left corner (to unlock it)
- From the Edit menu (across the top of screen), select Enable Root User

To wrap up this post I was planning to show you how the login window changes when a root account is enabled. Unlike other accounts on your system where a name is typically displayed as one of the login options, the root account is not listed as one of the options (for security reasons).

However, getting a screenshot of the login screen is a considerable feat. This is a great segue to a post coming next week where I’ll show the tricks that I tried for capturing the elusive login screen and I will pose an intriguing challenge for you…

If you are interested in working with the next beta of Dashcode, although there is no public announcement of the beta, it is available, read on for the details…

If you are not familiar with Dashcode, it’s a development tool created by Apple for building Dashboard widgets. The 1.0x release was bundled with Leopard. Dashcode is an impressive application, with drag-n-drop support and a no-coding option for creating a widget. Of course, as with any “no coding required” statement there is the unstated disclaimer that there are limitations on how far you can take a widget without digging into some code. And on that note, Dashcode offers excellent support for both writing and debugging code that make up a widget (CSS, HTML and JavaScript).

To give you an idea of what you can do with Dashcode, the widget below is an RSS feed of this blog that was created with version 1.0x.

You can try Dashcode 1.0 if you are running Leopard by installing the developer tools on the Leopard install DVD.

Interested to try the 2.0 Beta? There isn’t a download solely for Dashcode, however, if you download the iPhone SDK, Dashcode is one of many tools included in the download. If you do not have an Apple ID, follow the link near the bottom of this page to download the iPhone SDK, where you’ll find an option to create an ID.

Important note: if you import a 1.0 project into the beta, be aware that you might be able to work in the project with 1.0 if you save the project. To get around this, save any imported project with a new name (and/or location). An additional suggestion is to install the iPhone SDK in a different directory than the default /Developer. I opted to install the beta into /Developer/Beta such that I can use both versions of the tools.

In a screencast to follow, I’ll show you how I created the widget above with Dashcode 1.0.

I continue to find the Preview application to be a handy little tool. It’s not that Preview supports an enormous feature set for working with images, as much as each time over the last few months that I’ve look to the Previewer to help me out, it did.

The first time this came about I simply needed to resize an image to post on this blog – from the Tools menu, click Adjust Size and save the file, that’s it, done (and of course it can preserve the aspect ratio). My most recent encounter was when I needed to convert a file type from JPG to GIF. Again, a few clicks and it’s done – open an image, from the file menu choose the Save As option and from the dialog box select the image type. The figure below shows the supported file types; notice you can even save an image as a PDF.

By no means a full-fledged image editing program, and never intended to be, Previewer is still much more than its name suggests.

Google App Engine provides an opportunity to leverage Google’s infrastructure for server side web applications. The platform is built on a Python runtime, includes persistent storage as well as the capability to integrate with existing Google applications (think Google Maps, Gmail…).

The App Engine SDK is an open source project that is hosted on Google code, you can can access the project here. A download of the SDK is available for Mac here.

The App Engine SDK includes a web-server application that provides a means to emulate the App Engine services from within a local development environment. Once deployed, applications can be hosted on the domain, or your own domain.

The video below is a good introduction to Google App Engine from a recent CampFire One event:

One of the more intriguing aspects to services like the Google App Engine is that you focus on the application, not the hosting/scaling. Should you build a killer app, your focus still lies on the application itself, not on how to massively scale (which would be a good problem to have). From the App Engine homepage

This is a PREVIEW RELEASE of Google App Engine. For now, account registrations are limited to the first 10,000 developers, and applications are restricted to the free account limits.

Hurry and give it a go…

One of the defining concepts of working on a Mac is that things (usually) work just as you think they should. This is the culmination of good design translated into working code. The short video that follows is an example demonstrating how easy and intuitive it is to change the icon for an application. Believe it or not, it” onclick=”return TrackClick(”,’javascript%3AlynkVideoPop%28719%2C’)”s as simple as copy/paste.

This is a great trick to have up your sleeve when working with development tools that create a default icon, for example the Script Editor. With this approach you can quickly change an icon to reflect that something visually represents what the application does. And to help, do a quick search on Google for Mac OS X icons and you” onclick=”return TrackClick(”,’javascript%3AlynkVideoPop%28719%2C’)”ll be amused for hours…

For some reason I prefer to have system files (hidden by default) shown in Finder (must be the Unix in my system from grad school). With that said, there are times when it would be nice to have these same files out of sight when working with a cluttered folder. After having thought many times about writing a short script to toggle hidden files on/off, I finally took a few minutes to crank out the code below:

Script Editor Click to paste code into the Script Editor

--  Toggle Finder hidden file status
  -- Get current value
  set toggle to do shell script "defaults read AppleShowAllFiles"

  -- Toggle it
  if toggle = "ON" then
    do shell script "defaults write AppleShowAllFiles OFF"
    do shell script "defaults write AppleShowAllFiles ON
  end if

  -- Restart Finder
  tell application "Finder" to quit
  delay 0.5 -- If you have problems, you can tweak the delay
  tell application "Finder" to launch
on error

  display dialog "Unable to toggle bit status." buttons {"Better luck next time"} 
    with icon caution with title "Error"
end try

Notice the reference to delay – if you have problems with the scripting not running properly, you can experiment with a longer delay. There is minimal error handling, essentially just trapping errors and displaying the message below:

I prefer to save AppleScript code as an application, create an icon that serves as a reminder of what the script does, and drag/drop the application onto the Finder toolbar. You can see a screenshot below what my toolbar looks like (the icon for this script is the blue & white Finder image).

And speaking of icons, in an upcoming tip I’ll show you how easy it is to change an application icon on a Mac.