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. Below is an
173 explanation of how to do that.
177 Node.js will normally exit with a `0` status code when no more async
178 operations are pending. The following status codes are used in other
181 * `1` **Uncaught Fatal Exception** - There was an uncaught exception,
182 and it was not handled by a domain or an `'uncaughtException'` event
184 * `2` - Unused (reserved by Bash for builtin misuse)
185 * `3` **Internal JavaScript Parse Error** - The JavaScript source code
186 internal in Node.js's bootstrapping process caused a parse error. This
187 is extremely rare, and generally can only happen during development
189 * `4` **Internal JavaScript Evaluation Failure** - The JavaScript
190 source code internal in Node.js's bootstrapping process failed to
191 return a function value when evaluated. This is extremely rare, and
192 generally can only happen during development of Node.js itself.
193 * `5` **Fatal Error** - There was a fatal unrecoverable error in V8.
194 Typically a message will be printed to stderr with the prefix `FATAL
196 * `6` **Non-function Internal Exception Handler** - There was an
197 uncaught exception, but the internal fatal exception handler
198 function was somehow set to a non-function, and could not be called.
199 * `7` **Internal Exception Handler Run-Time Failure** - There was an
200 uncaught exception, and the internal fatal exception handler
201 function itself threw an error while attempting to handle it. This
202 can happen, for example, if a `process.on('uncaughtException')` or
203 `domain.on('error')` handler throws an error.
204 * `8` - Unused. In previous versions of Node.js, exit code 8 sometimes
205 indicated an uncaught exception.
206 * `9` - **Invalid Argument** - Either an unknown option was specified,
207 or an option requiring a value was provided without a value.
208 * `10` **Internal JavaScript Run-Time Failure** - The JavaScript
209 source code internal in Node.js's bootstrapping process threw an error
210 when the bootstrapping function was called. This is extremely rare,
211 and generally can only happen during development of Node.js itself.
212 * `12` **Invalid Debug Argument** - The `--debug` and/or `--debug-brk`
213 options were set, but an invalid port number was chosen.
214 * `>128` **Signal Exits** - If Node.js receives a fatal signal such as
215 `SIGKILL` or `SIGHUP`, then its exit code will be `128` plus the
216 value of the signal code. This is a standard Unix practice, since
217 exit codes are defined to be 7-bit integers, and signal exits set
218 the high-order bit, and then contain the value of the signal code.
223 <!--name=SIGINT, SIGHUP, etc.-->
225 Emitted when the processes receives a signal. See sigaction(2) for a list of
226 standard POSIX signal names such as `SIGINT`, `SIGHUP`, etc.
228 Example of listening for `SIGINT`:
230 // Start reading from stdin so we don't exit.
231 process.stdin.resume();
233 process.on('SIGINT', () => {
234 console.log('Got SIGINT. Press Control-D to exit.');
237 An easy way to send the `SIGINT` signal is with `Control-C` in most terminal
242 - `SIGUSR1` is reserved by Node.js to start the debugger. It's possible to
243 install a listener but that won't stop the debugger from starting.
244 - `SIGTERM` and `SIGINT` have default handlers on non-Windows platforms that resets
245 the terminal mode before exiting with code `128 + signal number`. If one of
246 these signals has a listener installed, its default behavior will be removed
247 (Node.js will no longer exit).
248 - `SIGPIPE` is ignored by default. It can have a listener installed.
249 - `SIGHUP` is generated on Windows when the console window is closed, and on other
250 platforms under various similar conditions, see signal(7). It can have a
251 listener installed, however Node.js will be unconditionally terminated by
252 Windows about 10 seconds later. On non-Windows platforms, the default
253 behavior of `SIGHUP` is to terminate Node.js, but once a listener has been
254 installed its default behavior will be removed.
255 - `SIGTERM` is not supported on Windows, it can be listened on.
256 - `SIGINT` from the terminal is supported on all platforms, and can usually be
257 generated with `CTRL+C` (though this may be configurable). It is not generated
258 when terminal raw mode is enabled.
259 - `SIGBREAK` is delivered on Windows when `CTRL+BREAK` is pressed, on non-Windows
260 platforms it can be listened on, but there is no way to send or generate it.
261 - `SIGWINCH` is delivered when the console has been resized. On Windows, this will
262 only happen on write to the console when the cursor is being moved, or when a
263 readable tty is used in raw mode.
264 - `SIGKILL` cannot have a listener installed, it will unconditionally terminate
265 Node.js on all platforms.
266 - `SIGSTOP` cannot have a listener installed.
268 Note that Windows does not support sending Signals, but Node.js offers some
269 emulation with `process.kill()`, and `child_process.kill()`. Sending signal `0`
270 can be used to test for the existence of a process. Sending `SIGINT`,
271 `SIGTERM`, and `SIGKILL` cause the unconditional termination of the target
276 This causes Node.js to emit an abort. This will cause Node.js to exit and
277 generate a core file.
281 What processor architecture you're running on: `'arm'`, `'ia32'`, or `'x64'`.
283 console.log('This processor architecture is ' + process.arch);
287 An array containing the command line arguments. The first element will be
288 'node', the second element will be the name of the JavaScript file. The
289 next elements will be any additional command line arguments.
291 // print process.argv
292 process.argv.forEach((val, index, array) => {
293 console.log(`${index}: ${val}`);
298 $ node process-2.js one two=three four
300 1: /Users/mjr/work/node/process-2.js
305 ## process.chdir(directory)
307 Changes the current working directory of the process or throws an exception if that fails.
309 console.log(`Starting directory: ${process.cwd()}`);
311 process.chdir('/tmp');
312 console.log(`New directory: ${process.cwd()}`);
315 console.log(`chdir: ${err}`);
320 An Object containing the JavaScript representation of the configure options
321 that were used to compile the current Node.js executable. This is the same as
322 the `config.gypi` file that was produced when running the `./configure` script.
324 An example of the possible output looks like:
328 default_configuration: 'Release',
334 node_install_npm: 'true',
336 node_shared_cares: 'false',
337 node_shared_http_parser: 'false',
338 node_shared_libuv: 'false',
339 node_shared_zlib: 'false',
340 node_use_dtrace: 'false',
341 node_use_openssl: 'true',
342 node_shared_openssl: 'false',
343 strict_aliasing: 'true',
345 v8_use_snapshot: 'true' } }
349 * {Boolean} Set to false after `process.disconnect()` is called
351 If `process.connected` is false, it is no longer possible to send messages.
355 Returns the current working directory of the process.
357 console.log(`Current directory: ${process.cwd()}`);
359 ## process.disconnect()
361 Close the IPC channel to the parent process, allowing this child to exit
362 gracefully once there are no other connections keeping it alive.
364 Identical to the parent process's [`ChildProcess.disconnect()`][].
366 If Node.js was not spawned with an IPC channel, `process.disconnect()` will be
371 An object containing the user environment. See environ(7).
373 An example of this object looks like:
375 { TERM: 'xterm-256color',
376 SHELL: '/usr/local/bin/bash',
378 PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin',
379 PWD: '/Users/maciej',
382 HOME: '/Users/maciej',
384 _: '/usr/local/bin/node' }
386 You can write to this object, but changes won't be reflected outside of your
387 process. That means that the following won't work:
389 $ node -e 'process.env.foo = "bar"' && echo $foo
393 process.env.foo = 'bar';
394 console.log(process.env.foo);
396 Assigning a property on `process.env` will implicitly convert the value
402 process.env.test = null;
403 console.log(process.env.test);
405 process.env.test = undefined;
406 console.log(process.env.test);
410 Use `delete` to delete a property from `process.env`.
415 process.env.TEST = 1;
416 delete process.env.TEST;
417 console.log(process.env.TEST);
423 This is the set of Node.js-specific command line options from the
424 executable that started the process. These options do not show up in
425 `process.argv`, and do not include the Node.js executable, the name of
426 the script, or any options following the script name. These options
427 are useful in order to spawn child processes with the same execution
428 environment as the parent.
432 $ node --harmony script.js --version
434 results in process.execArgv:
440 ['/usr/local/bin/node', 'script.js', '--version']
444 This is the absolute pathname of the executable that started the process.
451 ## process.exit([code])
453 Ends the process with the specified `code`. If omitted, exit uses the
456 To exit with a 'failure' code:
460 The shell that executed Node.js should see the exit code as 1.
465 A number which will be the process exit code, when the process either
466 exits gracefully, or is exited via [`process.exit()`][] without specifying
469 Specifying a code to `process.exit(code)` will override any previous
470 setting of `process.exitCode`.
475 Note: this function is only available on POSIX platforms (i.e. not Windows,
478 Gets the effective group identity of the process. (See getegid(2).)
479 This is the numerical group id, not the group name.
481 if (process.getegid) {
482 console.log(`Current gid: ${process.getegid()}`);
488 Note: this function is only available on POSIX platforms (i.e. not Windows,
491 Gets the effective user identity of the process. (See geteuid(2).)
492 This is the numerical userid, not the username.
494 if (process.geteuid) {
495 console.log(`Current uid: ${process.geteuid()}`);
500 Note: this function is only available on POSIX platforms (i.e. not Windows,
503 Gets the group identity of the process. (See getgid(2).)
504 This is the numerical group id, not the group name.
506 if (process.getgid) {
507 console.log(`Current gid: ${process.getgid()}`);
510 ## process.getgroups()
512 Note: this function is only available on POSIX platforms (i.e. not Windows,
515 Returns an array with the supplementary group IDs. POSIX leaves it unspecified
516 if the effective group ID is included but Node.js ensures it always is.
520 Note: this function is only available on POSIX platforms (i.e. not Windows,
523 Gets the user identity of the process. (See getuid(2).)
524 This is the numerical userid, not the username.
526 if (process.getuid) {
527 console.log(`Current uid: ${process.getuid()}`);
532 Returns the current high-resolution real time in a `[seconds, nanoseconds]`
533 tuple Array. It is relative to an arbitrary time in the past. It is not
534 related to the time of day and therefore not subject to clock drift. The
535 primary use is for measuring performance between intervals.
537 You may pass in the result of a previous call to `process.hrtime()` to get
538 a diff reading, useful for benchmarks and measuring intervals:
540 var time = process.hrtime();
544 var diff = process.hrtime(time);
547 console.log('benchmark took %d nanoseconds', diff[0] * 1e9 + diff[1]);
548 // benchmark took 1000000527 nanoseconds
552 ## process.initgroups(user, extra_group)
554 Note: this function is only available on POSIX platforms (i.e. not Windows,
557 Reads /etc/group and initializes the group access list, using all groups of
558 which the user is a member. This is a privileged operation, meaning you need
559 to be root or have the `CAP_SETGID` capability.
561 `user` is a user name or user ID. `extra_group` is a group name or group ID.
563 Some care needs to be taken when dropping privileges. Example:
565 console.log(process.getgroups()); // [ 0 ]
566 process.initgroups('bnoordhuis', 1000); // switch user
567 console.log(process.getgroups()); // [ 27, 30, 46, 1000, 0 ]
568 process.setgid(1000); // drop root gid
569 console.log(process.getgroups()); // [ 27, 30, 46, 1000 ]
571 ## process.kill(pid[, signal])
573 Send a signal to a process. `pid` is the process id and `signal` is the
574 string describing the signal to send. Signal names are strings like
575 `SIGINT` or `SIGHUP`. If omitted, the signal will be `SIGTERM`.
576 See [Signal Events][] and kill(2) for more information.
578 Will throw an error if target does not exist, and as a special case, a signal
579 of `0` can be used to test for the existence of a process. Windows platforms
580 will throw an error if the `pid` is used to kill a process group.
582 Note that even though the name of this function is `process.kill`, it is really
583 just a signal sender, like the `kill` system call. The signal sent may do
584 something other than kill the target process.
586 Example of sending a signal to yourself:
588 process.on('SIGHUP', () => {
589 console.log('Got SIGHUP signal.');
593 console.log('Exiting.');
597 process.kill(process.pid, 'SIGHUP');
599 Note: When SIGUSR1 is received by Node.js it starts the debugger, see
602 ## process.mainModule
604 Alternate way to retrieve [`require.main`][]. The difference is that if the main
605 module changes at runtime, `require.main` might still refer to the original main
606 module in modules that were required before the change occurred. Generally it's
607 safe to assume that the two refer to the same module.
609 As with `require.main`, it will be `undefined` if there was no entry script.
611 ## process.memoryUsage()
613 Returns an object describing the memory usage of the Node.js process
616 const util = require('util');
618 console.log(util.inspect(process.memoryUsage()));
626 `heapTotal` and `heapUsed` refer to V8's memory usage.
629 ## process.nextTick(callback[, arg][, ...])
631 * `callback` {Function}
633 Once the current event loop turn runs to completion, call the callback
636 This is *not* a simple alias to [`setTimeout(fn, 0)`][], it's much more
637 efficient. It runs before any additional I/O events (including
638 timers) fire in subsequent ticks of the event loop.
640 console.log('start');
641 process.nextTick(() => {
642 console.log('nextTick callback');
644 console.log('scheduled');
650 This is important in developing APIs where you want to give the user the
651 chance to assign event handlers after an object has been constructed,
652 but before any I/O has occurred.
654 function MyThing(options) {
655 this.setupOptions(options);
657 process.nextTick(() => {
658 this.startDoingStuff();
662 var thing = new MyThing();
663 thing.getReadyForStuff();
665 // thing.startDoingStuff() gets called now, not before.
667 It is very important for APIs to be either 100% synchronous or 100%
668 asynchronous. Consider this example:
670 // WARNING! DO NOT USE! BAD UNSAFE HAZARD!
671 function maybeSync(arg, cb) {
680 This API is hazardous. If you do this:
682 maybeSync(true, function() {
687 then it's not clear whether `foo()` or `bar()` will be called first.
689 This approach is much better:
691 function definitelyAsync(arg, cb) {
693 process.nextTick(cb);
700 Note: the nextTick queue is completely drained on each pass of the
701 event loop **before** additional I/O is processed. As a result,
702 recursively setting nextTick callbacks will block any I/O from
703 happening, just like a `while(true);` loop.
707 The PID of the process.
709 console.log(`This process is pid ${process.pid}`);
713 What platform you're running on:
714 `'darwin'`, `'freebsd'`, `'linux'`, `'sunos'` or `'win32'`
716 console.log(`This platform is ${process.platform}`);
720 An Object containing metadata related to the current release, including URLs
721 for the source tarball and headers-only tarball.
723 `process.release` contains the following properties:
725 * `name`: a string with a value that will always be `'node'` for Node.js. For
726 legacy io.js releases, this will be `'io.js'`.
727 * `sourceUrl`: a complete URL pointing to a _.tar.gz_ file containing the
728 source of the current release.
729 * `headersUrl`: a complete URL pointing to a _.tar.gz_ file containing only
730 the header files for the current release. This file is significantly smaller
731 than the full source file and can be used for compiling add-ons against
733 * `libUrl`: a complete URL pointing to an _node.lib_ file matching the
734 architecture and version of the current release. This file is used for
735 compiling add-ons against Node.js. _This property is only present on Windows
736 builds of Node.js and will be missing on all other platforms._
741 sourceUrl: 'https://nodejs.org/download/release/v4.0.0/node-v4.0.0.tar.gz',
742 headersUrl: 'https://nodejs.org/download/release/v4.0.0/node-v4.0.0-headers.tar.gz',
743 libUrl: 'https://nodejs.org/download/release/v4.0.0/win-x64/node.lib' }
745 In custom builds from non-release versions of the source tree, only the
746 `name` property may be present. The additional properties should not be
747 relied upon to exist.
749 ## process.send(message[, sendHandle][, callback])
752 * `sendHandle` {Handle object}
753 * `callback` {Function}
756 When Node.js is spawned with an IPC channel attached, it can send messages to its
757 parent process using `process.send()`. Each will be received as a
758 [`'message'`][] event on the parent's `ChildProcess` object.
760 If Node.js was not spawned with an IPC channel, `process.send()` will be undefined.
762 ## process.setegid(id)
764 Note: this function is only available on POSIX platforms (i.e. not Windows,
767 Sets the effective group identity of the process. (See setegid(2).)
768 This accepts either a numerical ID or a groupname string. If a groupname
769 is specified, this method blocks while resolving it to a numerical ID.
771 if (process.getegid && process.setegid) {
772 console.log(`Current gid: ${process.getegid()}`);
774 process.setegid(501);
775 console.log(`New gid: ${process.getegid()}`);
778 console.log(`Failed to set gid: ${err}`);
782 ## process.seteuid(id)
784 Note: this function is only available on POSIX platforms (i.e. not Windows,
787 Sets the effective user identity of the process. (See seteuid(2).)
788 This accepts either a numerical ID or a username string. If a username
789 is specified, this method blocks while resolving it to a numerical ID.
791 if (process.geteuid && process.seteuid) {
792 console.log(`Current uid: ${process.geteuid()}`);
794 process.seteuid(501);
795 console.log(`New uid: ${process.geteuid()}`);
798 console.log(`Failed to set uid: ${err}`);
802 ## process.setgid(id)
804 Note: this function is only available on POSIX platforms (i.e. not Windows,
807 Sets the group identity of the process. (See setgid(2).) This accepts either
808 a numerical ID or a groupname string. If a groupname is specified, this method
809 blocks while resolving it to a numerical ID.
811 if (process.getgid && process.setgid) {
812 console.log(`Current gid: ${process.getgid()}`);
815 console.log(`New gid: ${process.getgid()}`);
818 console.log(`Failed to set gid: ${err}`);
822 ## process.setgroups(groups)
824 Note: this function is only available on POSIX platforms (i.e. not Windows,
827 Sets the supplementary group IDs. This is a privileged operation, meaning you
828 need to be root or have the `CAP_SETGID` capability.
830 The list can contain group IDs, group names or both.
832 ## process.setuid(id)
834 Note: this function is only available on POSIX platforms (i.e. not Windows,
837 Sets the user identity of the process. (See setuid(2).) This accepts either
838 a numerical ID or a username string. If a username is specified, this method
839 blocks while resolving it to a numerical ID.
841 if (process.getuid && process.setuid) {
842 console.log(`Current uid: ${process.getuid()}`);
845 console.log(`New uid: ${process.getuid()}`);
848 console.log(`Failed to set uid: ${err}`);
854 A writable stream to stderr (on fd `2`).
856 `process.stderr` and `process.stdout` are unlike other streams in Node.js in
857 that they cannot be closed (`end()` will throw), they never emit the `finish`
858 event and that writes can block when output is redirected to a file (although
859 disks are fast and operating systems normally employ write-back caching so it
860 should be a very rare occurrence indeed.)
864 A `Readable Stream` for stdin (on fd `0`).
866 Example of opening standard input and listening for both events:
868 process.stdin.setEncoding('utf8');
870 process.stdin.on('readable', () => {
871 var chunk = process.stdin.read();
872 if (chunk !== null) {
873 process.stdout.write(`data: ${chunk}`);
877 process.stdin.on('end', () => {
878 process.stdout.write('end');
881 As a Stream, `process.stdin` can also be used in "old" mode that is compatible
882 with scripts written for node.js prior to v0.10.
883 For more information see [Stream compatibility][].
885 In "old" Streams mode the stdin stream is paused by default, so one
886 must call `process.stdin.resume()` to read from it. Note also that calling
887 `process.stdin.resume()` itself would switch stream to "old" mode.
889 If you are starting a new project you should prefer a more recent "new" Streams
894 A `Writable Stream` to `stdout` (on fd `1`).
896 For example, a `console.log` equivalent could look like this:
898 console.log = function(msg) {
899 process.stdout.write(`${msg}\n`);
902 `process.stderr` and `process.stdout` are unlike other streams in Node.js in
903 that they cannot be closed (`end()` will throw), they never emit the `'finish'`
904 event and that writes can block when output is redirected to a file (although
905 disks are fast and operating systems normally employ write-back caching so it
906 should be a very rare occurrence indeed.)
908 To check if Node.js is being run in a TTY context, read the `isTTY` property
909 on `process.stderr`, `process.stdout`, or `process.stdin`:
911 $ node -p "Boolean(process.stdin.isTTY)"
913 $ echo "foo" | node -p "Boolean(process.stdin.isTTY)"
916 $ node -p "Boolean(process.stdout.isTTY)"
918 $ node -p "Boolean(process.stdout.isTTY)" | cat
921 See [the tty docs][] for more information.
925 Getter/setter to set what is displayed in `ps`.
927 When used as a setter, the maximum length is platform-specific and probably
930 On Linux and OS X, it's limited to the size of the binary name plus the
931 length of the command line arguments because it overwrites the argv memory.
933 v0.8 allowed for longer process title strings by also overwriting the environ
934 memory but that was potentially insecure/confusing in some (rather obscure)
937 ## process.umask([mask])
939 Sets or reads the process's file mode creation mask. Child processes inherit
940 the mask from the parent process. Returns the old mask if `mask` argument is
941 given, otherwise returns the current mask.
943 const newmask = 0o022;
944 const oldmask = process.umask(newmask);
946 `Changed umask from ${oldmask.toString(8)} to ${newmask.toString(8)}`
952 Number of seconds Node.js has been running.
956 A compiled-in property that exposes `NODE_VERSION`.
958 console.log(`Version: ${process.version}`);
962 A property exposing version strings of Node.js and its dependencies.
964 console.log(process.versions);
966 Will print something like:
968 { http_parser: '2.3.0',
978 [`'message'`]: child_process.html#child_process_event_message
979 [`ChildProcess.disconnect()`]: child_process.html#child_process_child_disconnect
980 [`ChildProcess.send()`]: child_process.html#child_process_child_send_message_sendhandle_callback
981 [`Error`]: errors.html#errors_class_error
982 [`EventEmitter`]: events.html#events_class_events_eventemitter
983 [`net.Server`]: net.html#net_class_net_server
984 [`net.Socket`]: net.html#net_class_net_socket
985 [`process.exit()`]: #process_process_exit_code
986 [`promise.catch(...)`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/catch
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