doc: change Mac OS X to macOS

BUILDING.md

@@ -74,7 +74,7 @@ Depending on host platform, the selection of toolchains may vary.
 
 ## Building Node.js on supported platforms
 
-### Unix / OS X
+### Unix / macOS
 
 Prerequisites:
 
@@ -83,7 +83,7 @@ Prerequisites:
 * Python 2.6 or 2.7
 * GNU Make 3.81 or newer
 
-On OS X, you will also need:
+On macOS, you will also need:
 * [Xcode](https://developer.apple.com/xcode/download/)
   - You also need to install the `Command Line Tools` via Xcode. You can find
     this under the menu `Xcode -> Preferences -> Downloads`
@@ -237,7 +237,7 @@ With the `--download=all`, this may download ICU if you don't have an
 ICU in `deps/icu`. (The embedded `small-icu` included in the default
 Node.js source does not include all locales.)
 
-##### Unix / OS X:
+##### Unix / macOS:
 
 ```console
 $ ./configure --with-intl=full-icu --download=all
@@ -254,7 +254,7 @@ $ ./configure --with-intl=full-icu --download=all
 The `Intl` object will not be available, nor some other APIs such as
 `String.normalize`.
 
-##### Unix / OS X:
+##### Unix / macOS:
 
 ```console
 $ ./configure --without-intl
@@ -266,7 +266,7 @@ $ ./configure --without-intl
 > .\vcbuild without-intl
 ```
 
-#### Use existing installed ICU (Unix / OS X only):
+#### Use existing installed ICU (Unix / macOS only):
 
 ```console
 $ pkg-config --modversion icu-i18n && ./configure --with-intl=system-icu
@@ -282,7 +282,7 @@ You can find other ICU releases at
 Download the file named something like `icu4c-**##.#**-src.tgz` (or
 `.zip`).
 
-##### Unix / OS X
+##### Unix / macOS
 
 From an already-unpacked ICU:
 ```console

CONTRIBUTING.md

@@ -157,7 +157,7 @@ Bug fixes and features **should come with tests**. Add your tests in the
 project, see this [guide](./doc/guides/writing-tests.md). Looking at other tests
 to see how they should be structured can also help.
 
-To run the tests on Unix / OS X:
+To run the tests on Unix / macOS:
 
 ```text
 $ ./configure && make -j4 test

doc/STYLE_GUIDE.md

@@ -39,7 +39,7 @@
 * When documenting APIs, note the version the API was introduced in at
   the end of the section. If an API has been deprecated, also note the first
   version that the API appeared deprecated in.
-* When using dashes, use emdashes ("—", Ctrl+Alt+"-" on OSX) surrounded by
+* When using dashes, use emdashes ("—", Ctrl+Alt+"-" on macOS) surrounded by
   spaces, per the New York Times usage.
 * Including assets:
   * If you wish to add an illustration or full program, add it to the

doc/api/child_process.md

@@ -75,7 +75,7 @@ when the child process terminates.
 
 The importance of the distinction between [`child_process.exec()`][] and
 [`child_process.execFile()`][] can vary based on platform. On Unix-type operating
-systems (Unix, Linux, OSX) [`child_process.execFile()`][] can be more efficient
+systems (Unix, Linux, macOS) [`child_process.execFile()`][] can be more efficient
 because it does not spawn a shell. On Windows, however, `.bat` and `.cmd`
 files are not executable on their own without a terminal, and therefore cannot
 be launched using [`child_process.execFile()`][]. When running on Windows, `.bat`
@@ -433,7 +433,7 @@ child.on('error', (err) => {
 });
 ```
 
-*Note: Certain platforms (OS X, Linux) will use the value of `argv[0]` for the
+*Note: Certain platforms (macOS, Linux) will use the value of `argv[0]` for the
 process title while others (Windows, SunOS) will use `command`.*
 
 *Note: Node.js currently overwrites `argv[0]` with `process.execPath` on

doc/api/documentation.md

@@ -73,11 +73,11 @@ like `fs.open()`, will document that. The docs link to the corresponding man
 pages (short for manual pages) which describe how the syscalls work.
 
 **Caveat:** some syscalls, like lchown(2), are BSD-specific. That means, for
-example, that `fs.lchown()` only works on Mac OS X and other BSD-derived systems,
+example, that `fs.lchown()` only works on macOS and other BSD-derived systems,
 and is not available on Linux.
 
 Most Unix syscalls have Windows equivalents, but behavior may differ on Windows
-relative to Linux and OS X. For an example of the subtle ways in which it's
+relative to Linux and macOS. For an example of the subtle ways in which it's
 sometimes impossible to replace Unix syscall semantics on Windows, see [Node
 issue 4760](https://github.com/nodejs/node/issues/4760).
 

doc/api/errors.md

@@ -523,7 +523,7 @@ found [here][online].
   [file descriptors][] allowable on the system has been reached, and
   requests for another descriptor cannot be fulfilled until at least one
   has been closed. This is encountered when opening many files at once in
-  parallel, especially on systems (in particular, OS X) where there is a low
+  parallel, especially on systems (in particular, macOS) where there is a low
   file descriptor limit for processes. To remedy a low limit, run
   `ulimit -n 2048` in the same shell that will run the Node.js process.
 

doc/api/fs.md

@@ -1099,7 +1099,7 @@ changes:
 Asynchronous lchmod(2). No arguments other than a possible exception
 are given to the completion callback.
 
-Only available on Mac OS X.
+Only available on macOS.
 
 ## fs.lchmodSync(path, mode)
 <!-- YAML
@@ -1374,12 +1374,12 @@ The kernel ignores the position argument and always appends the data to
 the end of the file.
 
 _Note: The behavior of `fs.open()` is platform specific for some flags. As such,
-opening a directory on OS X and Linux with the `'a+'` flag - see example below -
-will return an error. In contrast, on Windows and FreeBSD, a file descriptor
-will be returned._
+opening a directory on macOS and Linux with the `'a+'` flag - see example
+below - will return an error. In contrast, on Windows and FreeBSD, a file
+descriptor will be returned._
 
 ```js
-// OS X and Linux
+// macOS and Linux
 fs.open('<directory>', 'a+', (err, fd) => {
   // => [Error: EISDIR: illegal operation on a directory, open <directory>]
 });
@@ -1943,7 +1943,7 @@ Also note the listener callback is attached to the `'change'` event fired by
 The `fs.watch` API is not 100% consistent across platforms, and is
 unavailable in some situations.
 
-The recursive option is only supported on OS X and Windows.
+The recursive option is only supported on macOS and Windows.
 
 #### Availability
 
@@ -1954,7 +1954,7 @@ to be notified of filesystem changes.
 
 * On Linux systems, this uses [`inotify`]
 * On BSD systems, this uses [`kqueue`]
-* On OS X, this uses [`kqueue`] for files and [`FSEvents`] for directories.
+* On macOS, this uses [`kqueue`] for files and [`FSEvents`] for directories.
 * On SunOS systems (including Solaris and SmartOS), this uses [`event ports`].
 * On Windows systems, this feature depends on [`ReadDirectoryChangesW`].
 * On Aix systems, this feature depends on [`AHAFS`], which must be enabled.
@@ -1972,7 +1972,7 @@ less reliable.
 
 <!--type=misc-->
 
-On Linux and OS X systems, `fs.watch()` resolves the path to an [inode][] and
+On Linux and macOS systems, `fs.watch()` resolves the path to an [inode][] and
 watches the inode. If the watched path is deleted and recreated, it is assigned
 a new inode. The watch will emit an event for the delete but will continue
 watching the *original* inode. Events for the new inode will not be emitted.
@@ -1982,7 +1982,7 @@ In AIX, save and close of a file being watched causes two notifications -
 one for adding new content, and one for truncation. Moreover, save and
 close operations on some platforms cause inode changes that force watch
 operations to become invalid and ineffective. AIX retains inode for the
-lifetime of a file, that way though this is different from Linux / OS X,
+lifetime of a file, that way though this is different from Linux / macOS,
 this improves the usability of file watching. This is expected behavior.
 
 #### Filename Argument

doc/api/net.md

@@ -25,7 +25,7 @@ sockets on other operating systems.
 On UNIX, the local domain is also known as the UNIX domain. The path is a
 filesystem path name. It gets truncated to `sizeof(sockaddr_un.sun_path) - 1`,
 which varies on different operating system between 91 and 107 bytes.
-The typical values are 107 on Linux and 103 on OS X. The path is
+The typical values are 107 on Linux and 103 on macOS. The path is
 subject to the same naming conventions and permissions checks as would be done
 on file creation. It will be visible in the filesystem, and will *persist until
 unlinked*.

doc/api/os.md

@@ -363,7 +363,7 @@ added: v0.3.3
 * Returns: {string}
 
 The `os.type()` method returns a string identifying the operating system name
-as returned by uname(3). For example `'Linux'` on Linux, `'Darwin'` on OS X and
+as returned by uname(3). For example `'Linux'` on Linux, `'Darwin'` on macOS and
 `'Windows_NT'` on Windows.
 
 Please see https://en.wikipedia.org/wiki/Uname#Examples for additional

doc/api/process.md

@@ -1631,12 +1631,12 @@ the current value of `ps`.
 
 *Note*: When a new value is assigned, different platforms will impose different
 maximum length restrictions on the title. Usually such restrictions are quite
-limited. For instance, on Linux and OS X, `process.title` is limited to the size
-of the binary name plus the length of the command line arguments because setting
-the `process.title` overwrites the `argv` memory of the process. Node.js v0.8
-allowed for longer process title strings by also overwriting the `environ`
-memory but that was potentially insecure and confusing in some (rather obscure)
-cases.
+limited. For instance, on Linux and macOS, `process.title` is limited to the
+size of the binary name plus the length of the command line arguments because
+setting the `process.title` overwrites the `argv` memory of the process.
+Node.js v0.8 allowed for longer process title strings by also overwriting the
+`environ` memory but that was potentially insecure and confusing in some
+(rather obscure) cases.
 
 ## process.umask([mask])
 <!-- YAML

doc/releases.md

@@ -188,13 +188,13 @@ Perform some smoke-testing. We have [citgm](https://github.com/nodejs/citgm) for
 
 If there is a reason to produce a test release for the purpose of having others try out installers or specifics of builds, produce a nightly build using **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** and wait for it to drop in <https://nodejs.org/download/nightly/>. Follow the directions and enter a proper length commit SHA, enter a date string, and select "nightly" for "disttype".
 
-This is particularly recommended if there has been recent work relating to the OS X or Windows installers as they are not tested in any way by CI.
+This is particularly recommended if there has been recent work relating to the macOS or Windows installers as they are not tested in any way by CI.
 
 ### 8. Produce Release Builds
 
 Use **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** to produce release artifacts. Enter the commit that you want to build from and select "release" for "disttype".
 
-Artifacts from each slave are uploaded to Jenkins and are available if further testing is required. Use this opportunity particularly to test OS X and Windows installers if there are any concerns. Click through to the individual slaves for a run to find the artifacts.
+Artifacts from each slave are uploaded to Jenkins and are available if further testing is required. Use this opportunity particularly to test macOS and Windows installers if there are any concerns. Click through to the individual slaves for a run to find the artifacts.
 
 All release slaves should achieve "SUCCESS" (and be green, not red). A release with failures should not be promoted as there are likely problems to be investigated.
 
@@ -204,7 +204,7 @@ If you have an error on Windows and need to start again, be aware that you'll ge
 
 ARMv7 takes the longest to compile. Unfortunately ccache isn't as effective on release builds, I think it's because of the additional macro settings that go in to a release build that nullify previous builds. Also most of the release build machines are separate to the test build machines so they don't get any benefit from ongoing compiles between releases. You can expect 1.5 hours for the ARMv7 builder to complete and you should normally wait for this to finish. It is possible to rush a release out if you want and add additional builds later but we normally provide ARMv7 from initial promotion.
 
-You do not have to wait for the ARMv6 / Raspberry PI builds if they take longer than the others. It is only necessary to have the main Linux (x64 and x86), OS X .pkg and .tar.gz, Windows (x64 and x86) .msi and .exe, source, headers and docs (both produced currently by an OS X slave). **If you promote builds _before_ ARM builds have finished, you must repeat the promotion step for the ARM builds when they are ready**.
+You do not have to wait for the ARMv6 / Raspberry PI builds if they take longer than the others. It is only necessary to have the main Linux (x64 and x86), macOS .pkg and .tar.gz, Windows (x64 and x86) .msi and .exe, source, headers and docs (both produced currently by an macOS slave). **If you promote builds _before_ ARM builds have finished, you must repeat the promotion step for the ARM builds when they are ready**.
 
 ### 9. Test the Build
 

test/README.md

@@ -292,7 +292,7 @@ Platform check for Linux on PowerPC.
 ### isOSX
 * return [<Boolean>](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#Boolean_type)
 
-Platform check for OS X.
+Platform check for macOS.
 
 ### isSunOS
 * return [<Boolean>](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#Boolean_type)