[shadybirdstan]

Is there anyway to see and more importantly edit these files when using OS X?

Each time I try to create one the OS won't let me.

Thanks.

[philzilla]

create it in BBEdit, TextEdit, etc. cd to the directory you want it in, save as 'htaccess' (no dot). open terminal, cd to the same dir, type:

sudo mv htaccess .htaccess

to open an existing file, use BBE's Open Hidden feature, or, use terminal:

open *.doc

open's options are as follows:

-a application (specifies the application to use for opening the file)

-e (causes the file to be opened with /Applications/TextEdit)

so, you'd want:

open -e .htaccess

[shadybirdstan]

Thanks.

[Rainy Day]

You can also use TinkerTool to show invisibles, although the downside to this approach is that you see some other files which are best left unseen.

But unless you're administering a server with multiple users who should not have access to the server's configuration file, it's better to keep .htaccess turned off and just make your changes in a file in the /private/etc/httpd/users/ directory. While .htaccess is sometimes more convenient than a config file (doesn't require an Apache restart for changes to take effect), there is a significant performance penalty as Apache looks for, reads and parses an .htaccess file (if present) in every directory from root on down to the directory containing the file being served everytime a page is served!

Anything which can be done with a .htaccess file can be done from a server configuration file. The only reason i can think to turn on .htaccess files is if you're developing a web site locally which will eventually be moved to another server (using .htaccess). In such a case, you're better off turning on .htaccess files only in the root directory of your development site, and not for your entire computer. This will at least reduce the number of directories searched for .htaccess. Of course one could keep it turned off during the early development phase of the project. YMMV.

[shadybirdstan]

Originally posted by Rainy Day:
You can also use TinkerTool to show invisibles, although the downside to this approach is that you see some other files which are best left unseen.

Thanks I'll check that out.

But unless you're administering a server with multiple users who should not have access to the server's configuration file, it's better to keep .htaccess turned off and just make your changes in a file in the /private/etc/httpd/users/ directory. While .htaccess is sometimes more convenient than a config file (doesn't require an Apache restart for changes to take effect), there is a significant performance penalty as Apache looks for, reads and parses an .htaccess file (if present) in every directory from root on down to the directory containing the file being served everytime a page is served!

Anything which can be done with a .htaccess file can be done from a server configuration file. The only reason i can think to turn on .htaccess files is if you're developing a web site locally which will eventually be moved to another server (using .htaccess).

I'm using this method because I'm learning some PHP on my side but want to eventually transfer the file to a web host that will let me use .htaccess files on their servers.

In such a case, you're better off turning on .htaccess files only in the root directory of your development site, and not for your entire computer.

I'm going to be doing my development in the root of my /library/webserver/documents because apparently this will more closely mirror the site when I transfer it to my host.

The problem I'm having now though, is just turning on .htaccess files. As soon as I set:

Code:
# This controls which options the .htaccess files in directories can
# override. Can also be "All", or any combination of "Options", "FileInfo", 
# "AuthConfig", and "Limit"
#
    AllowOverride All

In my httd.conf file I get a "Forbidden
You don't have permission to access / on this server." even if I have a blank .htaccess file sitting in /library/webserver/documents.

Another issue:
According to the book I'm reading I should enter the following into a .htaccess file:

Code:
php_value include_path
".:/usr/lib/php/:/var/www/html/_lib/_base:/var/www/html/_lib/_classes:/var/www/html/site:/var/www/html/core:/var/www/html/pear"

php_value register_globals "Off"

They then go on to say that "/var/www/html/" is their web server's root directory and I should change mine accordingly, which also has me stumped and unfortunately there is no more support offered for this book. I'm also confused by what they mean as far as /usr/lib/php is concerned.

Any help would be GREATLY appreciated.

[shadybirdstan]

A little update:

I used the terminal to delete the .htaccess file I had created (I used BBEDIT and think it may have screwed the file up). Used the touch command and then edited the file with PICO. The .htaccess file now works!!!

Now on to the second part of my question and I'm hoping you can help me Rainy Day .

This is the outstanding part of my question:

Another issue:
According to the book I'm reading I should enter the following into a .htaccess file:

Code:
php_value include_path
".:/usr/lib/php/:/var/www/html/_lib/_base:/var/www/html/_lib/_classes:/var/www/html/site:/var/www/html/core:/var/www/html/pear"

php_value register_globals "Off"

They then go on to say that "/var/www/html/" is their web server's root directory and I should change mine accordingly, which also has me stumped and unfortunately there is no more support offered for this book. I'm also confused by what they mean as far as /usr/lib/php is concerned.

[Rainy Day]

I used the terminal to delete the .htaccess file I had created (I used BBEDIT and think it may have screwed the file up). Used the touch command and then edited the file with PICO. The .htaccess file now works!!!

Ouch. PICO (or any CLI editor). More than likely, you had some errant control or high-ASCII character in the file. Apache seems to have problems with them in configuration files, and i suspect in .htaccess files as well. I once had a option-space character (instead of a regular space) in a config file and Apache refused to start because of it.

Forbidden You don't have permission to access / on this server."

"/" is the root level of your HD. You shouldn't be trying to serve any web pages out of there.

They then go on to say that "/var/www/html/" is their web server's root directory and I should change mine accordingly, which also has me stumped and unfortunately there is no more support offered for this book.

My advice is to intrepret this to mean: Wherever you see "/var/www/html/" in our book, substitute "/Users/yourusername/Sites/" instead. Really, though, you shouldn't need to do this in more than a few places at most, or something is amiss.

There's really no need to move the location of your Apache root directory. In fact, doing so is probably a bad idea. All your HTML and PHP code should be relative to whatever arbitrary root you might choose. This means your code will be portable and can move easily from one server (such as your local Mac) to another (such as your production server).

Just use the default root which Apple provides (i.e. the Sites directory in your user's home).

I'm also confused by what they mean as far as /usr/lib/php is concerned.

It's a search path for use by PHP. It belongs in your php.ini file; i don't believe it's even legal syntax for .htaccess. Same holds for register_globals "Off", by the way.

[Edit: I'm not familiar with the php_value directive and missed it on my first reading. It looks to be a way to pass variables to PHP from .htaccess, and thus would be legal syntax. However, since it would be parsed at runtime each time a page (any page, even a non-PHP page) is accessed in that directory or any directory below, it would add unneccessary overhead to the server and its use, therefore, should be avoided (unless, of course, you don't have access to the configuration files on a remote server and have no other choice). Best to put it in the php.ini file if possible.]

The register_globals "Off" is a good thing. It adds security to PHP by requiring a shroud around globals.

So what are you trying to do? Are you simply trying to learn PHP? Or install a PHP based package?

If you're simply trying to learn PHP, all you really need do is make a couple of changes to your Mac user's Apache configuration file* and you're off and running. If you're trying to install a PHP based package, then you may have to worry a bit more about search paths and the like.

* Note: Under MacOS X, you're better off not modifying Apache's main httpd.conf, but rather make your changes in a separate file stored in /private/etc/httpd/users/

Notice the last line of Apple's standard httpd.conf file:

Include /private/etc/httpd/users

That's intended to load http.conf customizations for individual users on your Mac. What it does, effectively, is append every file in the directory /private/etc/httpd/users/, in alphabetical order, to your /etc/httpd/httpd.conf file. So if you place a file containing only the customizations you would otherwise make to /etc/httpd/httpd.conf in the directory /private/etc/httpd/users/, your customizations will always be in effect without ever editing your /etc/httpd/httpd.conf file, and they won't break with various system updates. Slick, eh?

Important safety tip: Every file in /private/etc/httpd/users/ is appended to your /etc/httpd/httpd.conf file, even files with suffixes like ".bak", so keep your backup files in another directory, else they are likely to override the changes you're making in your primary file (e.g. my.httpd.conf.bak would load after my.httpd.conf, which might undo the edits you've made and send you off chasing your tail for hours while trying to figure out why the changes you're making don't seem to work properly -- of course i was never caught by this snare! ).

[shadybirdstan]

Originally posted by Rainy Day:
Ouch. PICO (or any CLI editor). More than likely, you had some errant control or high-ASCII character in the file. Apache seems to have problems with them in configuration files, and i suspect in .htaccess files as well. I once had a option-space character (instead of a regular space) in a config file and Apache refused to start because of it.

"/" is the root level of your HD. You shouldn't be trying to serve any web pages out of there.

My advice is to intrepret this to mean: Wherever you see "/var/www/html/" in our book, substitute "/Users/yourusername/Sites/" instead. Really, though, you shouldn't need to do this in more than a few places at most, or something is amiss.

There's really no need to move the location of your Apache root directory. In fact, doing so is probably a bad idea. All your HTML and PHP code should be relative to whatever arbitrary root you might choose. This means your code will be portable and can move easily from one server (such as your local Mac) to another (such as your production server).

Just use the default root which Apple provides (i.e. the Sites directory in your user's home).

It's a search path for use by PHP. It belongs in your php.ini file; i don't believe it's even legal syntax for .htaccess. Same holds for register_globals "Off", by the way.

The register_globals "Off" is a good thing. It adds security to PHP by requiring a shroud around globals.

So what are you trying to do? Are you simply trying to learn PHP? Or install a PHP based package?

If you're simply trying to learn PHP, all you really need do is make a couple of changes to your Mac user's Apache configuration file* and you're off and running. If you're trying to install a PHP based package, then you may have to worry a bit more about search paths and the like.

* Note: Under MacOS X, you're better off not modifying Apache's main httpd.conf, but rather make your changes in a separate file stored in /private/etc/httpd/users/

Notice the last line of Apple's standard httpd.conf file:

Include /private/etc/httpd/users

That's intended to load http.conf customizations for individual users on your Mac. What it does, effectively, is append every file in the directory /private/etc/httpd/users/, in alphabetical order, to your /etc/httpd/httpd.conf file. So if you place a file containing only the customizations you would otherwise make to /etc/httpd/httpd.conf in the directory /private/etc/httpd/users/, your customizations will always be in effect without ever editing your /etc/httpd/httpd.conf file, and they won't break with various system updates. Slick, eh?

Important safety tip: Every file in /private/etc/httpd/users/ is appended to your /etc/httpd/httpd.conf file, even files with suffixes like ".bak", so keep your backup files in another directory, else they are likely to override the changes you're making in your primary file (e.g. my.httpd.conf.bak would load after my.httpd.conf, which might undo the edits you've made and send you off chasing your tail for hours while trying to figure out why the changes you're making don't seem to work properly -- of course i was never caught by this snare! ).

Awesome tips and info...thank you very much .

[JB72]

* Note: Under MacOS X, you're better off not modifying Apache's main httpd.conf, but rather make your changes in a separate file stored in /private/etc/httpd/users/

Notice the last line of Apple's standard httpd.conf file:

Include /private/etc/httpd/users

I think you may want to put that in your sig.

Although, isn't the important part the "/users," more than the "/private?" Aren't they the same file via symlink?

related:


Getting the heck out of httpd.conf

The recent 10.2.4 update of Mac OS X unfortunately futzed with my Apache configuration file, confusing the heck out of me when suddenly my closet server stopped accepting iCal DAV-based publish requests.

Rather than re-inserting my site-specific settings into /etc/httpd/httpd.conf each time Apple decides to overwrite the Apache config file, I now maintain a site.conf file in /etc/httpd/conf/users, right alongside all the username.conf files.

These are loaded by the Apache Web server each time the it is (re)started. That's taken care of for you by the last line in httpd.conf:
Include /private/etc/httpd/users

This way, software updates may come and go, but my local configuration is unaffected