A reader writes: I’ve started to go through your shell script book but there is still something I’m unclear on. I’m showing my ignorance here, but how exactly do you save a shell script so you can use it later?” If you’re comfortable using the vi editor within the Mac OS X environment, your best bet is to open up a Terminal window (Applications - Utilities - Terminal) and type in the script directly. If not, you can use an application like BBEdit, save the file as text-only with or without line breaks, then open up the Terminal application and type in the name of the script, as in sh myscript.sh (assuming you saved the file as ‘myscript.sh’). The final step is for you to actually make the script executable, which you can do by using the chmod command, as in: chmod +x myscript.sh. Once you’ve done that – particularly if you have the script in one of the directories in your PATH – you can execute the script by simply typing its name at the command line.

Colin, Just off the top of my head, here are three possibilities for why your AppleScript script that uses the “Do Shell Script” AppleScript command isn’t working: o Using a different shell in Terminal vs. In Do Shell Script; or o Using a different starting directory in Terminal vs.

In Do Shell Script; or o Using different I/O redirection in Terminal vs. In Do Shell Script. Failing the above, I hope that this “application note” for the Do Shell Script command in AppleScript will get you pointed in the right direction. It should be REQUIRED SKIMMING for anyone who uses the Do Shell Script command: Technical Note TN2065 do shell script in AppleScript Over time, the above link might fail because of “link rot.” If that happens, I suggest searching Apple’s Developer website on “tn2065” (without the quotes).

I have found that wrapping an Unix command or Unix shell script invocation command (the name of the script) in an AppleScript is a great–and quick–way to turn any shell script or Unix command into an OSX application. Just save it out of the AppleScript Editor, being sure to select the “Application” choice for the “Format” on the drop-down menu in the “Save” dialog box. That will create an OSX application that can be double-clicked to launch, can be put into your Dock, etc, and can be generally used just the same as any other OSX application. I am new to the terminal and my work is letting do some work from home.

I am suppose to add some lines in my local host terminal to allow me access my work environment. I have the lines I am suppose to add below my 127.0.0.1 localhost to allow me access to my work environment. But I am lost as how to actually insert them into the terminal below the 127 localhost. How do I add a couple lines of text below the 127. I have tried looking on the internet, but to no avail.

I now know how to do lots of other neat commands except how to enter text into my terminal. Do I have to use the vi thingy or open up a text editor and type it in there and then paste it into the terminal. Thanks for your help in advance.

Hello, I hope that you are able to assist me. I am running a WebSTAR server on an old Macintosh G4 500 MHz DP mini-tower running Tiger 10.4.11. One of the websites that I operate requires using PHP and a mySQL database. While Tiger has PHP 4.4.9, I am using a self-contained version of PHP 5.2.0 which is installed in: /Applications/PHP5/bin/this is where the actual php binary is located This is a self-contained PHP package that I downloaded from the Zend website. The problem is that PHP crashes several times throughout the day. I don’t know if it is a result of so many search bots hitting the site, or people who are maliciously attacking the site, or what, but the constant PHP crashing is annoying, and makes the site unreliable.

Currently, the way I have dealt with the PHP crashing problem is by keeping “Activity Monitor” open on my desktop, as well as the Terminal. Whenever I see PHP disappear from “Activity Monitor”, I follow the instructions provided by 4D — the makers of WebSTAR — and type the following in the Terminal to restart PHP: set env PHPFCGICHILDREN 8./fcgirunner.pl xyz./php The x’s are the port number. “fcgirunner.pl” is an old PERL script released by Zeus Technology to startup remote FastCGI processes with their Zeus Web Server. As you can imagine, it is a hassle to have to keep an eye on PHP, and reboot it manually every time that it crashes, and I do have to sleep. With that in mind, I am interested in finding a way to automatically watch the PHP binary that is located at the above path, and to automatically relaunch the PHP binary in fcgi mode by using the above two Terminal commands, without having to keep “Activity Monitor” and the Terminal open all the time.

In short, I need a solution which will do two things: 1. Keep an eye on the self-contained PHP installation. Automatically reboot the PHP binary in fcgi mode — as per the above two Terminal commands — every time that it crashes. Someone on another site suggested that I use a shell script, but I have basically no experience with such things.

They suggested that I begin with something like the following, but to be honest, it is all Greek to me: CODE #! /bin/bash ofPid=’/bin/ps -ax grep php grep -v pidcheck.sh grep -v grep’ if -n “$ofPid” then exit 0; else /Applications/PHP5/bin/fcgirunning.pl fi exit 0; /CODE Another person suggested that I use “launchd with the KeepAlive key enabled”, but I have no idea whatsoever how to do that.

They offered this example: CODE Label my.textedit.job KeepAlive ProgramArguments /Applications/TextEdit.app/Contents/MacOS/TextEdit /CODE They also pointed me to the launchd manual on the Apple site, and to a page about daemons and agents, but again, it is way over my head. What would be perfect would be a shell script enclosed in an Applescript — as you described in a previous comment — which I could save as an application, and then add to my startup items. That way, the minute I start up the G4, PHP will automatically be launched, and the script will keep an eye on it.

It would be necessary for this script to check the PHP process every minute to make sure that it is still running, as otherwise, if PHP crashes, visitors to the site just get a blank, white page. Please bear in mind that I am not very proficient at using the Terminal, and have very little experience at writing Applescripts, or any other scripts. So, if you offer that kind of a solution, you will need to provide me with very clear step-by-step instructions. Thanks so much in advance.

As of AIR 2, you can use ADT to create native application installers for distributing AIR applications. For example, you can build an EXE installer file for distribution of an AIR application on Windows. You can build a DMG installer file for distribution of an AIR application on Mac OS. In AIR 2.5 and AIR 2.6, you can build a DEB or RPM installer file for distribution of an AIR application on Linux. Applications installed with a native application installer are known as extended desktop profile applications. You cannot use ADT to package a native installer for an AIR application if the application descriptor file does not support the desktop extended profile. You can restrict this profile using the supportedProfiles element in the application descriptor file.

You can build a native installer version of the AIR application in two basic ways. You can build the native installer based on the application descriptor file and other source files. (Other source files may include SWF files, HTML files, and other assets.). You can build the native installer based on an AIR file or based on an AIRI file.

You must use ADT on the same operating system as that of the native installer file you want to generate. So, to create an EXE file for Windows, run ADT on Windows.

To create a DMG file for Mac OS, run ADT on Mac OS. To create a DEB or RPG file for Linux, run ADT from the AIR 2.6 SDK on Linux. When you create a native installer to distribute an AIR application, the application gains these capabilities. It can launch and interact with native processes, using the NativeProcess class. For details, see one of the following:.

(for ActionScript developers). (for HTML developers).

It can use native extensions. It can use the File.openWithDefaultApplication method to open any file with the default system application defined to open it, regardless of its file type. (There are restrictions on applications that are not installed with a native installer. For details, see the entry for the File.openWithDefaultApplication entry in the language reference.) However, when packaged as a native installer, the application loses some of the benefits of the AIR file format.

A single file can no longer be distributed to all desktop computers. The built-in update function (as well as the updater framework) does not work. When the user double-clicks the native installer file, it installs the AIR application.

Open Exe File On Mac

If the required version of Adobe AIR is not already installed on the machine, the installer downloads it from the network and installs it first. If there is no network connection from which to obtain the correct version of Adobe AIR (if necessary), installation fails. Also, the installation fails if the operating system is not supported in Adobe AIR 2. Creating a native installer from the application source files To build a native installer out of the source files for the application, use the -package command with the following syntax (on a single command line): adt -package AIRSIGNINGOPTIONS -target native WINDOWSINSTALLERSIGNINGOPTIONS installerfile appxml fileordir -C dir fileordir -e file dir. This syntax is similar to the syntax for packaging an AIR file (without a native installer). However there are a few differences. You add the -target native option to the command.

(If you specify -target air, then ADT generates an AIR file instead of a native installer file.). You specify the target DMG or EXE file as the installerfile. Optionally, on Windows you can add a second set of signing options, indicated as WINDOWSINSTALLERSIGNINGOPTIONS in the syntax listing. On Windows, in addition to signing the AIR file, you can sign the Windows Installer file. Use the same type of certificate and signing option syntax as you would for signing the AIR file (see ). You can use the same certificate to sign the AIR file and the installer file, or you can specify different certificates. When a user downloads a signed Windows Installer file from the web, Windows identifies the source of the file, based on the certificate.

Mac Executable File

For details on ADT options other than the -target option, see. The following example creates a DMG file (a native installer file for Mac OS). Creating a native installer for an application that uses native extensions You can build a native installer out of the source files for the application and the native extension packages that the application requires.

Use the -package command with the following syntax (on a single command line): adt -package AIRSIGNINGOPTIONS -migrate MIGRATIONSIGNINGOPTIONS -target native WINDOWSINSTALLERSIGNINGOPTIONS installerfile appxml -extdir extension-directory fileordir -C dir fileordir -e file dir. This syntax is the same syntax used for packaging an a native installer, with two additional options. Use the -extdir extension-directory option to specify the directory that contains the ANE files (native extensions) that the application uses.

Use the optional -migrate flag and MIGRATIONSIGNINGOPTIONS parameters to sign an update to an application with a migration signature, when the primary code-signing certificate is different certificate than the one used by the previous version. For more information see. For details on ADT options, see. The following example creates a DMG file (a native installer file for Mac OS) for an application that uses native extensions. Creating a native installer from an AIR file or an AIRI file You can use ADT to generate a native installer file based on an AIR file or an AIRI file. To build a native installer based on an AIR file, use the ADT -package command with the following syntax (on a single command line): adt -package -target native WINDOWSINSTALLERSIGNINGOPTIONS installerfile airfile This syntax is similar to the syntax for creating a native installer based on the source files for the AIR application. However, there are a few differences.

Run Exe File On Mac

As the source, you specify an AIR file, rather than an application descriptor file and other source files for the AIR application. Do not specify signing options for the AIR file, as it is already signed To build a native installer based on an AIRI file, use the ADT -package command with the following syntax (on a single command line): adt AIRSIGNINGOPTIONS -package -target native WINDOWSINSTALLERSIGNINGOPTIONS installerfile airifile This syntax is similar to the syntax for creating a native installer based on an AIR file. However there are a few of differences.