I am attempting to serve a site off my home machine (a G3 w/cable modem connection). I successfuly (I thought!) installed Apache-PHP-MySQL using the hints on this site. I have been happily coding PHP pages, creating and using MySQL databases, etc., and everything works like a charm when I view locally.
However, no one can seem to access the site from outside. Specifically, I have www.philwebster.com pointed (via a free domain hosting service) to my IP address; the redirection works, but then the browser hangs at "Connecting to [IP address]..."
This is mysterious to me because:
1) When I view the site "locally", I do NOT use 127.0.0.1, but rather the IP address assigned by my ISP (this is assigned using "DHCP" but does not change; I've checked numerous times). I thought this meant my request would go out over the internet and "re-enter" my box from the outside, but apparently not...
2) I KNOW I was able to access the site from outside in the past, and don't know what has changed in the meantime!
I've tried serving from /Library/WebServer/Documents as well as Users/pwebster/Sites and neither seems to work. I even messed around with various settings in httpd.conf, including Port, Listen, etc., thinking it was my ISP blocking Port 80, but to no avail. Ditto with pwebster.conf, .htaccess files, etc.
Anyone had this problem and/or have suggestions as to a fix? This is driving me absolutely crazy! Thanks in advance...
I recently downloaded OmniDictionary from the OmniGroup and was wondering why it wasn't appearing in the Services menu. I found the following on the Omni Group web site: -
Mac OS X 10.0 only registers Services from aplications installed in /Applications, /Developer/Applications, or subfolders thereof, so if you want to use the Service provided by OmniDictionary you'll need to install it in one of those locations. Services can be provided by applications installed in /Network/Applications if the NSServicesFromNetworkApplications default (in NSGlobalDomain) is set to YES.
In order to keep my /Applications folder clean I had been placing apps that I had installed into a sub-folder of /Applications called User Applications. Once I moved my apps in /Applications I had several new entries in Services (OmniDictionary being one), woo-hoo!
The information on the OmniGroup web site implies that apps in subfolders of Applications would register as services (if applicable), but this doesn't seem to be the case.
Here's a substitue for pop-up folders. It works best with Finder windows, but can be applied for others.Take a window, resize it to a small size but so that you can still see the name of the window, and drag it to the bottom on the screen (should only see the title bar). Now hitting zoom will reveal the window in full. Hitting zoom again will return the window to the bottom of the screen. This is easier to use when the dock is is located on the side of the screen. Enjoy.
In the spirit of learning from others' mistakes, I'm sharing the following slightly embarassing story.
In the process of trying to use my web host's Linux OS "tar" command to compress a directory while excluding another, I managed to create a file called "-X". When I went to delete the mistakenly-named file, I quickly found myself stuck. Typing "rm -X" didn't work, because 'rm' interprets the "-" as the sign for a command-line switch, and it doesn't know what to do with "-X" as an option, leading to "unknown option" errors.
Thinking I was smarter than the box, I then tried to use the various UNIX quote characters to 'mark' the hyphen: rm "-X", rm \-X, and rm '-X'. None of these worked; each generated the same error message about unknown options. On my Mac, I would have simply used the GUI and dragged the file to the trash. On the Linux box, though, I was stumped - no GUI available, and a badly named file stuck in my directory.
One amusing ("You won't believe what I've done now...") call to a UNIX-knowledgeable friend provided two options. The first is to use two hyphens to let 'rm' know that there are no command-line switches: rm -- -X. The second is to refer to the file via its relationship to the parent directory: rm ./-X. Either of these will work just fine to delete the file (or you could use "mv" with the same syntax to rename it if you want to keep the file).
At least with OS X we have the option of using the GUI to correct our stupid mistakes! As such, there's an easy way out for X users ... but perhaps this story will save someone some command-line frustration at some point in the future. And please, all you advanced UNIX wizards out there, hold the snickering to a minimum! ;-)
If you want to keep a folder in a standard state (for whatever reason) then the following is one way of doing it (I'm sure there are others). Making the folder read only is another way, but this may not be what you want to do.
(MAKE SURE YOU USE THE CORRECT " ' ` SYMBOLS IN THESE STEPS!)
Create a list of the files in the directory that you want to keep standard e.g. the root level of your hard drive ( '%>' represents the prompt):
%> cd / %> ls >/filelist
This creates a file at the top level of your hard drive called 'filelist', which we'll use to compare contents to. If you are using this to keep the top level of your hard drive clean then run 'ls >/filelist' twice so the 'filelist' file does not get deleted or moved!).
which will move all files and folders not listed in the filelist from root to the current logged in users 'Documents' folder (or any other path you care to specify).
One use for this is to make the last example into a shell script that would run at startup (discussed elsewhere on this site) and this would then move all files that had been saved loose on the HD (root) to the users Document folder, thereby keeping the hard drive tidy.
The default header filters in Mail.app will fail to filter out headers like "Delivered-To:". To fix this, in the Preferences --> Viewing panel, on the Show Header Detail pop-up, click Custom then double click on the "To" filter, and change it to "^To:".
These filters are Regular Expressions, or regexps. They are patterns that match text. In regexp, a caret (^) at the beginning of the string means "the string starts with".
^To: - matches only strings that start with "To:".
The original pattern "To" happens to match the word "To" at the end of "Delivered-To". That's why you see that extra header line.
[Editor's note: regexps are incredibly powerful, and for those new to UNIX (like myself!), incredibly obtuse and confusing. I've been doing some reading on the web about them, and I found a tutorial written by Jan Borsodi which I found to be thorough and easy to read. Worth a view if you'd like to know more of what you can do with regexps; "^" is just the tip of the (large!) iceberg!]
Until now I had been using Get Info the hard way, open and close for each file, but recently, I noticed by accident that by not closing the "Get Info" window and just clicking on a drive, a file, folder, or an application ... I noticed that the information was updated on the fly.
I'm sure this is old news to some but for me it saves a few key strokes and was a nice touch. :-)
[Editor's note: The one-window Get Info interface has both pros and cons ... this tip is the "pro" side; the "con" side is that it's very hard to compare more than two files at once. If you have just two, it's pretty easy to click back and forth and note the difference. If you have three, it's just tedious. Personally, I'm hoping for an option for multiple Get Info windows at some point in the future]
Hello, I've sucessfully installed Ruby, a great newish scripting language. I recommend you try it out. Anyways, it works fine by itself, but I am having problems getting it to work as a script in Apache. I've installed mod_ruby, and have followed their directions. However, I can still not get it to work under Apache. Anyone had any luck?
For those that didn't know it, MacMame (a universal arcade game emulator that can run 2,500 games!) has been carbonized for a while now. There's a new release (download 0.53) out now, and it runs quite nicely in OS X. At left is a quick snapshot of Galaga running on MacMame on OS X -- here's a larger version if you'd like a clearer view.
I ran into a couple of minor visual glitches with a few games, but they are generally quite minor and most games ran perfectly. MacMame provides a large number of options for configuring the video, and it's usually possible to find a setting that looks good and performs well. UPDATE: The 0.53 version (released 8/15/01) seems to fix most of the video glitches I was having. The games now look perfect!
Performance on my G4/733 was (expectedly) fine, even without telling MacMame to hog the CPU. One of the nice things about older arcade games, though, is that they don't require huge amounts of horsepower. MacMame also ran very nicely on our iBook 500.
MacMame relies on original ROM files for the arcade games that it plays. Follow the links on the MacMame web site as a good starting point. From a legal perspective, you should own a full-size arcade version of any ROM you download, as they are still technically not in the public domain.
NOTE: Make sure you also download the new OpenGL plug-in for OS X (and OS 9). It's in the downloads section of the MacMame site, and it lets you apply OpenGL effects (bilinear filtering to smooth the jaggies) to MacMame's games.
If you grew up playing the video games of the 1980's, MacMame is a must-have OS X application!
On very rare occasions, the OS X Finder will lock up and not respond to keyboard or mouse actions. It happened to me tonight when I tried to move 300+ items from my iDisk to a SCSI SyQuest drive - I'm not sure if it was a bug in iDisk, the Finder, or the SCSI drivers. In any event, the Finder showed only the spinning rainbow, and clicking on it in the Dock revealed an "Application not responding" message. The machine was still quite usable (other open apps were doing fine and were fully responsive), but I wasn't sure how to resolve the Finder problem -- I couldn't launch any new applications (such as the Terminal or Process Viewer) since the Finder was unresponsive.
In addition, the usual escape route (command-option-escape) wasn't functional. The dialog box would not show up on the screen, regardless of which app was in the foreground.
I could have used another computer to connect and quit the Finder via "ps aux" and "kill", but that seemed like cheating. The only app I had in my dock (the only way I had to start programs) that wasn't running was CPU Monitor. On a lark, I launched it and noticed that it has two very useful menu items for troubleshooting system lockups - under the Processes menu, you can choose "Open Process Viewer" or "Open Top".
Either one of these was enough to solve my problem -- opening Top launches the Terminal, from where I could open a new window and use "ps aux" and "kill" to relaunch the Finder, or I could (as I did) use ProcessViewer to do it directly.
The moral of the story? To prevent a Finder lockup from rendering your machine unusable, keep one of CPU Monitor, Terminal, or ProcessViewer in your dock at all times. My personal choice is CPU Monitor, since I can get to either of the other apps through CPU Monitor. With one of these apps in your dock, you should (barring a dock lockup!) be able to launch a program to help you restart the Finder.
The nice aspect of working in OS X, of course, was that everything was back to completely normal once I restarted the Finder -- and, much to my amazement, I found that the copy that had locked the Finder had actually completed!