mirror of
https://github.com/nushell/nushell
synced 2024-12-29 06:23:11 +00:00
02de69de92
# Description I found a bunch of issues relating to the specialized reimplementation of `print()` that's done in `nu-cli` and it just didn't seem necessary. So I tried to unify the behavior reasonably. `PipelineData::print()` already handles the call to `table` and it even has a `no_newline` option. One of the most major issues before was that we were using the value iterator, and then converting to string, and then printing each with newlines. This doesn't work well for an external stream, because its iterator ends up creating `Value::binary()` with each buffer... so we were doing lossy UTF-8 conversion on those and then printing them with newlines, which was very weird:  You can see the random newline inserted in a break between buffers, but this would be even worse if it were on a multibyte UTF-8 character. You can produce this by writing a large amount of text to a text file, and then doing `nu -c 'open file.txt'` - in my case I just wrote `^find .`; it just has to be large enough to trigger a buffer break. Using `print()` instead led to a new issue though, because it doesn't abort on errors. This is so that certain commands can produce a stream of errors and have those all printed. There are tests for e.g. `rm` that depend on this behavior. I assume we want to keep that, so instead I made my target `BufferedReader`, and had that fuse closed if an error was encountered. I can't imagine we want to keep reading from a wrapped I/O stream if an error occurs; more often than not the error isn't going to magically resolve itself, it's not going to be a different error each time, and it's just going to lead to an infinite stream of the same error. The test that broke without that was `open . | lines`, because `lines` doesn't fuse closed on error. But I don't know if it's expected or not for it to do that, so I didn't target that. I think this PR makes things better but I'll keep looking for ways to improve on how errors and streams interact, especially trying to eliminate cases where infinite error loops can happen. # User-Facing Changes - **Breaking**: `BufferedReader` changes + no more public fields - A raw I/O stream from e.g. `open` won't produce infinite errors anymore, but I consider that to be a plus - the implicit `print` on script output is the same as the normal one now # Tests + Formatting Everything passes but I didn't add anything specific. |
||
|---|---|---|
| .. | ||
| nu-cli | ||
| nu-cmd-base | ||
| nu-cmd-dataframe | ||
| nu-cmd-extra | ||
| nu-cmd-lang | ||
| nu-cmd-plugin | ||
| nu-color-config | ||
| nu-command | ||
| nu-engine | ||
| nu-explore | ||
| nu-glob | ||
| nu-json | ||
| nu-lsp | ||
| nu-parser | ||
| nu-path | ||
| nu-plugin | ||
| nu-plugin-test-support | ||
| nu-pretty-hex | ||
| nu-protocol | ||
| nu-std | ||
| nu-system | ||
| nu-table | ||
| nu-term-grid | ||
| nu-test-support | ||
| nu-utils | ||
| nu_plugin_custom_values | ||
| nu_plugin_example | ||
| nu_plugin_formats | ||
| nu_plugin_gstat | ||
| nu_plugin_inc | ||
| nu_plugin_nu_example | ||
| nu_plugin_polars | ||
| nu_plugin_python | ||
| nu_plugin_query | ||
| nu_plugin_stress_internals | ||
| nuon | ||
| README.md | ||
Nushell core libraries and plugins
These sub-crates form both the foundation for Nu and a set of plugins which extend Nu with additional functionality.
Foundational libraries are split into two kinds of crates:
- Core crates - those crates that work together to build the Nushell language engine
- Support crates - a set of crates that support the engine with additional features like JSON support, ANSI support, and more.
Plugins are likewise also split into two types:
- Core plugins - plugins that provide part of the default experience of Nu, including access to the system properties, processes, and web-connectivity features.
- Extra plugins - these plugins run a wide range of different capabilities like working with different file types, charting, viewing binary data, and more.