Add a reverse search that works similar to the ZSH one. It is
triggered with <ctrl> + r and <ctrl> + s. It skips duplicated history
entries and works with multiline statements. Matching entries indicate
the search parameter with an underscore and cancelling with <ctrl> + c
or escape brings back the original line.
Multiple matches in a single history entry work as well and are
matched in the order of the current search direction. The cursor is
positioned at the current match position of the history entry.
Changing the direction immediately checks for the next entry in the
expected direction from the current position on.
Entries are accepted as soon any button is pressed that doesn't
correspond with the reverse search.
The behavior is deactivated for simple terminals. They do not support
most ANSI escape codes that are necessary for this feature.
PR-URL: https://github.com/nodejs/node/pull/31006
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This slightly alters the behaviour of session close by first using
.end() on a session socket to finish writing the data and only then
calls .destroy() to make sure the Readable side is closed. This allows
the socket to finish transmitting data, receive proper FIN packet and
avoid ECONNRESET errors upon graceful close.
onStreamClose now directly calls stream.destroy() instead of
kMaybeDestroy because the latter will first check that the stream has
writableFinished set. And that may not be true as we have just
(synchronously) called .end() on the stream if it was not closed and
that doesn't give it enough time to finish. Furthermore there is no
point in waiting for 'finish' as the other party have already closed the
stream and we won't be able to write anyway.
This also changes a few tests to correctly handle graceful session
close. This includes:
* not reading request data (on client side)
* not reading push stream data (on client side)
* relying on socket.destroy() (on client) to finish server session
due to the destroy of the socket without closing the server session.
As the goaway itself is *not* a session close.
Added few 'close' event mustCall checks.
PR-URL: https://github.com/nodejs/node/pull/30854
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
The vm documentation uses the word _sandbox_ but has a significant
disclaimer about how that should not be interpreted to connote security
guarantees. Remove the term "sandbox" from documentation. As a result,
some code and tests also need to change.
PR-URL: https://github.com/nodejs/node/pull/31057
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Under high load 2 types of issues arise with this test.
* filesystem calls gets queued even when the 'sync' is used which leads
to async_hooks being called with the events of tmpdir clean or
initial file write after clean.
This is solved by counting all 'change' calls while making sure there
is no dependency of StatWatcher's on one another and the expected
changes are waited for.
* some events are getting lost with the current
clean->write->write_and_watch strategy. Specifically I observed the
file size going from 0 to 5 entirely skipping 3 even though the write
call was there (this happened reliably on -j128).
So I've changed the strategy to avoid additional write considering
this still tests the hooks correctly.
This may indicate some sort of bug in async_hooks though I'm not sure.
Closes: https://github.com/nodejs/node/issues/21425
PR-URL: https://github.com/nodejs/node/pull/30362
Fixes: https://github.com/nodejs/node/issues/21425
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Vladimir de Turckheim <vlad2t@hotmail.com>
This patch splits the handling of `isMainThread` and
`ownsProcessState` from conditionals in
`lib/internal/bootstrap/node.js` into different scripts under
`lib/internal/bootstrap/switches/`, and call them accordingly
from C++ after `node.js` is run.
This:
- Creates a common denominator of the main thread and the worker
thread bootstrap that can be snapshotted and shared by
both.
- Makes it possible to override the configurations on-the-fly.
PR-URL: https://github.com/nodejs/node/pull/30862
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
ERR_INVALID_ARG_TYPE is the most common error used throughout the
code base. This improves the error message by providing more details
to the user and by indicating more precisely which values are allowed
ones and which ones are not.
It adds the actual input to the error message in case it's a primitive.
If it's a class instance, it'll print the class name instead of
"object" and "falsy" or similar entries are not named "type" anymore.
PR-URL: https://github.com/nodejs/node/pull/29675
Reviewed-By: Rich Trott <rtrott@gmail.com>
This makes sure the original input is passed to the error in case
no matching inputs are found. Instead of passing along all values,
only valid or possibliy valid values are passed through. That way
invalid values end up in the error case with the original input.
PR-URL: https://github.com/nodejs/node/pull/29675
Reviewed-By: Rich Trott <rtrott@gmail.com>
Installing an error listener has a side effect that emitted errors are
considered as handled. This is quite bad for monitoring/logging tools
which tend to be interested in errors but don't want to cause side
effects like swallow an exception.
There are some workarounds in the wild like monkey patching emit or
remit the error if monitoring tool detects that it is the only listener
but this is error prone and risky.
This PR allows to install a listener to monitor errors with the side
effect to consume the error. To avoid conflicts with other events it
exports a symbol on EventEmitter which owns this special meaning.
Refs: https://github.com/open-telemetry/opentelemetry-js/issues/225
PR-URL: https://github.com/nodejs/node/pull/30932
Refs: https://github.com/open-telemetry/opentelemetry-js/issues/225
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This fixes the following warning:
../src/env.cc: In member function ‘void node::Environment::Exit(int)’:
../src/env.cc:946:77: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘uint64_t {aka long unsigned int}’ [-Wformat=]
fprintf(stderr, "(node:%d, thread:%llu) ", uv_os_getpid(), thread_id());
~~~~~~~~~~~^
PR-URL: https://github.com/nodejs/node/pull/31020
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
test-wasi-binding.js was added during the initial WASI
development, but it is now considered obsolete. It also does
not provide any additional test coverage. This commit removes
it.
PR-URL: https://github.com/nodejs/node/pull/30980
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This commit updates to uvwasi 0.0.3, which implements a newer
version of the WASI spec, snapshot_1. Since the WASI API has
changed, this also requires updating the WebAssembly memory
interfacing logic and recompiling the WASI tests with a
version of wasi-libc that supports snapshot_1.
PR-URL: https://github.com/nodejs/node/pull/30980
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Ruben Bridgewater