Quitting Terminal after shell script runs
 

I just wondered if anyone has any tips or thoughts on the best way to make the Terminal quit once a shell script is run?

I could run the shell script in an AppleScript/Automator wrapper, but that's kind of a workaround.

I've seen this used:
kill -3 $(ps wax | grep "[T]erminal.app" | awk '{print $1}')

I realise there's a danger that I might have other processes running when I run my script.

You could use:

osascript -e "tell application "Terminal" to quit

or

"do shell script" Applescript command to run it without opening the Terminal in the first place.

What exactly does the shell script do?
I.e., if there's no user I/O involved, why even run it in a terminal?
[i execute many a bash script from Script Menu.]

The script is a fix for an application which invariably corrupts its preference file, causing a crash at the next launch. All it does is to replace the corrupt preference file with a backup. I suppose there's no reason why it couldn't be an AppleScript.

So bash scripts in the script menu don't run in Terminal...?

Right... and "AppleScript" not needed either. Just put the ugly black-icon "UNIX executable" bash file down in /Library/Scripts (or ~/Library/Scripts) somewhere, right next to those .scpt items [EDIT: or create your own "unix" subfolder if you like]... and select it from the menu.

That's extremely useful. Many thanks for that tip.

What exactly is it you are trying to accomplish? Also, if you add the suffix (extension) to a file that ends in ".command" it will make it double click-able to run from the GUI

Well, yes. The suffix .sh is also double-clickable. Terminal opens, runs the script, but does not quit.
Running the script from the scripts menu, or indeed as an AppleScript, would solve the "problem".

OK, I should have been more clear. How and what are you trying to do exactly, I run scripts on computers all the time with out ever opening up terminal. Is this something you can do remotely?

As I said, I have a little script that I double-click on, and it swaps the preference file of an app that keeps corrupting with a clean backup copy. It's literally just a cp command. (Plus #!/bin/sh and exit 0 )

The file is prefswap.sh, it has executable flags set, and when I double-click on it, it opens Terminal.

I realise that I could probably achieve the script's result in other ways: but it's more of a general enquiry, as I'm starting to write lots of little scripts.

How do you make run your scripts without the Terminal opening, then?

Well, you can set it as a log in hook and have it run at every log in. You can have launchd run it at scheduled times. You can create an alias in your ~/.bash_profile and just execute a single command in terminal and then quit it yourself. You can have the ARD client run it from a task server. If you have any third party enterprise apps available they do it as well.

You could even set up a work flow in Automator that would do all of this but I don't really use Automator all that much or ever really.

I'm really looking at scripts that need to be run at whim, rather than scheduled. So I think having them in the Scripts menu is the way to go.

You could create an alias in your ~/.bash_profile so you only need to type in one command. Does this happen often? I would also suggest filing a bug report with the developer of this application. It sounds rather annoying to have to do something like this over and over again.

I could do the alias, but that seems more clicks and keypresses than rather just clicking on the script.

The developer has fixed the problem, but only in the new version, which I'd have to pay the upgrade price for. (They release a new version every year.) It only happens occasionally, so I wouldn't want the script to run every startup.

I'm interested in having a whole raft of shell scripts. For instance, I've collated all the "default write" commands that I've used into one script, so that they can be run all at once in a new account or after a reinstall or similar.

Well one last thing to consider. If this is a user level preference, ie in your home directory, you can modify the user template. So, copy your pristine known good preference into the user template and anytime you delete that plist file, it will grab a new one from the template and it will get a fresh copy of the known good one. If the third party app does this off of their own template you can modify theirs, but as far as I have read (it will need to be tested out) that this method will work. So all you would have to do is just trash that plist in question and when the next new one is made on the fly it will grab it from the template.

Nice!

Will give it a go.

You know it!

That little-known functionality has been around a long time... but it actually broke in an early release of some update (Tiger 10.4.0 iirc), and a few folks around here went bats#!t. [if i can find the thread, i'll add a link.] EDIT: Bingo: "Script Menu and shell scripts" (May 2005)


@tlarkin:

You seem to be missing the fundamental advantage of being able to have a collection of executables which can be easily run at will by simply selecting them from a menu. Scheduling has its place, but it's not the be-all and end-all of everything. Sometimes we want to run a script on a whim (like benwiggy said), and often it's something related to some other *GUI* task with which we're currently engaged. Being able to drop down the *global* Script Menu (i.e., available from any app), and select a script to run is so much more convenient than shifting over to terminal, and typing out the name of some function (and then shift back to the GUI program).

The only remaining thing to be "fixed" here is for you to grasp that point! ;)

This is the 2nd time you've made this claim, but i have yet to see any actual proof.

And (assuming it can be rigged by editing some template), how is that actually any better?

• Script Menu method: select script. DONE!
  
  
• Your method: Go to Finder. Open home. Open Library. Open Preferences. Fish around for some plist. Move found plist to trash.

Hmm.

Hal

I know for a fact the user template works with all apple plists, but I have not had the chance to test all third party which is why I gave that disclaimer. I have used it in the past and have verified it works.

You can also run scripts from TextWrangler. When I write my scripts TW keeps a quick access menu on the side with every script I have written, and I can highlight and tell it to run or run in terminal or to get output of script.

I see the advantage of what you are talking about but was not sure the exact situation of the problem. Which is why I asked, and if it was something that happened on a very frequent basis, why not automate it?

Keep it simple, but get all the facts first.

No it doesn't. As i indicated in the other thread: if we delete our dock.plist, we don't wind up with a "default" dock a minute later. Finder has the former plist cached in RAM. It will re-write the (RAM) cached version to disk, and act like nothing happened.

I'm not going to argue, but here read for yourself

http://www.macosxhints.com/article.p...11010033851924

http://www.mytechmusings.com/2007/06...-template.html

http://www.makemacwork.com/customize...r-template.htm

top hits off google, and yes you do need to clear cache when you do this, but it does in fact work.

I don't need to google. I just deleted my own dock.plist.

The thing is:

1. what is the actual "problem" being discussed? -- and
2. how do these "solutions" you propose relate in a practical manner?

>>> and yes you do need to clear cache when you do this, but it does in fact work.

If some suggestion doesn't really fit a particular problem (let alone offer any advantage over methods already given), then i don't quite follow the purpose.

Did you actually modify the user template? Just because you don't quite grasp the benefits doesn't make it an invalid option. There are plenty of things you do with your Mac that I have not a clue which you are doing from reading your posts, but I would hardly try to claim them to be irrelevant.

The logic behind my suggestion was if you can modify the user template in /System, or perhaps the default template with in the application's contents itself, you can modify the default plist so you never have to run a script.

Also, I was unaware of the frequency of this problem, and there have been many solutions which address this in the same manner. I will give an example that Mike Bombich posted on his website.

1) Create a set of plists you want the end user to have

2) Modify the user template and copy over your plists, but make sure to clear caches, logs and other things you don't want every user to have

3) Create a log out script that wipes out all plist files in case the end user modifies anything so next time they log in they get the fresh set of plists from the user template.

From the OP:
If there were a way to just fix this all together, then why not try it? Why even bother with a script? I don't know and still don't know all the details so I can't deduct if that is possible.

You are very smart when it comes to Unix, no doubt smarter than I am, but my methods aren't out of this world when addressing problems like this. I deal with tons of crappily coded educational apps that I have to do things like this from time to time. I try to package it up in composer, with the files modified exactly how I want them to, thus fixing the problem with out having to do any post scripts.

As far as the 'plist' goes, perhaps it could simply be locked and that might obviate everything.


Well, that seems to be somewhat contradictory (never run a script <--> run script every logout). So then what, he needs to logout each time before relaunching the app? Not practical, imho.

Anyway, this thread had another aspect: "Quitting Terminal after shell script runs"... and,
i think one thing readers can take away from all this is the Script Menu tip works for that.

If a 'user template' solution ever materializes, i'll be happy to look at it.