| #!/bin/sh | |
| # Alot of these configs have been taken from the various places | |
| # on the web, most from here | |
| # https://github.com/mathiasbynens/dotfiles/blob/master/.osx | |
| # Set the colours you can use | |
| black='\033[0;30m' | |
| white='\033[0;37m' | |
| red='\033[0;31m' |
I have spent quite a bit of time figuring out automounts of NFS shares in OS X...
Somewhere along the line, Apple decided allowing mounts directly into /Volumes should not be possible:
/etc/auto_master (see last line):
#
# Automounter master map
#
+auto_master # Use directory service
| HTTP Status Codes General Nature of the Response | |
| • 1xx—Informational status which states that the request has been received and is continuing | |
| • 2xx—Success status which states that the request was received and accepted | |
| • 3xx—Redirection status which states that to complete the request, further action must be taken at another URI | |
| • 4xx—Client error status which states that the request is either improperly for- matted or cannot be completed for some reason |
| Response Headers | |
| ---------------- | |
| Response headers from the server give the client metadata about the resource being returned. Often, the response headers have matching corollaries in the request head- ers. Here is a list of response headers that you will most often be concerned with: | |
| • Age: 30—This gives the time the resource has been in proxy cache, in seconds. | |
| • Allow: GET, HEAD, PUT, DELETE—This lists the HTTP methods allowed on the resource. You saw this earlier, in the response to an OPTIONS request. | |
| • Cache-Control: max-age=120—This header allows either the client or server more control over caching than the default mechanisms. These commands are intended for proxy caches that lie between the client and server. Chapter 8, “Load Balancing and Caching,” covers this in greater detail. |
| Request Headers | |
| --------------- | |
| Request headers let the client specify additional information to the server about the requested representation of a resource. This list is by no means complete, but here are some common request headers, with examples that a client may specify: | |
| • Accept: text/plain, text/html—This tells the server that the client is looking for a plain-text or HTML representation of the resource. Other options could be application/json, text/javascript, application/xml, text/xml, image/jpeg, and countless others. | |
| • Accept-Encoding: compress, gzip—This header tells the server whether the client can take a gzip or compressed response. | |
| • User-Agent: pauldix-service-client/1.0—In most cases, the user agent field isn’t required. However, some servers reject requests that don’t specify a user agent of some kind. It’s generally part of being a good Internet citizen to specify a user agent that server administrators can find information on. |
| # Don't raise exceptions but return the response | |
| RestClient.get('http://example.com/resource'){|response, request, result| response } | |
| ➔ 404 Resource Not Found | text/html 282 bytes | |
| # Manage a specific error code | |
| RestClient.get('http://my-rest-service.com/resource'){ |response, request, result, &block| | |
| case response.code | |
| when 200 | |
| p "It worked !" | |
| response |
| [Mensch font](http://robey.lag.net/2010/06/21/mensch-font.html), | |
| [Source Code Pro](http://sourceforge.net/projects/sourcecodepro.adobe/files/), | |
| [Webkit](http://webkit.org), | |
| [Chrome](http://google.com/chrome), | |
| [Firefox](http://firefox.com), | |
| [Kaleidoscope](http://www.kaleidoscopeapp.com), | |
| [iTerm](http://iterm2.com), | |
| [Sublime Text](http://www.sublimetext.com/dev), | |
| [Sequel Pro](http://nightly.sequelpro.com), | |
| [Codekit](http://incident57.com/codekit/), |