Shell Command on Login

[simplebeep]

What is the best way to run a terminal command when logging in? And by “best” I mean “fastest.” I’ve been encapsulating my commands in an Applescript, but it’s terribly slow to load, and I’m hoping there’s some UNIX back-end I can use to speed things up.

Specifically, I want to run a shell script that I wrote. It decrypts some folders inside my Home directory so I can use them (this part works seamlessly, I just need it to auto-run itself).

Thanks!

 

[angelwatt]

Check out this Apple Developer page: System Startup Programming Topics: Customizing Login and Logout

 

[Lokrado]

i'm curious as to how you encrypted these folders.
moreover why don't you just use filevault to encrypt your entire home folder - seamlessly.

 

[phatqao]

i know this isn't exactly what you're looking for, but terminal has an option to run a script when it's launched. you could set terminal to launch at login, and then your script would run once terminal opened. just a thought.

 

[larkost]

There are two ways of doing it:

1) put the commands in a file, name it something.command. Make the file executable (chmod +x path/to/file). In the Users control panel add it to your startup items. This will start up terminal, and run it in there.

2) Create your command file, name it what you like. Create a LaunchAgent file and put it in ~/Library/LaunchAgents (you will probably have to create this folder). Make sure your LaunchAgent plist file points to your command file. This will run very early in your login, and will not open any windows.

 

[simplebeep]

Thanks everybody for your helpful input. What I ended up doing was using a LaunchAgent, since it seems to be the most Mac OS-friendly way. It’s not user-friendly at all, but then again, neither is my system of encryption; it’s okay for me, since I spend the effort automating it once and forget about it for months/years.

@Angelwatt, your link was most helpful, as I never would have known where to look for all that technical info. If you’re reading this thread, and want to automate stuff upon login, you’ll want to use LaunchAgents. For a thorough explanation, first read this article, Launchd in Depth. Then, to see what all your options are, take a look at man launchd.plist. The reason I didn’t just save my script as something.command and put it in Login Items is that it would have opened up in Terminal, which is more clutter than it’s worth. Cookies, though, to @larkost for noting both ways!

If you’re interested, here’s the LaunchAgent plist I used to make the task work. (This is in “classic” NeXT format for readability; you should be able to save this in a text file and convert it to XML format with Property List Editor):

{
	Label = "com.eightt.startupitems";
	Program = "/Users/simplebeep/Library/Miscellaneous/startupitems";
	ProgramArguments = (
		startupitems,
	);
	RunAtLoad = YES;
	KeepAlive = NO;
}

I saved this in ~/Library/LaunchAgents as com.eightt.startupitems.plist. It’s important that this be within your home folder, or else it will get run when you start your computer up, not when you log in.

Anyway, as you may have guessed, /Users/simplebeep/Library/Miscellaneous/startupitems is my shell script that does the decrypting, and then it opens some of my login items that are dependent on the decrypted folders being in place. I’ll explain how that all goes down in my next post.

 

[simplebeep]

Okay, @lokrado, here’s your answer. The reason I don’t use FileVault is that it’s too… monolithic. It’s all-or-nothing. I don’t need my entire home folder encrypted, just my sensitive files, the ones I’d be concerned about if someone got ahold of my computer. Besides, in the past I’ve had problems with FileVault which are probably fixed as of Snow Leopard; nevertheless, I don’t want to take the chance of dealing with that kind of thing again.

I thought about using encrypted sparsebundles, but the idea of storing my files on a separate virtual drive just didn’t seem very streamlined. One morning I came to a realization connecting three points: Mac OS X is just Fancy UNIX; disk images are attached to a mountpoint inside /Volumes; UNIX lets you set mountpoints (just about) wherever you want them. See where this is going?

I have about half a dozen encrypted sparsebundles (Mac OS Extended, Journaled format) tucked away in my ~/Library, that correspond to folders in my Home folder. Immediately after I log in, a shell script (that runs as I described previously) attaches these disk images to these folders as mountpoints. The commands go something like this:

hdiutil attach /Users/simplebeep/Library/Application\ Support/FotoCrypt.sparsebundle -mountpoint /Users/simplebeep/Pictures -nobrowse

Hdiutil attach opens disk images. I have the passwords for mine stored in my Keychain, which keeps them safe until I legitimately log in. The mountpoint flag tells the system where to put the disk once it’s open; you’ll notice, in the example, it replaces the system-provided “Pictures” folder. (Just don’t do that with the Library!) Finally, the nobrowse flag instructs the Finder that this is to be treated as a regular folder, and not to be shown on the Desktop or “Devices” section of the sidebar. It’s a folder whose contents just happen to be stored on a separate disk—a disk which is stored, encrypted, elsewhere inside the Home folder.

So all my encrypted files are still stored seamlessly inside my home folder where they “ought” to be. They really function as encrypted folders! I even do this with my Dropbox. When I was setting it up, I simply quit Dropbox, moved the folder’s contents into the appropriate sparsebundle, mounted it in the old folder’s place, and launched Dropbox again. The app didn’t even notice there was a change! My aforementioned script now starts Dropbox after the folder is mounted.

The advantages of this system:

• Time Machine makes hourly backups of my encrypted folders (or rather their encrypted sparsebundle counterparts) even while I’m logged in and they’re mounted.
• Only the folders I want encrypted, are encrypted.
• My documents are still in ~/Documents, likewise with my pictures, etc. Using exactly the same method, I can encrypt my email (~/Library/Mail).
• Once set up, this system is almost as convenient as FileVault. When I log in, my files are there, and when I log out, they’re inaccessible without my password.
• If one of the images fails, it doesn’t affect the others.

The disadvantages:

• This system is difficult to set up if you don’t have a good knowledge of Mac OS or you don’t know exactly how to go about setting it up.
• You can’t use Time Machine’s spacey interface to see past versions of the encrypted folders’ contents. But you can still open up your TM drive and open past versions of the sparsebundles!

 

[noire anqa]

The advantages of this system:

• Time Machine makes hourly backups of my encrypted folders (or rather their encrypted sparsebundle counterparts) even while I’m logged in and they’re mounted.
• Only the folders I want encrypted, are encrypted.
• My documents are still in ~/Documents, likewise with my pictures, etc. Using exactly the same method, I can encrypt my email (~/Library/Mail).
• Once set up, this system is almost as convenient as FileVault. When I log in, my files are there, and when I log out, they’re inaccessible without my password.
• If one of the images fails, it doesn’t affect the others.

Point 1 is invalid:
Have you tried mounting any of those encrypted sparsebundles from your backup?
On Snow Leopard backing up a mounted sparsebundle is just asking for trouble .. on Leopard they will mount but they aren't stable that way .. you're just asking for corruption and with a backup solution thats madness.

Point 2:
Sure

Point 3:
Thats not an advantage is it, both FileVault and your solution result in that.

Point 4:
Almost as convenient once set up? seriously? How is almost as convenient an advantage for your system over FileVault? Surely the more convenient system gets the advantage!

Point 5:
Sure, but isn't that what a backup is for? You're right partial loss is better than total loss, but loss is still crappy and a backup will save you from both.

The only real point you've made is number 2.

 

[simplebeep]

Thanks for your thoughtful and considerate reply. I see you have put deep thought into the failures of my points, which don't make sense except when taken cumulatively and as a whole. Surely I couldn't have intended for that to happen.

Through your thoroughly helpful and constructive language, I have come to realize that backing up an open sparsebundle may indeed be reckless—except that I've successfully done a complete system restore with no data loss. Perhaps it's because I've moved from Time Machine to Carbon Copy Cloner.

 

[noire anqa]

Thanks for your thoughtful and considerate reply. I see you have put deep thought into the failures of my points, which don't make sense except when taken cumulatively and as a whole. Surely I couldn't have intended for that to happen.

The language was intended to move you from a position you thought strongly defended. Perhaps i was overzealous, i'm sorry about that.

Through your thoroughly helpful and constructive language, I have come to realize that backing up an open sparsebundle may indeed be reckless—except that I've successfully done a complete system restore with no data loss. Perhaps it's because I've moved from Time Machine to Carbon Copy Cloner.

CCC and TM use different mechanisms, CCC will copy sparsebundles without damage, TM is capable of doing so but will not do so reliably. If you've done a restore with no data loss im pleased but it doesn't mean TM can be trusted. Do stick with CCC.

Apologies again for my choice of language earlier.

 

[Hal Itosis]

Have you tried mounting any of those encrypted sparsebundles from your backup? On Snow Leopard backing up a mounted sparsebundle is just asking for trouble .. on Leopard they will mount but they aren't stable that way .. you're just asking for corruption and with a backup solution thats madness.

I googled "backing up a mounted sparsebundle" and it only returned this thread. Can you provide any linkage which documents or otherwise discusses the phenomenon? [not doubting... just curious to learn more]

What i did find was this statement:

“TM can back up the disk image itself but it can not back up a mounted virtual volume you get when you mount a disk image. that means you lose the ability to go back in time in iphoto if you share your iphoto library this way. you can still restore the whole library by restoring the whole disk image but that's it.”​

...which is similar to —yet different from —what you're saying. [and it also seems to support the OP's experience wrt restoration.]

But i haven't tested this myself... so was wondering if you have, or perhaps just read about it somewhere (and if so, where?).

 

[simplebeep]

@Hal Itosis, the article you mentioned is speaking of the basic behavior of a disk image and of Time Machine. Remember that a disk image is a file stored in a discrete location; it is then mounted as a volume, a sort of virtual disk (that may or may not appear on your Desktop as a flash drive). Changes you make on that volume are reflected in the disk image file.

Time Machine is designed to back up the contents of your Startup Volume, the volume which contains the actively-running Mac OS, but it cannot back up other volumes, such as the mounted interface of a disk image. But, if the disk image file is stored on your Startup Volume, Time Machine will grab the file, thereby copying the contents of the virtual volume.

Now we must consider that sparsebundles are actually folders that contain small chunks of data comprising the image as a whole. Given this fact, before you proceed with using Time Machine to back up your sparsebundle disk image files, I strongly suggest you heed @noire anqa's advice above:

…TM is capable of doing so but will not do so reliably. If you've done a restore with no data loss im pleased but it doesn't mean TM can be trusted.

Sound advice. Also, in reference to the linked article, sparsebundles don't necessarily store data in such a way as Time Machine can easily handle. You can fetch previous versions of the entire disk image and pull out individual photos yourself, but TM's spacey interface treats the "cryptobundle" as one monolithic file, and can't help you find just the photo you need.

 

[Kenndac]

Hey,

This sounds like a neat little solution to the problem of wanting only a few important bits of information encrypted, rather than your entire home folder. I've never used file File Vault since it's way too heavy-handed for me - I don't see any point in encrypting my photos and music, but my documents and financial stuff? Sure!

If you're skilled enough in the right technologies, you should totally make this into a little application that automates this technique for "normal" (or, should I say non-Terminal-savvy) users. I'd certainly use it!

 

[Hal Itosis]

If you're skilled enough in the right technologies, you should totally make this into a little application that automates this technique for "normal" (or, should I say non-Terminal-savvy) users. I'd certainly use it!

Knox and Espionage are already out there in the field.

Sound advice.

Thanks for the explanation. I'd still be interested in a link (preferably with an apple.com domain, but whatever) which contains "documentation" of this issue.