5 The `process` object is a global object and can be accessed from anywhere.
6 It is an instance of [`EventEmitter`][].
10 This event is emitted when Node.js empties its event loop and has nothing else to
11 schedule. Normally, Node.js exits when there is no work scheduled, but a listener
12 for `'beforeExit'` can make asynchronous calls, and cause Node.js to continue.
14 `'beforeExit'` is not emitted for conditions causing explicit termination, such as
15 [`process.exit()`][] or uncaught exceptions, and should not be used as an
16 alternative to the `'exit'` event unless the intention is to schedule more work.
20 Emitted when the process is about to exit. There is no way to prevent the
21 exiting of the event loop at this point, and once all `'exit'` listeners have
22 finished running the process will exit. Therefore you **must** only perform
23 **synchronous** operations in this handler. This is a good hook to perform
24 checks on the module's state (like for unit tests). The callback takes one
25 argument, the code the process is exiting with.
27 This event is only emitted when Node.js exits explicitly by process.exit() or
28 implicitly by the event loop draining.
30 Example of listening for `'exit'`:
32 process.on('exit', (code) => {
35 console.log('This will not run');
37 console.log('About to exit with code:', code);
42 * `message` {Object} a parsed JSON object or primitive value
43 * `sendHandle` {Handle object} a [`net.Socket`][] or [`net.Server`][] object, or
46 Messages sent by [`ChildProcess.send()`][] are obtained using the `'message'`
47 event on the child's process object.
49 ## Event: 'rejectionHandled'
51 Emitted whenever a Promise was rejected and an error handler was attached to it
52 (for example with `.catch()`) later than after an event loop turn. This event
53 is emitted with the following arguments:
55 - `p` the promise that was previously emitted in an `'unhandledRejection'`
56 event, but which has now gained a rejection handler.
58 There is no notion of a top level for a promise chain at which rejections can
59 always be handled. Being inherently asynchronous in nature, a promise rejection
60 can be handled at a future point in time — possibly much later than the
61 event loop turn it takes for the `'unhandledRejection'` event to be emitted.
63 Another way of stating this is that, unlike in synchronous code where there is
64 an ever-growing list of unhandled exceptions, with promises there is a
65 growing-and-shrinking list of unhandled rejections. In synchronous code, the
66 `'uncaughtException'` event tells you when the list of unhandled exceptions
67 grows. And in asynchronous code, the `'unhandledRejection'` event tells you
68 when the list of unhandled rejections grows, while the `'rejectionHandled'`
69 event tells you when the list of unhandled rejections shrinks.
71 For example using the rejection detection hooks in order to keep a map of all
72 the rejected promise reasons at a given time:
74 const unhandledRejections = new Map();
75 process.on('unhandledRejection', (reason, p) => {
76 unhandledRejections.set(p, reason);
78 process.on('rejectionHandled', (p) => {
79 unhandledRejections.delete(p);
82 This map will grow and shrink over time, reflecting rejections that start
83 unhandled and then become handled. You could record the errors in some error
84 log, either periodically (probably best for long-running programs, allowing
85 you to clear the map, which in the case of a very buggy program could grow
86 indefinitely) or upon process exit (more convenient for scripts).
88 ## Event: 'uncaughtException'
90 Emitted when an exception bubbles all the way back to the event loop. If a
91 listener is added for this exception, the default action (which is to print
92 a stack trace and exit) will not occur.
94 Example of listening for `'uncaughtException'`:
96 process.on('uncaughtException', (err) => {
97 console.log(`Caught exception: ${err}`);
101 console.log('This will still run.');
104 // Intentionally cause an exception, but don't catch it.
106 console.log('This will not run.');
108 Note that `'uncaughtException'` is a very crude mechanism for exception
111 Do *not* use it as the Node.js equivalent of `On Error Resume Next`. An
112 unhandled exception means your application - and by extension Node.js itself -
113 is in an undefined state. Blindly resuming means *anything* could happen.
115 Exceptions thrown from within the event handler will not be caught. Instead the
116 process will exit with a non zero exit code and the stack trace will be printed.
117 This is to avoid infinite recursion.
119 Think of resuming as pulling the power cord when you are upgrading your system.
120 Nine out of ten times nothing happens - but the 10th time, your system is bust.
122 `'uncaughtException'` should be used to perform synchronous cleanup before
123 shutting down the process. It is not safe to resume normal operation after
124 `'uncaughtException'`. If you do use it, restart your application after every
127 You have been warned.
129 ## Event: 'unhandledRejection'
131 Emitted whenever a `Promise` is rejected and no error handler is attached to
132 the promise within a turn of the event loop. When programming with promises
133 exceptions are encapsulated as rejected promises. Such promises can be caught
134 and handled using [`promise.catch(...)`][] and rejections are propagated through
135 a promise chain. This event is useful for detecting and keeping track of
136 promises that were rejected whose rejections were not handled yet. This event
137 is emitted with the following arguments:
139 - `reason` the object with which the promise was rejected (usually an [`Error`][]
141 - `p` the promise that was rejected.
143 Here is an example that logs every unhandled rejection to the console
145 process.on('unhandledRejection', (reason, p) => {
146 console.log("Unhandled Rejection at: Promise ", p, " reason: ", reason);
147 // application specific logging, throwing an error, or other logic here
150 For example, here is a rejection that will trigger the `'unhandledRejection'`
153 somePromise.then((res) => {
154 return reportToUser(JSON.parse(res)); // note the typo
155 }); // no `.catch` or `.then`
157 Here is an example of a coding pattern that will also trigger
158 `'unhandledRejection'`:
160 function SomeResource() {
161 // Initially set the loaded status to a rejected promise
162 this.loaded = Promise.reject(new Error('Resource not yet loaded!'));
165 var resource = new SomeResource();
166 // no .catch or .then on resource.loaded for at least a turn
168 In cases like this, you may not want to track the rejection as a developer
169 error like you would for other `'unhandledRejection'` events. To address
170 this, you can either attach a dummy `.catch(function() { })` handler to
171 `resource.loaded`, preventing the `'unhandledRejection'` event from being
172 emitted, or you can use the [`'rejectionHandled'`][] event.
176 Node.js will normally exit with a `0` status code when no more async
177 operations are pending. The following status codes are used in other
180 * `1` **Uncaught Fatal Exception** - There was an uncaught exception,
181 and it was not handled by a domain or an `'uncaughtException'` event
183 * `2` - Unused (reserved by Bash for builtin misuse)
184 * `3` **Internal JavaScript Parse Error** - The JavaScript source code
185 internal in Node.js's bootstrapping process caused a parse error. This
186 is extremely rare, and generally can only happen during development
188 * `4` **Internal JavaScript Evaluation Failure** - The JavaScript
189 source code internal in Node.js's bootstrapping process failed to
190 return a function value when evaluated. This is extremely rare, and
191 generally can only happen during development of Node.js itself.
192 * `5` **Fatal Error** - There was a fatal unrecoverable error in V8.
193 Typically a message will be printed to stderr with the prefix `FATAL
195 * `6` **Non-function Internal Exception Handler** - There was an
196 uncaught exception, but the internal fatal exception handler
197 function was somehow set to a non-function, and could not be called.
198 * `7` **Internal Exception Handler Run-Time Failure** - There was an
199 uncaught exception, and the internal fatal exception handler
200 function itself threw an error while attempting to handle it. This
201 can happen, for example, if a `process.on('uncaughtException')` or
202 `domain.on('error')` handler throws an error.
203 * `8` - Unused. In previous versions of Node.js, exit code 8 sometimes
204 indicated an uncaught exception.
205 * `9` - **Invalid Argument** - Either an unknown option was specified,
206 or an option requiring a value was provided without a value.
207 * `10` **Internal JavaScript Run-Time Failure** - The JavaScript
208 source code internal in Node.js's bootstrapping process threw an error
209 when the bootstrapping function was called. This is extremely rare,
210 and generally can only happen during development of Node.js itself.
211 * `12` **Invalid Debug Argument** - The `--debug` and/or `--debug-brk`
212 options were set, but an invalid port number was chosen.
213 * `>128` **Signal Exits** - If Node.js receives a fatal signal such as
214 `SIGKILL` or `SIGHUP`, then its exit code will be `128` plus the
215 value of the signal code. This is a standard Unix practice, since
216 exit codes are defined to be 7-bit integers, and signal exits set
217 the high-order bit, and then contain the value of the signal code.
222 <!--name=SIGINT, SIGHUP, etc.-->
224 Emitted when the processes receives a signal. See sigaction(2) for a list of
225 standard POSIX signal names such as `SIGINT`, `SIGHUP`, etc.
227 Example of listening for `SIGINT`:
229 // Start reading from stdin so we don't exit.
230 process.stdin.resume();
232 process.on('SIGINT', () => {
233 console.log('Got SIGINT. Press Control-D to exit.');
236 An easy way to send the `SIGINT` signal is with `Control-C` in most terminal
241 - `SIGUSR1` is reserved by Node.js to start the debugger. It's possible to
242 install a listener but that won't stop the debugger from starting.
243 - `SIGTERM` and `SIGINT` have default handlers on non-Windows platforms that resets
244 the terminal mode before exiting with code `128 + signal number`. If one of
245 these signals has a listener installed, its default behavior will be removed
246 (Node.js will no longer exit).
247 - `SIGPIPE` is ignored by default. It can have a listener installed.
248 - `SIGHUP` is generated on Windows when the console window is closed, and on other
249 platforms under various similar conditions, see signal(7). It can have a
250 listener installed, however Node.js will be unconditionally terminated by
251 Windows about 10 seconds later. On non-Windows platforms, the default
252 behavior of `SIGHUP` is to terminate Node.js, but once a listener has been
253 installed its default behavior will be removed.
254 - `SIGTERM` is not supported on Windows, it can be listened on.
255 - `SIGINT` from the terminal is supported on all platforms, and can usually be
256 generated with `CTRL+C` (though this may be configurable). It is not generated
257 when terminal raw mode is enabled.
258 - `SIGBREAK` is delivered on Windows when `CTRL+BREAK` is pressed, on non-Windows
259 platforms it can be listened on, but there is no way to send or generate it.
260 - `SIGWINCH` is delivered when the console has been resized. On Windows, this will
261 only happen on write to the console when the cursor is being moved, or when a
262 readable tty is used in raw mode.
263 - `SIGKILL` cannot have a listener installed, it will unconditionally terminate
264 Node.js on all platforms.
265 - `SIGSTOP` cannot have a listener installed.
267 Note that Windows does not support sending Signals, but Node.js offers some
268 emulation with `process.kill()`, and `child_process.kill()`. Sending signal `0`
269 can be used to test for the existence of a process. Sending `SIGINT`,
270 `SIGTERM`, and `SIGKILL` cause the unconditional termination of the target
275 This causes Node.js to emit an abort. This will cause Node.js to exit and
276 generate a core file.
280 What processor architecture you're running on: `'arm'`, `'ia32'`, or `'x64'`.
282 console.log('This processor architecture is ' + process.arch);
286 An array containing the command line arguments. The first element will be
287 'node', the second element will be the name of the JavaScript file. The
288 next elements will be any additional command line arguments.
290 // print process.argv
291 process.argv.forEach((val, index, array) => {
292 console.log(`${index}: ${val}`);
297 $ node process-2.js one two=three four
299 1: /Users/mjr/work/node/process-2.js
304 ## process.chdir(directory)
306 Changes the current working directory of the process or throws an exception if that fails.
308 console.log(`Starting directory: ${process.cwd()}`);
310 process.chdir('/tmp');
311 console.log(`New directory: ${process.cwd()}`);
314 console.log(`chdir: ${err}`);
319 An Object containing the JavaScript representation of the configure options
320 that were used to compile the current Node.js executable. This is the same as
321 the `config.gypi` file that was produced when running the `./configure` script.
323 An example of the possible output looks like:
327 default_configuration: 'Release',
333 node_install_npm: 'true',
335 node_shared_cares: 'false',
336 node_shared_http_parser: 'false',
337 node_shared_libuv: 'false',
338 node_shared_zlib: 'false',
339 node_use_dtrace: 'false',
340 node_use_openssl: 'true',
341 node_shared_openssl: 'false',
342 strict_aliasing: 'true',
344 v8_use_snapshot: 'true' } }
348 * {Boolean} Set to false after `process.disconnect()` is called
350 If `process.connected` is false, it is no longer possible to send messages.
354 Returns the current working directory of the process.
356 console.log(`Current directory: ${process.cwd()}`);
358 ## process.disconnect()
360 Close the IPC channel to the parent process, allowing this child to exit
361 gracefully once there are no other connections keeping it alive.
363 Identical to the parent process's [`ChildProcess.disconnect()`][].
365 If Node.js was not spawned with an IPC channel, `process.disconnect()` will be
370 An object containing the user environment. See environ(7).
372 An example of this object looks like:
374 { TERM: 'xterm-256color',
375 SHELL: '/usr/local/bin/bash',
377 PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin',
378 PWD: '/Users/maciej',
381 HOME: '/Users/maciej',
383 _: '/usr/local/bin/node' }
385 You can write to this object, but changes won't be reflected outside of your
386 process. That means that the following won't work:
388 $ node -e 'process.env.foo = "bar"' && echo $foo
392 process.env.foo = 'bar';
393 console.log(process.env.foo);
395 Assigning a property on `process.env` will implicitly convert the value
401 process.env.test = null;
402 console.log(process.env.test);
404 process.env.test = undefined;
405 console.log(process.env.test);
409 Use `delete` to delete a property from `process.env`.
414 process.env.TEST = 1;
415 delete process.env.TEST;
416 console.log(process.env.TEST);
422 This is the set of Node.js-specific command line options from the
423 executable that started the process. These options do not show up in
424 `process.argv`, and do not include the Node.js executable, the name of
425 the script, or any options following the script name. These options
426 are useful in order to spawn child processes with the same execution
427 environment as the parent.
431 $ node --harmony script.js --version
433 results in process.execArgv:
439 ['/usr/local/bin/node', 'script.js', '--version']
443 This is the absolute pathname of the executable that started the process.
450 ## process.exit([code])
452 Ends the process with the specified `code`. If omitted, exit uses the
455 To exit with a 'failure' code:
459 The shell that executed Node.js should see the exit code as 1.
464 A number which will be the process exit code, when the process either
465 exits gracefully, or is exited via [`process.exit()`][] without specifying
468 Specifying a code to `process.exit(code)` will override any previous
469 setting of `process.exitCode`.
474 Note: this function is only available on POSIX platforms (i.e. not Windows,
477 Gets the effective group identity of the process. (See getegid(2).)
478 This is the numerical group id, not the group name.
480 if (process.getegid) {
481 console.log(`Current gid: ${process.getegid()}`);
487 Note: this function is only available on POSIX platforms (i.e. not Windows,
490 Gets the effective user identity of the process. (See geteuid(2).)
491 This is the numerical userid, not the username.
493 if (process.geteuid) {
494 console.log(`Current uid: ${process.geteuid()}`);
499 Note: this function is only available on POSIX platforms (i.e. not Windows,
502 Gets the group identity of the process. (See getgid(2).)
503 This is the numerical group id, not the group name.
505 if (process.getgid) {
506 console.log(`Current gid: ${process.getgid()}`);
509 ## process.getgroups()
511 Note: this function is only available on POSIX platforms (i.e. not Windows,
514 Returns an array with the supplementary group IDs. POSIX leaves it unspecified
515 if the effective group ID is included but Node.js ensures it always is.
519 Note: this function is only available on POSIX platforms (i.e. not Windows,
522 Gets the user identity of the process. (See getuid(2).)
523 This is the numerical userid, not the username.
525 if (process.getuid) {
526 console.log(`Current uid: ${process.getuid()}`);
531 Returns the current high-resolution real time in a `[seconds, nanoseconds]`
532 tuple Array. It is relative to an arbitrary time in the past. It is not
533 related to the time of day and therefore not subject to clock drift. The
534 primary use is for measuring performance between intervals.
536 You may pass in the result of a previous call to `process.hrtime()` to get
537 a diff reading, useful for benchmarks and measuring intervals:
539 var time = process.hrtime();
543 var diff = process.hrtime(time);
546 console.log('benchmark took %d nanoseconds', diff[0] * 1e9 + diff[1]);
547 // benchmark took 1000000527 nanoseconds
551 ## process.initgroups(user, extra_group)
553 Note: this function is only available on POSIX platforms (i.e. not Windows,
556 Reads /etc/group and initializes the group access list, using all groups of
557 which the user is a member. This is a privileged operation, meaning you need
558 to be root or have the `CAP_SETGID` capability.
560 `user` is a user name or user ID. `extra_group` is a group name or group ID.
562 Some care needs to be taken when dropping privileges. Example:
564 console.log(process.getgroups()); // [ 0 ]
565 process.initgroups('bnoordhuis', 1000); // switch user
566 console.log(process.getgroups()); // [ 27, 30, 46, 1000, 0 ]
567 process.setgid(1000); // drop root gid
568 console.log(process.getgroups()); // [ 27, 30, 46, 1000 ]
570 ## process.kill(pid[, signal])
572 Send a signal to a process. `pid` is the process id and `signal` is the
573 string describing the signal to send. Signal names are strings like
574 `SIGINT` or `SIGHUP`. If omitted, the signal will be `SIGTERM`.
575 See [Signal Events][] and kill(2) for more information.
577 Will throw an error if target does not exist, and as a special case, a signal
578 of `0` can be used to test for the existence of a process. Windows platforms
579 will throw an error if the `pid` is used to kill a process group.
581 Note that even though the name of this function is `process.kill`, it is really
582 just a signal sender, like the `kill` system call. The signal sent may do
583 something other than kill the target process.
585 Example of sending a signal to yourself:
587 process.on('SIGHUP', () => {
588 console.log('Got SIGHUP signal.');
592 console.log('Exiting.');
596 process.kill(process.pid, 'SIGHUP');
598 Note: When SIGUSR1 is received by Node.js it starts the debugger, see
601 ## process.mainModule
603 Alternate way to retrieve [`require.main`][]. The difference is that if the main
604 module changes at runtime, `require.main` might still refer to the original main
605 module in modules that were required before the change occurred. Generally it's
606 safe to assume that the two refer to the same module.
608 As with `require.main`, it will be `undefined` if there was no entry script.
610 ## process.memoryUsage()
612 Returns an object describing the memory usage of the Node.js process
615 const util = require('util');
617 console.log(util.inspect(process.memoryUsage()));
625 `heapTotal` and `heapUsed` refer to V8's memory usage.
628 ## process.nextTick(callback[, arg][, ...])
630 * `callback` {Function}
632 Once the current event loop turn runs to completion, call the callback
635 This is *not* a simple alias to [`setTimeout(fn, 0)`][], it's much more
636 efficient. It runs before any additional I/O events (including
637 timers) fire in subsequent ticks of the event loop.
639 console.log('start');
640 process.nextTick(() => {
641 console.log('nextTick callback');
643 console.log('scheduled');
649 This is important in developing APIs where you want to give the user the
650 chance to assign event handlers after an object has been constructed,
651 but before any I/O has occurred.
653 function MyThing(options) {
654 this.setupOptions(options);
656 process.nextTick(() => {
657 this.startDoingStuff();
661 var thing = new MyThing();
662 thing.getReadyForStuff();
664 // thing.startDoingStuff() gets called now, not before.
666 It is very important for APIs to be either 100% synchronous or 100%
667 asynchronous. Consider this example:
669 // WARNING! DO NOT USE! BAD UNSAFE HAZARD!
670 function maybeSync(arg, cb) {
679 This API is hazardous. If you do this:
681 maybeSync(true, function() {
686 then it's not clear whether `foo()` or `bar()` will be called first.
688 This approach is much better:
690 function definitelyAsync(arg, cb) {
692 process.nextTick(cb);
699 Note: the nextTick queue is completely drained on each pass of the
700 event loop **before** additional I/O is processed. As a result,
701 recursively setting nextTick callbacks will block any I/O from
702 happening, just like a `while(true);` loop.
706 The PID of the process.
708 console.log(`This process is pid ${process.pid}`);
712 What platform you're running on:
713 `'darwin'`, `'freebsd'`, `'linux'`, `'sunos'` or `'win32'`
715 console.log(`This platform is ${process.platform}`);
719 An Object containing metadata related to the current release, including URLs
720 for the source tarball and headers-only tarball.
722 `process.release` contains the following properties:
724 * `name`: a string with a value that will always be `'node'` for Node.js. For
725 legacy io.js releases, this will be `'io.js'`.
726 * `sourceUrl`: a complete URL pointing to a _.tar.gz_ file containing the
727 source of the current release.
728 * `headersUrl`: a complete URL pointing to a _.tar.gz_ file containing only
729 the header files for the current release. This file is significantly smaller
730 than the full source file and can be used for compiling add-ons against
732 * `libUrl`: a complete URL pointing to an _node.lib_ file matching the
733 architecture and version of the current release. This file is used for
734 compiling add-ons against Node.js. _This property is only present on Windows
735 builds of Node.js and will be missing on all other platforms._
740 sourceUrl: 'https://nodejs.org/download/release/v4.0.0/node-v4.0.0.tar.gz',
741 headersUrl: 'https://nodejs.org/download/release/v4.0.0/node-v4.0.0-headers.tar.gz',
742 libUrl: 'https://nodejs.org/download/release/v4.0.0/win-x64/node.lib' }
744 In custom builds from non-release versions of the source tree, only the
745 `name` property may be present. The additional properties should not be
746 relied upon to exist.
748 ## process.send(message[, sendHandle][, callback])
751 * `sendHandle` {Handle object}
752 * `callback` {Function}
755 When Node.js is spawned with an IPC channel attached, it can send messages to its
756 parent process using `process.send()`. Each will be received as a
757 [`'message'`][] event on the parent's `ChildProcess` object.
759 If Node.js was not spawned with an IPC channel, `process.send()` will be undefined.
761 ## process.setegid(id)
763 Note: this function is only available on POSIX platforms (i.e. not Windows,
766 Sets the effective group identity of the process. (See setegid(2).)
767 This accepts either a numerical ID or a groupname string. If a groupname
768 is specified, this method blocks while resolving it to a numerical ID.
770 if (process.getegid && process.setegid) {
771 console.log(`Current gid: ${process.getegid()}`);
773 process.setegid(501);
774 console.log(`New gid: ${process.getegid()}`);
777 console.log(`Failed to set gid: ${err}`);
781 ## process.seteuid(id)
783 Note: this function is only available on POSIX platforms (i.e. not Windows,
786 Sets the effective user identity of the process. (See seteuid(2).)
787 This accepts either a numerical ID or a username string. If a username
788 is specified, this method blocks while resolving it to a numerical ID.
790 if (process.geteuid && process.seteuid) {
791 console.log(`Current uid: ${process.geteuid()}`);
793 process.seteuid(501);
794 console.log(`New uid: ${process.geteuid()}`);
797 console.log(`Failed to set uid: ${err}`);
801 ## process.setgid(id)
803 Note: this function is only available on POSIX platforms (i.e. not Windows,
806 Sets the group identity of the process. (See setgid(2).) This accepts either
807 a numerical ID or a groupname string. If a groupname is specified, this method
808 blocks while resolving it to a numerical ID.
810 if (process.getgid && process.setgid) {
811 console.log(`Current gid: ${process.getgid()}`);
814 console.log(`New gid: ${process.getgid()}`);
817 console.log(`Failed to set gid: ${err}`);
821 ## process.setgroups(groups)
823 Note: this function is only available on POSIX platforms (i.e. not Windows,
826 Sets the supplementary group IDs. This is a privileged operation, meaning you
827 need to be root or have the `CAP_SETGID` capability.
829 The list can contain group IDs, group names or both.
831 ## process.setuid(id)
833 Note: this function is only available on POSIX platforms (i.e. not Windows,
836 Sets the user identity of the process. (See setuid(2).) This accepts either
837 a numerical ID or a username string. If a username is specified, this method
838 blocks while resolving it to a numerical ID.
840 if (process.getuid && process.setuid) {
841 console.log(`Current uid: ${process.getuid()}`);
844 console.log(`New uid: ${process.getuid()}`);
847 console.log(`Failed to set uid: ${err}`);
853 A writable stream to stderr (on fd `2`).
855 `process.stderr` and `process.stdout` are unlike other streams in Node.js in
856 that they cannot be closed (`end()` will throw), they never emit the `finish`
857 event and that writes can block when output is redirected to a file (although
858 disks are fast and operating systems normally employ write-back caching so it
859 should be a very rare occurrence indeed.)
863 A `Readable Stream` for stdin (on fd `0`).
865 Example of opening standard input and listening for both events:
867 process.stdin.setEncoding('utf8');
869 process.stdin.on('readable', () => {
870 var chunk = process.stdin.read();
871 if (chunk !== null) {
872 process.stdout.write(`data: ${chunk}`);
876 process.stdin.on('end', () => {
877 process.stdout.write('end');
880 As a Stream, `process.stdin` can also be used in "old" mode that is compatible
881 with scripts written for node.js prior to v0.10.
882 For more information see [Stream compatibility][].
884 In "old" Streams mode the stdin stream is paused by default, so one
885 must call `process.stdin.resume()` to read from it. Note also that calling
886 `process.stdin.resume()` itself would switch stream to "old" mode.
888 If you are starting a new project you should prefer a more recent "new" Streams
893 A `Writable Stream` to `stdout` (on fd `1`).
895 For example, a `console.log` equivalent could look like this:
897 console.log = function(msg) {
898 process.stdout.write(`${msg}\n`);
901 `process.stderr` and `process.stdout` are unlike other streams in Node.js in
902 that they cannot be closed (`end()` will throw), they never emit the `'finish'`
903 event and that writes can block when output is redirected to a file (although
904 disks are fast and operating systems normally employ write-back caching so it
905 should be a very rare occurrence indeed.)
907 To check if Node.js is being run in a TTY context, read the `isTTY` property
908 on `process.stderr`, `process.stdout`, or `process.stdin`:
910 $ node -p "Boolean(process.stdin.isTTY)"
912 $ echo "foo" | node -p "Boolean(process.stdin.isTTY)"
915 $ node -p "Boolean(process.stdout.isTTY)"
917 $ node -p "Boolean(process.stdout.isTTY)" | cat
920 See [the tty docs][] for more information.
924 Getter/setter to set what is displayed in `ps`.
926 When used as a setter, the maximum length is platform-specific and probably
929 On Linux and OS X, it's limited to the size of the binary name plus the
930 length of the command line arguments because it overwrites the argv memory.
932 v0.8 allowed for longer process title strings by also overwriting the environ
933 memory but that was potentially insecure/confusing in some (rather obscure)
936 ## process.umask([mask])
938 Sets or reads the process's file mode creation mask. Child processes inherit
939 the mask from the parent process. Returns the old mask if `mask` argument is
940 given, otherwise returns the current mask.
942 const newmask = 0o022;
943 const oldmask = process.umask(newmask);
945 `Changed umask from ${oldmask.toString(8)} to ${newmask.toString(8)}`
951 Number of seconds Node.js has been running.
955 A compiled-in property that exposes `NODE_VERSION`.
957 console.log(`Version: ${process.version}`);
961 A property exposing version strings of Node.js and its dependencies.
963 console.log(process.versions);
965 Will print something like:
967 { http_parser: '2.3.0',
977 [`'message'`]: child_process.html#child_process_event_message
978 [`ChildProcess.disconnect()`]: child_process.html#child_process_child_disconnect
979 [`ChildProcess.send()`]: child_process.html#child_process_child_send_message_sendhandle_callback
980 [`Error`]: errors.html#errors_class_error
981 [`EventEmitter`]: events.html#events_class_events_eventemitter
982 [`net.Server`]: net.html#net_class_net_server
983 [`net.Socket`]: net.html#net_class_net_socket
984 [`process.exit()`]: #process_process_exit_code
985 [`promise.catch(...)`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/catch
986 [`'rejectionHandled'`]: #process_event_rejectionhandled
987 [`require.main`]: modules.html#modules_accessing_the_main_module
988 [`setTimeout(fn, 0)`]: timers.html#timers_settimeout_callback_delay_arg
989 [Signal Events]: #process_signal_events
990 [Stream compatibility]: stream.html#stream_compatibility_with_older_node_js_versions
991 [the tty docs]: tty.html#tty_tty