OS X Shell

Oct 13 2011

rsync

This is a command coming from the *NIX world I found to be useful for maintaining a backup for important software. It works either on a single computer or with two computers. The details can be found in the man page for the command. I’d like to thank Mike Doob from the MUUG for reminding me about this command.

The simplest way to use the command is “rsync <file list or directory 1> <file list or directory 2>”. All it does is copy files from area 1 to area 2 if they are newer than those in area 2.

To copy files from one computer to another the account name and computer name are needed. An example would be “rsync sbalmer@microsoft.com:/Secret_Meetings_To_Control_The_World.txt timc@apple.com:/Sunday_Coffee_With_Friends.text”. Incidentally, since they are different computers, passwords are needed.

I tried this a number of years ago with 10.2 and FreeNAS (FreeBSD) and apparently that was the only configuration which (according to everything I read on the net) would not work.

By BlankMike • Cross Platform, Macintosh, OS X, OS X Shell • 0 • Tags:

Jun 5 2011

How to automatically mount an NFS drive (UNIX network) on OS X

This article is a variation/enhancement to a post I found at http://sourceforge.net/apps/phpbb/freenas/viewtopic.php?f=49&t=9289 for a FreeNAS server. Of course purely Mac folks would likely want to stick with the AFP protocol. In terms of generalities the NFS server does not necessarily have to be running FreeNAS. It just has to work. FreeNAS is basically a “Swiss Army Knife” of external storage. I find it does a lot of things very easily. It doesn’t work on all machines (I’ve had a 60% success rate) but when it works, it works well.

The question of why anyone would want to run storage of any sort connected to a network drive over their LAN is simple. When people upgrade to new machines they frequently have the old machine sitting around doing nothing. In the case of some Intel Macs (or PCs) they can just throw in a HUGE amount of storage for the price of adding a little amount of storage to a current Mac. In my case I have access to free/cheap old PCs and parts. This allows me to use these machines to experiment and learn for free. Since we were looking at a problem regarding NFS at the lab this is exactly what I did.

First off the person doing this needs access to a working NFS machine. As I suggested before, FreeNAS isn’t necessary but is easy to install and configure. This step is one I will leave to the reader.

Second, go into a terminal and edit the /etc/auto_master file. The reader will have to use the sudo command to do so since it is a system file. If the reader is paranoid like me they should back up the file first so they can recover if there are any mistakes. The author of the article I used as reference wanted to install things under the /home directory. This is fine. Personally I wanted to see if I could put things in a different location. In this case I wanted them in /nfs. Rather than modify the existing line I added the following line…

/nfs                    auto_nfs        -nobrowse

The first part says where to mount the drive. The second is another file with further instructions. I have no idea what the third part does, but it was made clear it was to be there.

Third was to create the auto_nfs file. In this case I copied the auto_home file to auto_nfs. At that point I’ll skip ahead an hour and a half to the point where I replaced the last line in the file with the following line… ;-)

server 192.168.X.Y:/mnt/main           # Use directory service

First there has to be the name of a directory. In this case the drive will be mounted under /nfs/server. I gather it is set up this way because there is the possibility someone may want to mount multiple machines this way. Then is the location of the NFS device. The 192.168 part refers to a non-internet LAN. The reader should replace “X” and “Y” with the detailed location of the NFS server. The /mnt/main is the location on the server where the area to mount is located. The final part is a coment left over from the previous file and sort of kind of makes sense.

Apart from Step 5 everything is the same as in the reference article. Essentially all the reader has to do is type “sudo automount -vc”, test things, and they are done.

The down side is it appears to be mounted as read only. I’ll post an update when I figure out how to make it read and write. It may just be a permissions issue but it may be something else.

As a final thing I thought it would be a good idea to have quicker access to the device. I made a symbolic link to the mounted directory in my home area. This can be done in a number of ways. I just went into the terminal and typed “ln -s /nfs nfs”. So now I don’t have to go hunting through the whole computer to find the directory.

Considering I can access things with less trouble through afp, I’m not sure I’ll keep this available on the Mac.

By BlankMike • Cross Platform, Disk Images, Disk Storage, Hardware, Macintosh, OS X, OS X Shell, Software, Tips • 0 • Tags: , , ,

Mar 30 2011

BASH reference

As is one can tell from the dates on my posts, I spent a while tracking this one down. The original link is in a now inaccessible e-mail account so I went out and located it directly on the web. The date of the manual is in 2010 so it looks as though it is being kept relatively up to date.

For those interested in why I am posting this particular link, the reason is simple. BASH is the shell used by OS X and one of the shells used by Linux/BSD. It ties in with the shell programming articles I’ve written recently. This link is to the reference guide/manual for the shell. All those Apple// folks who ended up with Macs can now start programming again. ;-)

http://www.gnu.org/software/bash/manual/

Incidentally to view the manual on-line the second of the first group of links is the best place to start.

By BlankMike • Cross Platform, Documentation, Manuals, OS X Shell, Programming • 0 • Tags: ,

Mar 15 2011

Shell script example for OS X

Almost any series of commands which can be run in the shell can be run from a shell script. Tying in some of the last few posts I published here this is an example.

Let’s say I wanted to run the gedit editor from the shell rather than from the dock/GUI… I would first have to locate the executable program. I happen to know it is installed in “/Applications/gedit.app/Contents/MacOS/gedit“. By running this program the gedit editor will start. Since it was intended to be started from a GUI there is some whining by the program itself, but it works.

The next thing is to put the command into a file. There are several ways to do this. The editors I discussed in an earlier article will do. There are also a number of UNIX tricks to do the same thing without using an editor. Each is equally valid as long as the task is done. In my case I used pico and stored the file in my bin directory under the name gedit.

Now for a bit of UNIX magic… A file is not a program until the operating system knows it is a program. In this case typing “chmod 755 gedit” will do the trick. (Geek stuff) I used 755 instead of 700 because I wasn’t sure if 700 would work. By typing gedit from the command line the gedit editor will now run (as long as the script location is in the $PATH).

Lastly, there is a bit of icing on the cake… If I wanted to edit a particular file it would be nice to be able to specify it. As it is right now the script will only start the editor but not open or edit a particular file. The trick here is to go to the end of the line and add “ %1“. Note there is a space before the percentage sign. This will pass along the name of the file to the original program. After saving the file everything works as planned. As an added bonus there is no need to perform another chmod on the file.

By BlankMike • Macintosh, OS X, OS X Shell, Programming • 0 • Tags: ,

Mar 7 2011

Faster Web Access: A simple method

This is largely a repeat of an article in an earlier issue of the magazine. It works across all forms of *NIX (including OS X) and in a limited way Windows as well. Most professional *NIX people don’t recommend it. The reasons escape me at the moment.

One thought some network analysts had a couple of years ago as to the slow loading of web pages was due to mis-configured or slow ad servers. Visiting some pages with numerous popups and ads on occasion will seem to confirm this. Compare the some times five minute wait to how fast a simple HTML page with no graphics or ads takes and the difference is immense. I decided to see if the fault indeed belong to the ad servers. After some basic research I came up with a method to test the idea.

In the *NIX world there is a system file (/etc/hosts) which tells the computer where a particular URL is located. Additionally there is a “magic” IP address (127.0.0.1) which points to the computer currently being used. Combining this knowledge with a list of third party sites which frequently appear while my machine waits for something to load, resulted in an addition of about two dozen lines to the hosts file. Sure enough the speed of access to the core information of the web pages improved dramatically. The down side is there are segments of many web pages with “broken picture” icons.

For those who wish to try it, the syntax of the lines in the file are the IP (127.0.0.1), followed by a <Tab> or a number of spaces, finally by a list of domains separated by a single space. For simplicity I try to keep related domains on the same line and have a separate line for unrelated domains. Lines with the number sign (#) in front are comments. I suggest keeping a backup of the original file in case it needs to be restored. There are sample hosts file on the net. I advise against using them for three reasons.

  1. The speed will improve after about half a dozen domains are added to the file.
  2. There are thousands of domains in these lists. Some may no longer be up. This may slow down the machine even more.
  3. Most of these files were written for Windows and have a slightly different syntax.

With a small number of domains in the list I have not noticed many problems for the last year or so.

By BlankMike • Macintosh, OS X Shell, Programming • 0 • Tags:

Mar 5 2011

Terminal Tips: History and Auto-completion

These tips can be used with the OS X terminal, iTerm, and most Linux shells. I have also verified the history works with the Windows “DOS Prompt”. It’s nice when things work out in a consistent cross-platform way. ;-)

The history feature is useful when a programmer wishes to perform similar commands over again. In the past the process used to be more complex. Now it’s as simple as using the up arrow key. The down arrow key works to go the other direction. Many of those just getting familiar with the various terminal or shell commands will at first find this feature somewhat dubious. Here is a situation where the history feature really shines. Picture writing a program for a couple of hours and saving it. When run it has a syntax error. By using the history the programmer can save keystrokes to get back to where they were before. A second example would be a long command with a mistake on the line. Not realising the mistake the programmer presses the <Enter> key. Naturally the program doesn’t do what was expected. The programmer can use the history to recall the previous command and figure out where the problem was, then correct it.

Using auto-completion falls into a similar category in terms of usefulness. At first the novice shell user may not find a use for it. Eventually they will come to rely on it. The auto-completion searches the $PATH system variable I mentioned in an earlier article to match a file or command which is partially typed on the command line. For example let’s say the programmer wants to view the contents of their Desktop directory. Naturally they would use the ls command to do so. The whole command would be ls Desktop. Instead of typing the whole thing the programmer could type ls De<Tab>. This will fill out the command correctly so they can then press the <Enter> key. The reason they would have to go as far as De instead of D is because there is another directory called Documents. In certain shells the auto-complete would cycle through the possibilities. In others it will not. It is best to assume it won’t.

By BlankMike • Macintosh, OS X Shell, Programming • 0 • Tags:

Mar 2 2011

Mac Terminal tip: Adding a directory to the $PATH environment variable

The Mac has a unique way of setting up its $PATH variable. These are the locations the BSD portion of OS X looks at to find programs to run. In this case the list of paths can be found in the file /etc/paths. To edit it the administrator needs to sudo their favourite editor since the file itself is owned by root. For example “sudo pico /etc/paths”.

This is useful for the programmer who wants to have their programs accessible anywhere in the terminal. In my case I added “~/bin” to the end of the file. This allows any user to create a program or script in their own “bin” directory.

As someone who has done this in Linux I can say it is a whole lot easier to do this in OS X.

By BlankMike • Macintosh, OS X Shell, Programming, Tips • 0 • Tags: , , ,

Mar 1 2011

Alternative Software: iTerm

Programmers are always looking for tools to make things easier. The Terminal program included with OS X is adequate. This alternative makes things a little less spartan. According to the documentation this is an active project where the author implements features from other shells. One thing I find useful is the use of the scrollwheel as the middle mouse button for copy and pasting selected text. It also uses PC (Linux) keybindings such as <Home> (beginning of the line) and <End> (end of the line). What impressed me the most was the way I was able to make changes to the appearance and save them for next time.

To be fair, I’ve only used it twice. As someone who programs shell scripts, I was satisfied at the difference.

This program can be found at http://iterm.sourceforge.net.

By BlankMike • Apps, Emulation, Freeware, Macintosh, OS X Shell, Programming, Software • 0 • Tags: ,