Unity builds a lot of stuff, lots of which are files generated by the tools that shouldn’t be committed to version control.

• Create new empty 3-d project in Unity Editor
• Create a new empty repo in your GitHub account
• Use text editor to add a README.md in the root folder of your project
• Go to GitHub’s archives of .gitignore files and grab the .gitignore for Unity development.
  • Place this file in the root folder for your project
• Execute the following script:

git init
git add README.md ,gitignore
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/adamwadelewis/gallery.git
git push -u origin main

• Now add the contents of your Unity project folder to your repo and then commit and

“Wait a moment, you’re using Homebrew?”, you say Dear Reader? “If you are using Homebrew, shouldn’t we use the copy of the Apache that comes with Homebrew?”, you say?

It’s a viable alternative. Just like with PHP and other things, using a package manager like Homebrew to install the web server in user space means that you can keep up a lot more rapidly with upstream changes in Apache. Down side is you have to undo some things in the system and remember to confirm and redo these things when you update macOS.

Let’s go about it… we need to turn off the version of Apache included in the operating system:

sudo apachectl stop
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist 2>/dev/null

This turns off the server and unloads the system install of Apache from the list of services loaded at system startup.

Now we get things up and running with Homebrew:

brew install httpd
brew services start httpd

One more configuration adjustment: to keep things somewhat clean, Homebrew’s Apache installer defaults to run on port 8080 rather than port 80. This avoids conflicts issues between the system install of Apache and the Homebrew version. But we want the Homebrew version to server pages on the default port.

How to fix this, edit /opt/homebrew/etc/httpd/httpd.conf to switch the listen port to port 80. Use your favorite edit to find the Listen line in the file and make certain it looks like this:

Listen 8080

Now restart the server using brew services restart httpd.

An opinion

There is a common thread among the different blogs telling you how to do this that recommends you reset the server root to the Sites folder in your home folder. This is not something I recommend you to do as I believe you need to have a separation between production and development code. Feel free to reconfigure Apache in this manner as you wish but I’ll leave figuring how to do this to be an exercise for the reader.

Do go back and apply the changes I introduced in Part 1 of this series to get your home folder configured. All you need to do is adjust the files names to use the configuration files in your Homebrew install.

Apple recently made the decision to remove PHP from the OS image.   That’s a good call as the version included with the OS quickly gets out of date.   So, it’s up to us as software developers to manage the install and update of the development tool

A Quick Aside

Time to express an opinion: I am not a PHP fan. It’s a kludge of a language built on top of a kludge of web application architecture. But enough back-end stuff remains built on that architecture that one has to understand it and sometimes support it.

Back to our regular programming

For macOS, the simplest way to manage installing and configurating PHP is to use a package manager like Home-brew. It’s a one line install command:

/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”

Worth noting that is a lot of gooey, cruchy open-source goodness in the Homebrew repository.

At this point, you can install PHP:

brew install php

This will get you PHP8. If you need earlier versions, then you will want to use one of the specific version casks in Brew.

And now things get macOS ugly

We want to configure our Apache install to use PHP. H

Time to hack! Configuring Apache

Things begin by adjusting our Apache configuration to load PHP. Edit the Apache httpd.conf configuration file:

Sudo vi /etc/apache2/httpd.conf

Add the following:

LoadModule php_module /opt/homebrew/opt/php/lib/httpd/modules/libphp.so
<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

Confirm that the DirectoryIndex entry includes “index.php”:

DirectoryIndex index.php index.html

Now we code-sign

Here is where Apple tightening up security in macOS 12 bits us in the posterior: Homebrew’s stuff isn’t code-signed. Means that Apache will puke upon us when it tries to load the PHP module.

We have to manually sign the package. This requires some finagling with keychains using the Keychain Access utility and the Xcode command-line tools.

Here things get “interesting”. We need to adjust macOS to allow us to self-sign certificates. In other words, we get to be our own “Certificate Authority”.

Launch the macOS Keychain Access utility:

Now goto Keychain Assistant>Certificate Assistant>Create A Certificate Authority

. You should see something that looks like this:

Do the following:

1. Adjust the name as needed.
2. Select “Code Signing” from the “User Certificate” dropdown.
3. Turn on the “Let me override defaults” checkbox
4. Enter your e-mail at the appropriate location
5. Select “Continue“
6. Accept defaults for Certificate Information
7. Enter appropriate certificate information and select “Continue”
8. Accept defaults for the Key Pair information for both certificate and users
9. Do the same for extensions
10. Turn on the “Extended Key Usage Extension for This CA” option
11. Select the “Code Signing” checkbox that appears
12. Accept defaults until you get to the create screen
13. Turn on “On this machine, trust certificates signed by this CA“
14. Select “Create”
15. Close the “Certificate Assistant“

Sign the PHP module using the Xcode command-line code signing tool (replacing ”AWL“ as required):

codesign –sign ”AWL“ –force –keychain ~/Library/Keychains/login.keychain-db /opt/homebrew/opt/php/lib/httpd/modules/libphp.so

Now again edit the Apache httpd.conf file and adjust the entry for PHP as below (again, replacing ”AWL“ with what you used in the certificate):

LoadModule php_module /opt/homebrew/opt/php/lib/httpd/modules/libphp.so ”AWL"

Now restart Apache and you should be ready to rock and roll:

sudo apachectl -k restart

Selah.

A good chunk of what we need do web development exists in macOS 12.1 (Monterey) without having to resort to add-ons like the XAMPP stack. I have enough of my students asking me how to do this that I thought I would consolidate my notes and put them up on the web so I can just point them at that reference. This is going to pull from multiple sources and I’ll try to acknowledge every one that I can. Let me know if I missed one.

There are some things you will need to add.  Recent versions of macOS no longer include PHP as part of the operating system.  That’s actually a good thing as the tendency has been for the version included has tended to lag behind the current tip of development.  Here’s where you find yourself using a package manager like Homebrew.

First step: Configuring Apache

The OS includes the Apache web server.  It’s buried pretty deep into the system bits so you are going to having to apply some important skills:

• Understanding of working with the Terminal.app to run command-line programs to update configuration files and manage the web sever

,

• Know some of the internals of the Apache web server,
• And know how to open and save files in text editor like vi or nano.

This information is spread over the Internet but the bulk of the material is taken from the Apple tech support discussion forum at https://discussions.apple.com/docs/DOC-250004361

Start by editing the web server configuration file located at /etc/apache2/httpd.conf. Note that this requires admin permissions, so you will need to use sudo:

sudo vi /etc/apache2/httpd.conf

Look for the line in the file that enables the “Sites” folder for individual users (this is equivalent for macOS as public_html is for Linux). In recent versions of macOS, this is at line 184 in the file. Uncomment that line by removing the leading “#” comment indicator. It needs to read as follows:

Include /private/etc/apache2/extra/httpd-userdir.conf

Save and exit the editor.
 

This change tells the web server to look for an include configuration file that will define user folders in the web server. Edit that file:

sudo vi /etc/apaches2/extra/httpd-userdir.conf

Uncomment line 16 of that file so that it reads:

Include /private/etc/apache2/users/*.conf

Now you need to tell the web server that about your user folders. First step, look in the Users and Group preferences pane to get your short user name. Right click on your user name in the pref pane and select “Advanced Options”. The short user name can be found in the “Account Name” field. For discussion purposes, we’ll use my short name of “alewis”. Replace this with your own when you do this,.

Now let’s use your tex editor to create a configuration file for user folders:

sudo vi /etc/apache2/users/alewis.conf

Add the following content:

<Directory “/Users//Sites/”>
 AddLanguage en .en
 Options Indexes MultiViews FollowSymLinks ExecCGI
 AllowOverride None
 Require host localhost
</Directory>

You will need to add additional configuration items to this file if, for example, you want to enable PHP.

Then create the Sites folder in your home folder:

mkdir ~/Sites
echo “<html><body><h1> My site works</h1></body></html>” > ~/Sites/index.html.en

This creates the Sites folder and adds a minimal working example in the folder that we can test against shortly.

Now we have to do some shell voodoo. Apple has tightened up the security in macOS 12 to, by default, not allow other users access to a user’s folders,. The macOS installation of Apache is configured to run in a special hidden user account named “_www”. You need to setup an Access Control List (acl) that lets the web server have access to your folder:

chmod +a “_www allow execute” ~/Sites
 

And now we see if things work. With Apache, one should always use the web servers configtest command to make certain things are configured in a clean manner:

apachectl configtest
 

So… what’s apachectl? That’s a command line tool that one uses to control the web server (which is an Apache thing, and so works on any of the UNIX-based operating systems). If the config test returns ‘Syntax OK’, then you are ready to rock the web.

Now for macOS command-line magic… you need to tell macOS to start Apache at system startup:

sudo launchctl load -w /System/Library/LaunchDaemons org.apache.httpd.plist

If you want to get things running in the meantime, do a:

sudo apachectl graceful
 

At this point, navigate to http://localhost and http://localhost/~<your short user name> and see if you get the expected responses from the web server.

 
Reference: https://discussions.apple.com/docs/DOC-250004361

Next up: Getting PHP to work using Homebrew.

One of the leading reasons to dive into the command-line tools in macOS is automation.   Writing scripts that link with the Shortcuts stuff adapted from iOS means you can automate some things.

For instance, there is a command-line tool that you can use to run software updates: software update.

Consider:

softwareupdate -l

This gets you a list of available software just like what happens in System Preferences when you launch the Software Update preference pane. In both cases, the utilities are talking the softwareupdate daemon in the operating system.

Next up, getting stuff installed:

softwareupdate -I NAME
softwareupdate --install name

You replace NAME with one of the items from the list you asked for in the first step. Be careful there as macOS is very sensitive about names and format of names. You should quote the names and watch out for cases where the name has trailing spaces.

The “-d” option will just download an update while including the “-a” option will install all available updates. One of the useful options for this command-line tool is “–install-rosetta”. This option tells macOS on Apple silicon Macs to install the Rosetta 2 hypervisor/emulator for Intel macOS applications. Include the –agree-to-license” option to agree to the software license agreement without user interaction.

Selah.

Non-developer types (you know, you “normies” out there) tend to want to do everything using the mouse rather than the keyboard. Really true for people using macOS. Makes me hurt when I see it as there are many things easier to do with the command line than with multiple mouse clicks.

This isn’t going to be series talking about how to do stuff in Bash or zsh using the Terminal application. Lots of introductions out on the Intertubes about Shell programming and how one can use it to automate for fun and profit. This series is going to point out things that about using the command line in macOS that you don’t often hear about.

Like what things? Many of the tools you use to run macOS have lesser known command line interfaces. Classic examples are apps like Disk Utility and Software Update. Both have command line interfaces that allow you to do stuff in single commands that take multiple clicks in the GUI. That’s what we’re going to examine in this series of posts.

But there are some things available to you in the Terminal app and with Bash and/or zsh that you can use to make your life easier. Drag and drop is supported by Terminal… dragging a folder icon from Finder to the Terminal’s Dock icon opens a new window in the app and changes the current working folder to that that folder. Dragging files onto a Terminal window inserts their paths separated by spaces.

A really useful thing is the open command. Issuing the command by itself in a shell will open the current working folder in a Finder window. You can specify a file name as an option:

open ~/Library/Preferences
open ../..
open /etc

Provides a quick way to get to hidden folders when you need to do something “admin”-like on your machine.

You can open a specific file, which will use the current association for that file type to open the file, or use the -a option to specify the app to use to open the file. You have the -e or -t options to open a file using TextEdit or your favorite editor.

Really useful is the -f option which allows you to pipe text into the open command. This allows you to use open within shell pipelines, up to and including getting output from a command into a text editor.

Lots of things that you can do here and Terminal’s linkages into Finder and the open command give you way to link the things you do in the Terminal with the windowing system and vice-versa. So go grab a good tutorial in the use of zsh and enjoy!

Selah.