I noticed that mdfind has become much more useful now in Leopard. For instance, you can run Finder saved searches from the command line. As an example...
mdfind -s "Pet Pics"
...will show the results of saved search called "Pet Pics." It actually looks for the saved search in ~/Library/Saved Searches, but you can give it a full file path if you wish. This means you can build up your queries visually using Finder, then easily use them in scripts. Also, you can give mdfind queries in the same language that you'd use in Spotlight:
mdfind -interpret "pet kind:image"
As usual, check man mdfind page for more info, but note that the man page is not consistent with all that mdfind can do (eg, it doesn't mention -s in the man page).
A lot of people have complained about ssh being slow when connecting to others hosts when you give a hostname instead of an IP address. The problem is obviously related to DNS name resolution. At my workplace, this might also have to do with the fact that we are using the .local domain for our network (which was decided long before Apple used it for Rendezvous).
However, I did not want to care where the problem really comes from, so I wrote a script that works around ssh's slow name resolution. It resolves the hostname using the host(1) utility, and calls ssh using the resulting IP address. Even after extensive web searching, I did not find out why ssh is only slow for some people (depending on various network and ssh config settings), so I do not really know whom this hint applies to. But it still might be worth a try if you think your ssh is slow when connecting, and you've already checked your DNS and ssh settings.
Put the following script into some directory in your PATH, for instance /usr/local/bin, name it ssh, make it executable by running chmod +x /usr/local/bin/ssh, and there you go.
if [ "$destuser" = "$desthost" ]
exec /usr/bin/ssh "$dest" "$@"
There is a little bug I did not care to fix: The script assumes that your first argument will always be hostname or user@hostname. Any ssh options or commands must be given afterwards.
Given what I do for Macworld, I take a lot of screenshots. Sometimes I need to take those shots remotely -- for instance, to grab a screnshot of the login window, you must connect to a logged-out Mac via ssh, then use the screencapture command, as described in this older hint.
With 10.5, though, the rules have changed, as described in the man pages for screencapture:
To capture screen content while logged in via ssh, you must launch screencapture in the same mach bootstrap hierarchy as loginwindow:
PID=pid of loginwindow
sudo launchctl bsexec $PID screencapture [options]
So to take a screen capture, you need to first get the PID of the loginwindow, which you can do via ps ax | grep [l]oginwindow in Terminal. The PID is the first number in the output; assuming it was 935, you'd then execute sudo launchctl bsexec 935 screencapture, followed by your desired screencapture options.
Being the lazy sort, this seemed like too much work, so I came up with the following solution.
In my search for the nicest text editor, I have kept returning to Vim. I would use it for a little while, and then I would lose interest because something or another wasn't quite working the way I liked. This last time, I manged to solve all of those things, and I even found some extra features I didn't know about. Right now, I am using Vim.app (native GUI), version 7.1.161, with all the latest patches. Even better, I did not have to puzzle over configuration settings or anything to compile it - I just entered a command, and everything else relating to compiling was done automatically. How is this possible, you ask? All will be revealed...
The new X11.app Version 2.0 introduced with Leopard has a lot of bugs. Some of the issues (and workarounds) are discussed in this excellent thread over on the macosxhints forum site. Also, the people from x.org have released updated X11-libraries and an updated Xquartz server; you can read about them here.
[robg adds: The thread on the macosxhints forums contains a ton of information culled from various sources about what works and what doesn't work, and how you can fix some (but not all) of the issues. ]
I see a lot of hints, such as the one to remove 10.5's translucent menu bar, that tell you to restart your computer for the changes to take effect. However, you only really need to restart the WindowServer, which handles the graphical part of the system. I just do that in Terminal, with this command:
sudo killall -HUP WindowServer
Warning: All your opened programs will quit immediately! This is like a restart, but of only the graphical part of the system. Quit your open programs first! You have been warned. Here's what happens:
kill is a program to send signals (terminate or just "signals") to Unix programs -- and in OS X, all programs are Unix programs. killall is the same, but you can use the name of the program instead of its process ID (pid). The dark side is that if you have more than one program with the same name, all programs will receive the kill signal.
-HUP is a signal that usually says to the process that configuration files are changed and the process must be restarted.
WindowServer is the program that manages the graphical side of OS X.
You can see all the available signals by typing kill -l, but play with care!
[robg adds: A comment on the queue site notes that this may be useful for those times when the GUI locks up, if you're still able to connect via ssh -- try a restart of the window server before forcing a full reboot.]
Note: This hint is not correct. However, there's good information in the comments about why, along with workarounds. Please do not implement the hint, but if you're looking for alternatives, check the comments.
After much frustration, it seems that I have found a bug in 10.5. When doing unix scripting, it's useful to be able to do something like the following:
However, when using /bin/sh as the shell, echo -n no longer works. This is pretty much the most basic of basics in the unix world, and it just irks me that it's giving me grief. You can, of course, fix it by changing your shell to bash instead of sh, ala:
Unfortunately, that only affects you. If there are other scripts you are running that you don't want to modify yourself, then you need to do something more drastic.
I'm a big fan of locate, even in this day and age of Spotlight; it's a super-fast way to find things in Terminal (with the downside that it needs updates to remain current, as it's a static index of file names). By default in 10.5, locate won't find files on Time Machine drives -- this is probably a good thing, as it greatly increases both the size of the database and the number of returned matches.
However, I was working on a project, and I wanted this information in locate. The solution is pretty simple: you need to edit /usr/libexec/locate.updatedb (with sudo). Look for this line:
For all you Leopard users out there, here's a handy tip on how to use Quick Look from the command line.
Leopard ships with a command called qlmanage. The -p option shows a preview of the file passed to the command. In the terminal, type the following:
qlmanage -p thefile
As you'll see, it also generates a ton of text output when run. You can prevent this by creating the following shell script:
qlmanage -p "$@" >& /dev/null &
The >& /dev/null prevents output from displaying, and the final & runs the process in the background so a new prompt displays in Terminal. Save this script as an executable file and store it somewhere in your PATH (I stored mine in a home bin folder used for custom-made scripts). I recommend naming it something short like ql.
When using the script, you can close the Quick Look window with the mouse (the conventional way), or close it in Terminal by getting the pid from the ps command and using kill pid#.
[robg adds: This hint originally appeared on the author's blog; check there for any udpates. I actually prefer the script without the last &, as you can then close the Quick Look window with a Control-C (but you cannot work on anything else in that same window until you do so, of course).]
Quartz-wm no longer keeps windows from sliding under the menu bar at the top of the window. You can now stuff the title bar of the window up under the menu bar of the screen and loose the ability to move the window back out again. Grrr.
The solution? Run a different window manager (the venerable twm comes with Apple's X11) and set the title bar height larger than the menu bar height.