mirror of
https://github.com/nushell/nushell.git
synced 2025-05-21 15:13:23 +00:00
472 Commits
Author | SHA1 | Message | Date | |
---|---|---|---|---|
|
306e305b65
|
Add help pipe-and-redirect command. (#14821)
# Description This pr is going to add a new command named `help pipe-and-redirect`. So user can detect such feature easier. # User-Facing Changes Here is the output of this command: ``` ╭───┬────────┬──────────────────────────────────────┬──────────────────────────────────────────────────────────────┬─────────────────────╮ │ # │ symbol │ name │ description │ example │ ├───┼────────┼──────────────────────────────────────┼──────────────────────────────────────────────────────────────┼─────────────────────┤ │ 0 │ | │ pipe │ pipeline stdout of a command to another command │ ^cmd1 | ^cmd2 │ │ 1 │ e>| │ stderr pipe │ pipeline stderr of a command to another command │ ^cmd1 e>| ^cmd2 │ │ 2 │ o+e>| │ stdout and stderr pipe │ pipeline stdout and stderr of a command to another command │ ^cmd1 o+e>| ^cmd2 │ │ 3 │ o> │ redirection │ redirect stdout of a command, overwriting a file │ ^cmd1 o> file.txt │ │ 4 │ e> │ stderr redirection │ redirect stderr of a command, overwriting a file │ ^cmd1 e> file.txt │ │ 5 │ o+e> │ stdout and stderr redirection │ redirect stdout and stderr of a command, overwriting a file │ ^cmd1 o+e> file.txt │ │ 6 │ o>> │ redirection append │ redirect stdout of a command, appending to a file │ ^cmd1 o> file.txt │ │ 7 │ e>> │ stderr redirection append │ redirect stderr of a command, appending to a file │ ^cmd1 e> file.txt │ │ 8 │ o+e>> │ stdout and stderr redirection append │ redirect stdout and stderr of a command, appending to a file │ ^cmd1 o+e> file.txt │ │ 9 │ o>| │ │ Unsupported, it's the same to `|`, use it instead │ │ ├───┼────────┼──────────────────────────────────────┼──────────────────────────────────────────────────────────────┼─────────────────────┤ │ # │ symbol │ name │ description │ example │ ╰───┴────────┴──────────────────────────────────────┴──────────────────────────────────────────────────────────────┴─────────────────────╯ ``` # Tests + Formatting # After Submitting Should update more examples in [nushell doc](https://www.nushell.sh/lang-guide/chapters/pipelines.html) to fill more examples |
||
|
6eb14522b6
|
Remove deprecated commands (#14726)
# Description Remove commands which were deprecated in 0.101: * `split-by` (#14019) * `date to-record` and `date to-table` (#14319) # User-Facing Changes - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting TODO: `grep` (`ag`) doc repo for any usage of these commands |
||
|
80788636ee
|
Make utouch the new touch (#14721)
# Description This PR removes the old `touch` command in favor of the uutils/coreutils implementation of `touch`, which we integrated in 0.101 (#11817). It turns out that in `utouch`, the `--no-deref`/`-s` wasn't working, and the issue had gone undetected because I accidentally made the test for that use `touch` rather than `utouch`. This has been fixed now. # User-Facing Changes Our old `touch` command didn't have anything that the new uutils-based command doesn't, and the uutils-based command actually has a little more functionality. So nothing using `touch` should break. Scripts using `utouch` will have to use `touch` now, but given that `utouch` has been around for less than 2 months, I assume people haven't really been using it. # Tests + Formatting The utouch tests seem to have everything from the old touch tests, so I deleted the old touch tests. # After Submitting This will need to be mentioned in the release notes. |
||
|
b2b5b89a92
|
Add command to get evaluated color setting (#14683)
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> In #14647 I added the option `"auto"` to be a valid option for `$env.config.use_ansi_coloring`. That improves the decision making whether ansi colors should be used or not but that makes it hard for custom commands to respect that value as the config might now be a non-boolean value. To retrieve that evaluated value I added a new command called `config use-colors` that returns an evaluated boolean that may be used to decide if colors should be used or not. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> Scripts that previously just checked `$env.config.use_ansi_coloring` should now use `config use-colors` for their color decision making. # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> This PR essentially only runs `UseAnsiColoring::get`, and that is highly tested in the #14647, so I don't think this needs further testing. - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> I'm not sure if we have any docs about that ansi coloring setup. If we have, we should update these. |
||
|
469e23cae4
|
Add bytes split command (#14652)
Related #10708 # Description Add `bytes split` command. `bytes split` splits its input on the provided separator on binary values _and_ binary streams without collecting. The separator can be a multiple character string or multiple byte binary. It can be used when neither `split row` (not streaming over raw input) nor `lines` (streaming, but can only split on newlines) is right. The backing iterator implemented in this PR, `SplitRead`, can be used to implement a streaming `split row` in the future. # User-Facing Changes `bytes split` command added, which can be used to split binary values and raw streams using a separator. # Tests + Formatting - 🟢 toolkit fmt - 🟢 toolkit clippy - 🟢 toolkit test - 🟢 toolkit test stdlib # After Submitting Mention in release notes. |
||
|
8f4feeb119
|
add config flatten command (#14621)
# Description This is supposed to be a Quality-of-Life command that just makes some things easier when dealing with a nushell config. Really all it does is show you the current config in a flattened state. That's it. I was thinking this could be useful when comparing config settings between old and new config files. There are still room for improvements. For instance, closures are listed as an int. They can be updated with a `view source <int>` pipeline but that could all be built in too.  The command works by getting the current configuration, serializing it to json, then flattening that json. BTW, there's a new flatten_json.rs in nu-utils. Theoretically all this mess could be done in a custom command script, but it's proven to be exceedingly difficult based on the work from discord. Here's some more complex items to flatten.  # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |
||
|
68c2729991
|
add view blocks command (#14610)
# Description This PR is meant to add another nushell introspection/debug command, `view blocks`. This command shows what is in the EngineState's memory that is parsed and stored as blocks. Blocks may continue to grow as you use the repl.  # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |
||
|
8127b5dd24
|
Add merge deep command (#14525)
# Description This PR adds the `merge deep` command. This allows you to merge nested records and tables/lists within records together, instead of overwriting them. The code for `merge` was reworked to support more general merging of values, so `merge` and `merge deep` use the same underlying code. `merge deep` mostly works like `merge`, except it recurses into inner records which exist in both the input and argument rather than just overwriting. For lists and by extension tables, `merge deep` has a couple different strategies for merging inner lists, which can be selected with the `--strategy` flag. These are: - `table`: Merges tables element-wise, similarly to the merge command. Non-table lists are not merged. - `overwrite`: Lists and tables are overwritten with their corresponding value from the argument, similarly to scalars. - `append`: Lists and tables in the input are appended with the corresponding list from the argument. - `prepend`: Lists and tables in the input are prepended with the corresponding list from the argument. This can also be used with the new config changes to write a monolithic record of _only_ the config values you want to change: ```nushell # in config file: const overrides = { history: { file_format: "sqlite", isolation: true } } # use append strategy for lists, e.g., menus keybindings $env.config = $env.config | merge deep --strategy=append $overrides # later, in REPL: $env.config.history # => ╭───────────────┬────────╮ # => │ max_size │ 100000 │ # => │ sync_on_enter │ true │ # => │ file_format │ sqlite │ # => │ isolation │ true │ # => ╰───────────────┴────────╯ ``` <details> <summary>Performance details</summary> For those interested, there was less than one standard deviation of difference in startup time when setting each config item individually versus using <code>merge deep</code>, so you can use <code>merge deep</code> in your config at no measurable performance cost. Here's my results: My normal config (in 0.101 style, with each `$env.config.[...]` value updated individually) ```nushell bench --pretty { ./nu -l -c '' } # => 45ms 976µs 983ns +/- 455µs 955ns ``` Equivalent config with a single `overrides` record and `merge deep -s append`: ```nushell bench --pretty { ./nu -l -c '' } # => 45ms 587µs 428ns +/- 702µs 944ns ``` </details> Huge thanks to @Bahex for designing the strategies API and helping finish up this PR while I was sick ❤️ Related: #12148 # User-Facing Changes Adds the `merge deep` command to recursively merge records. For example: ```nushell {a: {foo: 123 bar: "overwrite me"}, b: [1, 2, 3]} | merge deep {a: {bar: 456, baz: 789}, b: [4, 5, 6]} # => ╭───┬───────────────╮ # => │ │ ╭─────┬─────╮ │ # => │ a │ │ foo │ 123 │ │ # => │ │ │ bar │ 456 │ │ # => │ │ │ baz │ 789 │ │ # => │ │ ╰─────┴─────╯ │ # => │ │ ╭───┬───╮ │ # => │ b │ │ 0 │ 4 │ │ # => │ │ │ 1 │ 5 │ │ # => │ │ │ 2 │ 6 │ │ # => │ │ ╰───┴───╯ │ # => ╰───┴───────────────╯ ``` `merge deep` also has different strategies for merging inner lists and tables. For example, you can use the `append` strategy to _merge_ the inner `b` list instead of overwriting it. ```nushell {a: {foo: 123 bar: "overwrite me"}, b: [1, 2, 3]} | merge deep --strategy=append {a: {bar: 456, baz: 789}, b: [4, 5, 6]} # => ╭───┬───────────────╮ # => │ │ ╭─────┬─────╮ │ # => │ a │ │ foo │ 123 │ │ # => │ │ │ bar │ 456 │ │ # => │ │ │ baz │ 789 │ │ # => │ │ ╰─────┴─────╯ │ # => │ │ ╭───┬───╮ │ # => │ b │ │ 0 │ 1 │ │ # => │ │ │ 1 │ 2 │ │ # => │ │ │ 2 │ 3 │ │ # => │ │ │ 3 │ 4 │ │ # => │ │ │ 4 │ 5 │ │ # => │ │ │ 5 │ 6 │ │ # => │ │ ╰───┴───╯ │ # => ╰───┴───────────────╯ ``` **Note to release notes writers**: Please credit @Bahex for this PR as well 😄 # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> Added tests for deep merge - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> N/A --------- Co-authored-by: Bahex <bahey1999@gmail.com> |
||
|
8771872d86
|
Add path self command for getting absolute paths to files at parse time (#14303)
Alternative solution to: - #12195 The other approach: - #14305 # Description Adds ~`path const`~ `path self`, a parse-time only command for getting the absolute path of the source file containing it, or any file relative to the source file. - Useful for any script or module that makes use of non nuscript files. - Removes the need for `$env.CURRENT_FILE` and `$env.FILE_PWD`. - Can be used in modules, sourced files or scripts. # Examples ```nushell # ~/.config/nushell/scripts/foo.nu const paths = { self: (path self), dir: (path self .), sibling: (path self sibling), parent_dir: (path self ..), cousin: (path self ../cousin), } export def main [] { $paths } ``` ```nushell > use foo.nu > foo ╭────────────┬────────────────────────────────────────────╮ │ self │ /home/user/.config/nushell/scripts/foo.nu │ │ dir │ /home/user/.config/nushell/scripts │ │ sibling │ /home/user/.config/nushell/scripts/sibling │ │ parent_dir │ /home/user/.config/nushell │ │ cousin │ /home/user/.config/nushell/cousin │ ╰────────────┴────────────────────────────────────────────╯ ``` Trying to run in a non-const context ```nushell > path self Error: × this command can only run during parse-time ╭─[entry #1:1:1] 1 │ path self · ─────┬──── · ╰── can't run after parse-time ╰──── help: try assigning this command's output to a const variable ``` Trying to run in the REPL i.e. not in a file ```nushell > const foo = path self Error: × Error: nu:🐚:file_not_found │ │ × File not found │ ╭─[entry #3:1:13] │ 1 │ const foo = path self │ · ─────┬──── │ · ╰── Couldn't find current file │ ╰──── │ ╭─[entry #3:1:13] 1 │ const foo = path self · ─────┬──── · ╰── Encountered error during parse-time evaluation ╰──── ``` # Comparison with #14305 ## Pros - Self contained implementation, does not require changes in the parser. - More concise usage, especially with parent directories. --------- Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com> |
||
|
3d5f853b03
|
Start to Add WASM Support Again (#14418)
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> The [nushell/demo](https://github.com/nushell/demo) project successfully demonstrated running Nushell in the browser using WASM. However, the current version of Nushell cannot be easily built for the `wasm32-unknown-unknown` target, the default for `wasm-bindgen`. This PR introduces initial support for the `wasm32-unknown-unknown` target by disabling OS-dependent features such as filesystem access, IO, and platform/system-specific functionality. This separation is achieved using a new `os` feature in the following crates: - `nu-cmd-lang` - `nu-command` - `nu-engine` - `nu-protocol` The `os` feature includes all functionality that interacts with an operating system. It is enabled by default, but can be disabled using `--no-default-features`. All crates that depend on these core crates now use `--no-default-features` to allow compilation for WASM. To demonstrate compatibility, the following script builds all crates expected to work with WASM. Direct user interaction, running external commands, working with plugins, and features requiring `openssl` are out of scope for now due to their complexity or reliance on C libraries, which are difficult to compile and link in a WASM environment. ```nushell [ # compatible crates "nu-cmd-base", "nu-cmd-extra", "nu-cmd-lang", "nu-color-config", "nu-command", "nu-derive-value", "nu-engine", "nu-glob", "nu-json", "nu-parser", "nu-path", "nu-pretty-hex", "nu-protocol", "nu-std", "nu-system", "nu-table", "nu-term-grid", "nu-utils", "nuon" ] | each {cargo build -p $in --target wasm32-unknown-unknown --no-default-features} ``` ## Caveats This PR has a few caveats: 1. **`miette` and `terminal-size` Dependency Issue** `miette` depends on `terminal-size`, which uses `rustix` when the target is not Windows. However, `rustix` requires `std::os::unix`, which is unavailable in WASM. To address this, I opened a [PR](https://github.com/eminence/terminal-size/pull/68) for `terminal-size` to conditionally compile `rustix` only when the target is Unix. For now, the `Cargo.toml` includes patches to: - Use my forked version of `terminal-size`. - ~~Use an unreleased version of `miette` that depends on `terminal-size@0.4`.~~ These patches are temporary and can be removed once the upstream changes are merged and released. 2. **Test Output Adjustments** Due to the slight bump in the `miette` version, one test required adjustments to accommodate minor formatting changes in the error output, such as shifted newlines. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> This shouldn't break anything but allows using some crates for targeting `wasm32-unknown-unknown` to revive the demo page eventually. # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` I did not add any extra tests, I just checked that compiling works, also when using the host target but unselecting the `os` feature. # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> ~~Breaking the wasm support can be easily done by adding some `use`s or by adding a new dependency, we should definitely add some CI that also at least builds against wasm to make sure that building for it keep working.~~ I added a job to build wasm. --------- Co-authored-by: Ian Manske <ian.manske@pm.me> |
||
|
dc9e8161d9
|
Implement chunk_by operation (#14410)
# Description This pull requests implements a new ~~partition-by~~ `chunk-by` command. The operation takes a closure and partitions the input list into sublists based on the return value of the closure. - fixes #14149 Examples, tests and and documentation were added accordingly.   |
||
|
32196cfe78
|
Add term query , for querying information from terminals. (#14427)
## Related - #10150 - https://github.com/nushell/nushell/pull/10150#issuecomment-1721238336 - #10387 - https://github.com/nushell/nushell/pull/10387#issuecomment-1722228185 # Description `term query`: a command for querying information from the terminal. Prints the `$query`, and immediately starts reading raw bytes from stdin. The standard input will be read until the `terminator` sequence is encountered. The `terminator` is not removed from the output. It also stops on <kbd>Ctrl-C</kbd> with an error. ``` Usage: > term query {flags} <query> Flags: -h, --help: Display the help message for this command -t, --terminator (required parameter) <one_of(binary, string)>: stdin will be read until this sequence is encountered Parameters: query <one_of(binary, string)>: The query that will be printed to stdout ``` This was previously possible with `input` until #10150. `input` command's features such as cursor control, deleting input etc. are useful, but interfere with this use case. `term query` makes the following uses possible: ```nushell # get the terminal size with ansi escape codes def terminal-size [] { let response = term query (ansi size) --terminator 'R' # $response should look like this # Length: 9 (0x9) bytes | printable whitespace ascii_other non_ascii # 00000000: 1b 5b 33 38 3b 31 35 30 52 •[38;150R let sz = $response | bytes at 2..<-1 | decode # 38;150 # $sz should look like 38;150 let size = ($sz | split row ';' | each {into int}) # output in record syntax { rows: $size.0 columns: $size.1 } } ``` ```nushell # read clipboard content using OSC 52 term query $"(ansi --osc '52;c;?')(ansi st)" --terminator (ansi st) | bytes at 7..<-2 | decode | decode base64 | decode ``` # User-Facing Changes - added `ansi query` # Tests + Formatting - Integration tests should be added if possible. |
||
|
f63f8cb154
|
Add utouch command from uutils/coreutils (#11817)
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> Part of https://github.com/nushell/nushell/issues/11549 # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> This PR adds a `utouch` command that uses the `touch` command from https://github.com/uutils/coreutils. Eventually, `utouch` may be able to replace `touch`. The conflicts in Cargo.lock and Cargo.toml are because I'm using the uutils/coreutils main rather than the latest release, since the changes that expose `uu_touch`'s internal functionality aren't available in the latest release. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> Users will have access to a new `utouch` command with the following flags: todo # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |
||
|
3182adb6a0
|
Url split query (#14211)
Addresses the following points from #14162 > - There is no built-in counterpart to url build-query for splitting a query string There is `from url`, which, due to naming, is a little hard to discover and suffers from the following point > - url parse can create records with duplicate keys > - url parse's params should either: > - ~group the same keys into a list.~ > - instead of a record, be a key-value table. (table<key: string, value: string>) # Description ## `url split-query` Counterpart to `url build-query`, splits a url encoded query string to key value pairs, represented as `table<key: string, value: string>` ``` > "a=one&a=two&b=three" | url split-query ╭───┬─────┬───────╮ │ # │ key │ value │ ├───┼─────┼───────┤ │ 0 │ a │ one │ │ 1 │ a │ two │ │ 2 │ b │ three │ ╰───┴─────┴───────╯ ``` ## `url parse` The output's `param` field is now a table as well, mirroring the new `url split-query` ``` > 'http://localhost?a=one&a=two&b=three' | url parse ╭──────────┬─────────────────────╮ │ scheme │ http │ │ username │ │ │ password │ │ │ host │ localhost │ │ port │ │ │ path │ / │ │ query │ a=one&a=two&b=three │ │ fragment │ │ │ │ ╭───┬─────┬───────╮ │ │ params │ │ # │ key │ value │ │ │ │ ├───┼─────┼───────┤ │ │ │ │ 0 │ a │ one │ │ │ │ │ 1 │ a │ two │ │ │ │ │ 2 │ b │ three │ │ │ │ ╰───┴─────┴───────╯ │ ╰──────────┴─────────────────────╯ ``` # User-Facing Changes - `url parse`'s output has the mentioned change, which is backwards incompatible. |
||
|
a95c2198a6
|
Remove group command (#14056)
# Description Removes the `group` command that was deprecated back in 0.96.0 with #13377. # User-Facing Changes Breaking change, removed `group` command. |
||
|
2830ec008c
|
Replace the old encode base64 and decode base64 with new-base64 commands (#14018)
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> Maybe we can deprecate `encode new-base64` and `decode new-base64` first, to make the code clean and simple I'd rather remove the old `encode base64` and `decode base64` and replace them with the `* new-base64` commands. Related PR: https://github.com/nushell/nushell/pull/13428 # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> - `encode new-base64` --> `encode base64` - `decode new-base64` --> `decode base64` # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> It's a breaking change |
||
|
f63cecc316
|
add metadata access command (#13785)
# Description Add `metadata access`, which allows accessing/inspecting the metadata of a stream in a closure. ```nu ls | metadata access {|meta| ... } ``` - The metadata is provided as an argument to the closure, identical to the record obtained with `metadata` command. - `metadata access` passes its input stream into the closure as it is. - Within the closure, both the metadata and the stream are available. The closure may modify, collect or pass the stream as it is. # Motivation - Without this command, nu code can't act on metadata without losing the stream, use cases requiring both the stream and metadata must be implemented either as a built-in or a plugin. - This command allows users to enhance presentation of data, similar to `table` coloring the output of `ls`. |
||
|
f58a4b5017
|
Add split cell-path (#13705)
this PR should close #12168 # Description Add `split cell-path`, inverse of `into cell-path`. # User-Facing Changes Currently there is no way to make use of cell-path values as a user, other than passing them to builtin commands. This PR makes more use cases possible. |
||
|
af76e11dd6
|
Remove str deunicode (#13693)
# Description Closes #13677 Remove the command `str deunicode`, as it has a narrow application, is loosely defined by the data provided by the `deunicode` crate and thus a stabilization liability post-1.0. Furthermore the data to perform the look-up is quite substantial. Removing the command and the `deunicode` dependency saves 0.9 MB of binary data in release mode (~ 2% of total) (checked via `cargo bloat --release` for a linux x86 build) # User-Facing Changes The `str deunicode` command recently added in #13270 is gone |
||
|
0560826414
|
encode /decode for multiple alphabets (#13428)
Based on the discussion in #13419. ## Description Reworks the `decode`/`encode` commands by adding/changing the following bases: - `base32` - `base32hex` - `hex` - `new-base64` The `hex` base is compatible with the previous version of `hex` out of the box (it only adds more flags). `base64` isn't, so the PR adds a new version and deprecates the old one. All commands have `string -> binary` signature for decoding and `string | binary -> string` signature for encoding. A few `base64` encodings, which are not a part of the [RFC4648](https://datatracker.ietf.org/doc/html/rfc4648#section-6), have been dropped. ## Example usage ```Nushell ~/fork/nushell> "string" | encode base32 | decode base32 | decode string ``` ```Nushell ~/fork/nushell> "ORSXG5A=" | decode base32 # `decode` always returns a binary value Length: 4 (0x4) bytes | printable whitespace ascii_other non_ascii 00000000: 74 65 73 74 test ``` ## User-Facing Changes - New commands: `encode/decode base32/base32hex`. - `encode hex` gets a `--lower` flag. - `encode/decode base64` deprecated in favor of `encode/decode new-base64`. |
||
|
1c37f4b958
|
Create random binary command (#13542)
# Description/User-Facing Changes Creates a new `random binary <LENGTH>` command, which returns random bytes. Resolve #13500 |
||
|
0918050ac8
|
Deprecate group in favor of chunks (#13377)
# Description The name of the `group` command is a little unclear/ambiguous. Everything I look at it, I think of `group-by`. I think `chunks` more clearly conveys what the `group` command does. Namely, it divides the input list into chunks of a certain size. For example, [`slice::chunks`](https://doc.rust-lang.org/std/primitive.slice.html#method.chunks) has the same name. So, this PR adds a new `chunks` command to replace the now deprecated `group` command. The `chunks` command is a refactored version of `group`. As such, there is a small performance improvement: ```nushell # $data is a very large list > bench { $data | chunks 2 } --rounds 30 | get mean 474ms 921µs 190ns # deprecation warning was disabled here for fairness > bench { $data | group 2 } --rounds 30 | get mean 592ms 702µs 440ns > bench { $data | chunks 200 } --rounds 30 | get mean 374ms 188µs 318ns > bench { $data | group 200 } --rounds 30 | get mean 481ms 264µs 869ns > bench { $data | chunks 1 } --rounds 30 | get mean 642ms 574µs 42ns > bench { $data | group 1 } --rounds 30 | get mean 981ms 602µs 513ns ``` # User-Facing Changes - `group` command has been deprecated in favor of new `chunks` command. - `chunks` errors when given a chunk size of `0` whereas `group` returns chunks with one element. # Tests + Formatting Added tests for `chunks`, since `group` did not have any tests. # After Submitting Update book if necessary. |
||
|
b0bf54614f
|
Don't add touch command to default context twice (#13371)
# Description Touch was added to the shell command context twice, once with the other filesystem commands and once with the format commands. I removed that second occurrence of touch, because I'm assuming it was only added there because "Touch" starts with "To." # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> None |
||
|
d7392f1f3b
|
Internal representation (IR) compiler and evaluator (#13330)
# Description This PR adds an internal representation language to Nushell, offering an alternative evaluator based on simple instructions, stream-containing registers, and indexed control flow. The number of registers required is determined statically at compile-time, and the fixed size required is allocated upon entering the block. Each instruction is associated with a span, which makes going backwards from IR instructions to source code very easy. Motivations for IR: 1. **Performance.** By simplifying the evaluation path and making it more cache-friendly and branch predictor-friendly, code that does a lot of computation in Nushell itself can be sped up a decent bit. Because the IR is fairly easy to reason about, we can also implement optimization passes in the future to eliminate and simplify code. 2. **Correctness.** The instructions mostly have very simple and easily-specified behavior, so hopefully engine changes are a little bit easier to reason about, and they can be specified in a more formal way at some point. I have made an effort to document each of the instructions in the docs for the enum itself in a reasonably specific way. Some of the errors that would have happened during evaluation before are now moved to the compilation step instead, because they don't make sense to check during evaluation. 3. **As an intermediate target.** This is a good step for us to bring the [`new-nu-parser`](https://github.com/nushell/new-nu-parser) in at some point, as code generated from new AST can be directly compared to code generated from old AST. If the IR code is functionally equivalent, it will behave the exact same way. 4. **Debugging.** With a little bit more work, we can probably give control over advancing the virtual machine that `IrBlock`s run on to some sort of external driver, making things like breakpoints and single stepping possible. Tools like `view ir` and [`explore ir`](https://github.com/devyn/nu_plugin_explore_ir) make it easier than before to see what exactly is going on with your Nushell code. The goal is to eventually replace the AST evaluator entirely, once we're sure it's working just as well. You can help dogfood this by running Nushell with `$env.NU_USE_IR` set to some value. The environment variable is checked when Nushell starts, so config runs with IR, or it can also be set on a line at the REPL to change it dynamically. It is also checked when running `do` in case within a script you want to just run a specific piece of code with or without IR. # Example ```nushell view ir { |data| mut sum = 0 for n in $data { $sum += $n } $sum } ``` ```gas # 3 registers, 19 instructions, 0 bytes of data 0: load-literal %0, int(0) 1: store-variable var 904, %0 # let 2: drain %0 3: drop %0 4: load-variable %1, var 903 5: iterate %0, %1, end 15 # for, label(1), from(14:) 6: store-variable var 905, %0 7: load-variable %0, var 904 8: load-variable %2, var 905 9: binary-op %0, Math(Plus), %2 10: span %0 11: store-variable var 904, %0 12: load-literal %0, nothing 13: drain %0 14: jump 5 15: drop %0 # label(0), from(5:) 16: drain %0 17: load-variable %0, var 904 18: return %0 ``` # Benchmarks All benchmarks run on a base model Mac Mini M1. ## Iterative Fibonacci sequence This is about as best case as possible, making use of the much faster control flow. Most code will not experience a speed improvement nearly this large. ```nushell def fib [n: int] { mut a = 0 mut b = 1 for _ in 2..=$n { let c = $a + $b $a = $b $b = $c } $b } use std bench bench { 0..50 | each { |n| fib $n } } ``` IR disabled: ``` ╭───────┬─────────────────╮ │ mean │ 1ms 924µs 665ns │ │ min │ 1ms 700µs 83ns │ │ max │ 3ms 450µs 125ns │ │ std │ 395µs 759ns │ │ times │ [list 50 items] │ ╰───────┴─────────────────╯ ``` IR enabled: ``` ╭───────┬─────────────────╮ │ mean │ 452µs 820ns │ │ min │ 427µs 417ns │ │ max │ 540µs 167ns │ │ std │ 17µs 158ns │ │ times │ [list 50 items] │ ╰───────┴─────────────────╯ ```  ## [gradient_benchmark_no_check.nu](https://github.com/nushell/nu_scripts/blob/main/benchmarks/gradient_benchmark_no_check.nu) IR disabled: ``` ╭───┬──────────────────╮ │ 0 │ 27ms 929µs 958ns │ │ 1 │ 21ms 153µs 459ns │ │ 2 │ 18ms 639µs 666ns │ │ 3 │ 19ms 554µs 583ns │ │ 4 │ 13ms 383µs 375ns │ │ 5 │ 11ms 328µs 208ns │ │ 6 │ 5ms 659µs 542ns │ ╰───┴──────────────────╯ ``` IR enabled: ``` ╭───┬──────────────────╮ │ 0 │ 22ms 662µs │ │ 1 │ 17ms 221µs 792ns │ │ 2 │ 14ms 786µs 708ns │ │ 3 │ 13ms 876µs 834ns │ │ 4 │ 13ms 52µs 875ns │ │ 5 │ 11ms 269µs 666ns │ │ 6 │ 6ms 942µs 500ns │ ╰───┴──────────────────╯ ``` ## [random-bytes.nu](https://github.com/nushell/nu_scripts/blob/main/benchmarks/random-bytes.nu) I got pretty random results out of this benchmark so I decided not to include it. Not clear why. # User-Facing Changes - IR compilation errors may appear even if the user isn't evaluating with IR. - IR evaluation can be enabled by setting the `NU_USE_IR` environment variable to any value. - New command `view ir` pretty-prints the IR for a block, and `view ir --json` can be piped into an external tool like [`explore ir`](https://github.com/devyn/nu_plugin_explore_ir). # Tests + Formatting All tests are passing with `NU_USE_IR=1`, and I've added some more eval tests to compare the results for some very core operations. I will probably want to add some more so we don't have to always check `NU_USE_IR=1 toolkit test --workspace` on a regular basis. # After Submitting - [ ] release notes - [ ] further documentation of instructions? - [ ] post-release: publish `nu_plugin_explore_ir` |
||
|
33d0537cae
|
add str deunicode command (#13270)
# Description Sometimes it's helpful to deal with only ASCII. This command will take a unicode string as input and convert it to ASCII using the deunicode crate. ```nushell ❯ "A…B" | str deunicode A...B ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |
||
|
634361b2d1
|
Make which-support feature non-optional (#13125)
# Description Removes the `which-support` cargo feature and makes all of its feature-gated code enabled by default in all builds. I'm not sure why this one command is gated behind a feature. It seems to be a relic of older code where we had features for what seems like every command. |
||
|
758c5d447a
|
Add support for the ps command on FreeBSD, NetBSD, and OpenBSD (#12892)
# Description I feel like it's a little sad that BSDs get to enjoy almost everything other than the `ps` command, and there are some tests that rely on this command, so I figured it would be fun to patch that and make it work. The different BSDs have diverged from each other somewhat, but generally have a similar enough API for reading process information via `sysctl()`, with some slightly different args. This supports FreeBSD with the `freebsd` module, and NetBSD and OpenBSD with the `netbsd` module. OpenBSD is a fork of NetBSD and the interface has some minor differences but many things are the same. I had wanted to try to support DragonFlyBSD too, but their Rust version in the latest release is only 1.72.0, which is too old for me to want to try to compile rustc up to 1.77.2... but I will revisit this whenever they do update it. Dragonfly is a fork of FreeBSD, so it's likely to be more or less the same - I just don't want to enable it without testing it. Fixes #6862 (partially, we probably won't be adding `zfs list`) # User-Facing Changes `ps` added for FreeBSD, NetBSD, and OpenBSD. # Tests + Formatting The CI doesn't run tests for BSDs, so I'm not entirely sure if everything was already passing before. (Frankly, it's unlikely.) But nothing appears to be broken. # After Submitting - [ ] release notes? - [ ] DragonflyBSD, whenever they do update Rust to something close enough for me to try it |
||
|
b9331d1b08
|
Add sys users command (#12787)
# Description Add a new `sys users` command which returns a table of the users of the system. This is the same table that is currently present as `(sys).host.sessions`. The same table has been removed from the recently added `sys host` command. # User-Facing Changes Adds a new command. (The old `sys` command is left as is.) |
||
|
1038c64f80
|
Add sys subcommands (#12747)
# Description Adds subcommands to `sys` corresponding to each column of the record returned by `sys`. This is to alleviate the fact that `sys` now returns a regular record, meaning that it must compute every column which might take a noticeable amount of time. The subcommands, on the other hand, only need to compute and return a subset of the data which should be much faster. In fact, it should be as fast as before, since this is how the lazy record worked (it would compute only each column as necessary). I choose to add subcommands instead of having an optional cell-path parameter on `sys`, since the cell-path parameter would: - increase the code complexity (can access any value at any row or nested column) - prevents discovery with tab-completion - hinders type checking and allows users to pass potentially invalid columns # User-Facing Changes Deprecates `sys` in favor of the new `sys` subcommands. |
||
|
adf38c7c76
|
Msgpack commands (#12664)
# Description I thought about bringing `nu_plugin_msgpack` in, but that is MPL with a clause that prevents other licenses, so rather than adapt that code I decided to take a crack at just doing it straight from `rmp` to `Value` without any `rmpv` in the middle. It seems like it's probably faster, though I can't say for sure how much with the plugin overhead. @IanManske I started on a `Read` implementation for `RawStream` but just specialized to `from msgpack` here, but I'm thinking after release maybe we can polish it up and make it a real one. It works! # User-Facing Changes New commands: - `from msgpack` - `from msgpackz` - `to msgpack` - `to msgpackz` # Tests + Formatting Pretty thorough tests added for the format deserialization, with a roundtrip for serialization. Some example tests too for both `from msgpack` and `to msgpack`. - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting - [ ] update release notes |
||
|
7fe2e60af7
|
add ability to set metadata (#12564)
# Description This PR adds the ability to set metadata. This is especially useful for activating LS_COLORS when using table literals.  You can also set the filepath metadata, although I'm not really user how useful this is. We may end up removing this option entirely. ```nushell ❯ "crates" | metadata set --datasource-filepath $'(pwd)/crates' | metadata ╭────────┬───────────────────────────────────╮ │ source │ /Users/fdncred/src/nushell/crates │ ╰────────┴───────────────────────────────────╯ ``` No file paths are checked. You could also do this. ```nushell ❯ "crates" | metadata set --datasource-filepath $'a/b/c/d/crates' | metadata ╭────────┬────────────────╮ │ source │ a/b/c/d/crates │ ╰────────┴────────────────╯ ``` The command name and parameter names are still WIP. We could change them. There are currently 3 kinds of metadata in nushell. ```rust pub enum DataSource { Ls, HtmlThemes, FilePath(PathBuf), } ``` I've skipped adding `HtmlThemes` because it seems to be specific to our `to html` command only. |
||
|
e889679d42
|
Use nightly clippy to kill dead code/fix style (#12334)
- **Remove duplicated imports** - **Remove unused field in `CompletionOptions`** - **Remove unused struct in `nu-table`** - **Clarify generic bounds** - **Simplify a subtrait bound for `ExactSizeIterator`** - **Use `unwrap_or_default`** - **Use `Option` directly instead of empty string** - **Elide unneeded clone in `to html`** |
||
|
c747ec75c9
|
Add command_prelude module (#12291)
# Description When implementing a `Command`, one must also import all the types present in the function signatures for `Command`. This makes it so that we often import the same set of types in each command implementation file. E.g., something like this: ```rust use nu_protocol::ast::Call; use nu_protocol::engine::{Command, EngineState, Stack}; use nu_protocol::{ record, Category, Example, IntoInterruptiblePipelineData, IntoPipelineData, PipelineData, ShellError, Signature, Span, Type, Value, }; ``` This PR adds the `nu_engine::command_prelude` module which contains the necessary and commonly used types to implement a `Command`: ```rust // command_prelude.rs pub use crate::CallExt; pub use nu_protocol::{ ast::{Call, CellPath}, engine::{Command, EngineState, Stack}, record, Category, Example, IntoInterruptiblePipelineData, IntoPipelineData, IntoSpanned, PipelineData, Record, ShellError, Signature, Span, Spanned, SyntaxShape, Type, Value, }; ``` This should reduce the boilerplate needed to implement a command and also gives us a place to track the breadth of the `Command` API. I tried to be conservative with what went into the prelude modules, since it might be hard/annoying to remove items from the prelude in the future. Let me know if something should be included or excluded. |
||
|
838fc7e098
|
Initial implementation for uutils uname (#11684)
Hi, This PR aims at implementing the first iteration for `uname` using `uutils`. Couple of things: * Currently my [PR](https://github.com/uutils/coreutils/pull/5921) to make the required changes is pending in `uutils` repo. * I guess the number of flags has to be investigated. Still the tests cover all of them. <!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - [X] `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - [X] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - [X] `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - [X] `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> --------- Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com> |
||
|
2046912160
|
remove str escape-glob command (#12241)
This is a follow up to #12018 |
||
|
14d1c67863
|
Debugger experiments (#11441)
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> This PR adds a new evaluator path with callbacks to a mutable trait object implementing a Debugger trait. The trait object can do anything, e.g., profiling, code coverage, step debugging. Currently, entering/leaving a block and a pipeline element is marked with callbacks, but more callbacks can be added as necessary. Not all callbacks need to be used by all debuggers; unused ones are simply empty calls. A simple profiler is implemented as a proof of concept. The debugging support is implementing by making `eval_xxx()` functions generic depending on whether we're debugging or not. This has zero computational overhead, but makes the binary slightly larger (see benchmarks below). `eval_xxx()` variants called from commands (like `eval_block_with_early_return()` in `each`) are chosen with a dynamic dispatch for two reasons: to not grow the binary size due to duplicating the code of many commands, and for the fact that it isn't possible because it would make Command trait objects object-unsafe. In the future, I hope it will be possible to allow plugin callbacks such that users would be able to implement their profiler plugins instead of having to recompile Nushell. [DAP](https://microsoft.github.io/debug-adapter-protocol/) would also be interesting to explore. Try `help debug profile`. ## Screenshots Basic output:  To profile with more granularity, increase the profiler depth (you'll see that repeated `is-windows` calls take a large chunk of total time, making it a good candidate for optimizing):  ## Benchmarks ### Binary size Binary size increase vs. main: **+40360 bytes**. _(Both built with `--release --features=extra,dataframe`.)_ ### Time ```nushell # bench_debug.nu use std bench let test = { 1..100 | each { ls | each {|row| $row.name | str length } } | flatten | math avg } print 'debug:' let res2 = bench { debug profile $test } --pretty print $res2 ``` ```nushell # bench_nodebug.nu use std bench let test = { 1..100 | each { ls | each {|row| $row.name | str length } } | flatten | math avg } print 'no debug:' let res1 = bench { do $test } --pretty print $res1 ``` `cargo run --release -- bench_debug.nu` is consistently 1--2 ms slower than `cargo run --release -- bench_nodebug.nu` due to the collection overhead + gathering the report. This is expected. When gathering more stuff, the overhead is obviously higher. `cargo run --release -- bench_nodebug.nu` vs. `nu bench_nodebug.nu` I didn't measure any difference. Both benchmarks report times between 97 and 103 ms randomly, without one being consistently higher than the other. This suggests that at least in this particular case, when not running any debugger, there is no runtime overhead. ## API changes This PR adds a generic parameter to all `eval_xxx` functions that forces you to specify whether you use the debugger. You can resolve it in two ways: * Use a provided helper that will figure it out for you. If you wanted to use `eval_block(&engine_state, ...)`, call `let eval_block = get_eval_block(&engine_state); eval_block(&engine_state, ...)` * If you know you're in an evaluation path that doesn't need debugger support, call `eval_block::<WithoutDebug>(&engine_state, ...)` (this is the case of hooks, for example). I tried to add more explanation in the docstring of `debugger_trait.rs`. ## TODO - [x] Better profiler output to reduce spam of iterative commands like `each` - [x] Resolve `TODO: DEBUG` comments - [x] Resolve unwraps - [x] Add doc comments - [x] Add usage and extra usage for `debug profile`, explaining all columns # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> Hopefully none. # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |
||
|
872aa78373
|
Add interleave command for reading multiple streams in parallel (#11955)
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> This command mixes input from multiple sources and sends items to the final stream as soon as they're available. It can be called as part of a pipeline with input, or it can take multiple closures and mix them that way. See `crates/nu-command/tests/commands/interleave.rs` for a practical example. I imagine this will be most often used to run multiple commands in parallel and print their outputs line-by-line. A stdlib command could potentially use `interleave` to make this particular use case easier. It's quite common to wish that nushell had a command for running things in the background, and instead of providing job control, this provides an alternative to some use cases for that by just allowing multiple commands to run simultaneously and direct their output to the same place. This enables certain things that are not possible with `par-each` - for example, you may wish to run `make` across several projects in parallel: ```nushell (ls projects).name | par-each { |project| cd $project; make } ``` This works well enough, but the output will only be available after each `make` command finishes. `interleave` allows you to get each line: ```nushell interleave ...( (ls projects).name | each { |project| { cd $project make | lines | each { |line| {project: $project, out: $line} } } } ) ``` The result of this is a stream that you could process further - for example, by saving to a text file. Note that the closures themselves are not run in parallel. The initial execution happens serially, and then the streams are consumed in parallel. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> Adds a new command. # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |
||
|
262914cf92
|
remove old mv command in favor of umv (renamed to mv) (#12022)
# Description This PR removes our old nushell `mv` command in favor of the uutils/coreutils `uu_mv` crate's `mv` command which we integrated in 0.90.1. # User-Facing Changes # Tests + Formatting # After Submitting |
||
|
345edbbe10
|
add is-not-empty command as a QOL improvement (#11991)
# Description This PR adds `is-not-empty` as a counterpart to `is-empty`. It's the same code but negates the results. This command has been asked for many times. So, I thought it would be nice for our community to add it just as a quality-of-life improvement. This allows people to stop writing their `def is-not-empty [] { not ($in | is-empty) }` custom commands. I'm sure there will be some who disagree with adding this, I just think it's like we have `in` and `not-in` and helps fill out the language and makes it a little easier to use. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |
||
|
e69a02d379
|
Add tee command for operating on copies of streams (#11928)
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> [Related conversation on Discord](https://discord.com/channels/601130461678272522/615329862395101194/1209951539901366292) # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> This is inspired by the Unix tee command, but significantly more powerful. Rather than just writing to a file, you can do any kind of stream operation that Nushell supports within the closure. The equivalent of Unix `tee -a file.txt` would be, for example, `command | tee { save -a file.txt }` - but of course this is Nushell, and you can do the same with structured data to JSON objects, or even just run any other command on the system with it. A `--stderr` flag is provided for operating on the stderr stream from external programs. This may produce unexpected results if the stderr stream is not then also printed by something else - nushell currently doesn't. See #11929 for the fix for that. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> If someone was using the system `tee` command, they might be surprised to find that it's different. # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |
||
|
7b95e37bbe
|
Making coreutils umkdir as the default mkdir (#12007)
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> `umkdir` was added in #10785, I think it's time to replace the default one. # After Submitting Remove the old `mkdir` command and making coreutils' `umkdir` as the default |
||
|
f7d647ac3c
|
open , rm , umv , cp , rm and du : Don't globs if inputs are variables or string interpolation (#11886)
# Description
This is a follow up to
https://github.com/nushell/nushell/pull/11621#issuecomment-1937484322
Also Fixes: #11838
## About the code change
It applys the same logic when we pass variables to external commands:
|
||
|
f17f857b1f
|
wrapping run_repl with catch_unwind and restarting the repl on panic (#11860)
Provides the ability to cleanly recover from panics, falling back to the last known good state of EngineState and Stack. This pull request also utilizes miette's panic handler for better formatting of panics. <img width="642" alt="Screenshot 2024-02-21 at 08 34 35" src="https://github.com/nushell/nushell/assets/56345/f81efaba-aa45-4e47-991c-1a2cf99e06ff"> --------- Co-authored-by: Jack Wright <jack.wright@disqo.com> |
||
|
0e023eaa84
|
add str escape-glob command (#11664)
# Description This pr is a follow up to #11621, it introduces a `str escape-glob` command as a workaround for the case: ```nushell let f = "a[123]b" ls $f ``` It will glob `a[123]b`, we can get rid of the behavior through `str escape-glob` command: ```nushll let f = "a[123]b" ls ($f | str escape-glob) ``` It's more useful in the `each` context: `ls | get name | str escape-glob | each {|it| ls $it}` # User-Facing Changes NaN # Tests + Formatting Done # After Submitting --------- Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com> |
||
|
2a65d43c13
|
Add into cell-path for dynamic cell-path creation (#11322)
# Description The `cell-path` is a type that can be created statically with `$.nested.structure.5`, but can't be created from user input. This makes it difficult to take advantage of commands that accept a cell-path to operate on data structures. This PR adds `into cell-path` for dynamic cell-path creation. `into cell-path` accepts the following input shapes: * Bare integer (equivalent to `$.1`) * List of strings and integers * List of records with entries `value` and `optional` * String (parsed into a cell-path) ## Example usage An example of where `into cell-path` can be used is in working with `git config --list`. The git configuration has a tree structure that maps well to nushell records. With dynamic cell paths it is easy to convert `git config list` to a record: ```nushell git config --list | lines | parse -r '^(?<key>[^=]+)=(?<value>.*)' | reduce --fold {} {|entry, result| let path = $entry.key | into cell-path $result | upsert $path {|| $entry.value } } | select remote ``` Output: ``` ╭────────┬──────────────────────────────────────────────────────────────────╮ │ │ ╭──────────┬───────────────────────────────────────────────────╮ │ │ remote │ │ │ ╭───────┬───────────────────────────────────────╮ │ │ │ │ │ upstream │ │ url │ git@github.com:nushell/nushell.git │ │ │ │ │ │ │ │ fetch │ +refs/heads/*:refs/remotes/upstream/* │ │ │ │ │ │ │ ╰───────┴───────────────────────────────────────╯ │ │ │ │ │ │ ╭───────┬─────────────────────────────────────╮ │ │ │ │ │ origin │ │ url │ git@github.com:drbrain/nushell │ │ │ │ │ │ │ │ fetch │ +refs/heads/*:refs/remotes/origin/* │ │ │ │ │ │ │ ╰───────┴─────────────────────────────────────╯ │ │ │ │ ╰──────────┴───────────────────────────────────────────────────╯ │ ╰────────┴──────────────────────────────────────────────────────────────────╯ ``` ## Errors `lex()` + `parse_cell_path()` are forgiving about what is allowed in a cell-path so it will allow what appears to be nonsense to become a cell-path: ```nushell let table = [["!@$%^&*" value]; [key value]] $table | get ("!@$%^&*.0" | into cell-path) # => key ``` But it will reject bad cell-paths: ``` ❯ "a b" | into cell-path Error: nu:🐚:cant_convert × Can't convert to cell-path. ╭─[entry #14:1:1] 1 │ "a b" | into cell-path · ───────┬────── · ╰── can't convert string to cell-path ╰──── help: "a b" is not a valid cell-path (Parse mismatch during operation.) ``` # User-Facing Changes New conversion command `into cell-path` # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting Automatic documentation updates |
||
|
ff5815c0a3
|
remove cp-old (#11622)
# Description The `cp-old` command has been deprecated for a few releases now. It should be safe to remove it once and for all. Let's see. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |
||
|
ee6547dbb7
|
Initial implementation of umv from uutils (#10822)
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description Hi, This closes #10446 , wherein we start implementing `mv` from `uutils`. There are some stuff to iron out, particularly * Decide on behavior from ignored tests * Wait for release/PRs to be approved on `uutils` side, but still can be tested for now. See [PR approved](https://github.com/uutils/coreutils/pull/5428), and [pending](https://github.com/uutils/coreutils/pull/5429). * `--progress` does not seem to work on `uutils mv` either and have not checked whether certain `X` size has to be achieved in order for it to appear, thus something to investigate as well, but thought it wasnt important enough to not make the PR. See [issue comment](https://github.com/nushell/nushell/issues/10446#issuecomment-1764497988), on the possible strategy to follow, mainly copy what we did with `ucp`. I still left some comments on purpose particularly on tests, which of course would be removed before something is decided here. :) @fdncred <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - [X] `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - [X] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - [X] `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - [X] `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library <!-- > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |
||
|
84742275a1
|
Add ulimit command (#11324)
# Description Add `ulimit` command to Nushell. Closes #9563 Closes #3976 Related pr #11246 Reference: https://github.com/fish-shell/fish-shell/blob/master/fish-rust/src/builtins/ulimit.rs https://github.com/mirror/busybox/blob/master/shell/shell_common.c#L529 # User-Facing Changes ``` nushell on ulimit is 📦 v0.88.2 via 🦀 v1.72.1 [3/246] ❯ ulimit -a ╭────┬──────────────────────────────────────────────────────────────────────────┬───────────┬───────────╮ │ # │ description │ soft │ hard │ ├────┼──────────────────────────────────────────────────────────────────────────┼───────────┼───────────┤ │ 0 │ Maximum size of core files created (kB, -c) │ unlimited │ unlimited │ │ 1 │ Maximum size of a process's data segment (kB, -d) │ unlimited │ unlimited │ │ 2 │ Controls of maximum nice priority (-e) │ 0 │ 0 │ │ 3 │ Maximum size of files created by the shell (kB, -f) │ unlimited │ unlimited │ │ 4 │ Maximum number of pending signals (-i) │ 55273 │ 55273 │ │ 5 │ Maximum size that may be locked into memory (kB, -l) │ 8192 │ 8192 │ │ 6 │ Maximum resident set size (kB, -m) │ unlimited │ unlimited │ │ 7 │ Maximum number of open file descriptors (-n) │ 1024 │ 524288 │ │ 8 │ Maximum bytes in POSIX message queues (kB, -q) │ 800 │ 800 │ │ 9 │ Maximum realtime scheduling priority (-r) │ 0 │ 0 │ │ 10 │ Maximum stack size (kB, -s) │ 8192 │ unlimited │ │ 11 │ Maximum amount of CPU time in seconds (seconds, -t) │ unlimited │ unlimited │ │ 12 │ Maximum number of processes available to the current user (-u) │ 55273 │ 55273 │ │ 13 │ Maximum amount of virtual memory available to each process (kB, -v) │ unlimited │ unlimited │ │ 14 │ Maximum number of file locks (-x) │ unlimited │ unlimited │ │ 15 │ Maximum contiguous realtime CPU time (-y) │ unlimited │ unlimited │ ╰────┴──────────────────────────────────────────────────────────────────────────┴───────────┴───────────╯ nushell on ulimit is 📦 v0.88.2 via 🦀 v1.72.1 ❯ ulimit -s ╭───┬─────────────────────────────┬──────┬───────────╮ │ # │ description │ soft │ hard │ ├───┼─────────────────────────────┼──────┼───────────┤ │ 0 │ Maximum stack size (kB, -s) │ 8192 │ unlimited │ ╰───┴─────────────────────────────┴──────┴───────────╯ nushell on ulimit is 📦 v0.88.2 via 🦀 v1.72.1 ❯ ulimit -s 100 nushell on ulimit is 📦 v0.88.2 via 🦀 v1.72.1 ❯ ulimit -s ╭───┬─────────────────────────────┬──────┬──────╮ │ # │ description │ soft │ hard │ ├───┼─────────────────────────────┼──────┼──────┤ │ 0 │ Maximum stack size (kB, -s) │ 100 │ 100 │ ╰───┴─────────────────────────────┴──────┴──────╯ nushell on ulimit is 📦 v0.88.2 via 🦀 v1.72.1 ``` # Tests + Formatting - [x] add commands::ulimit::limit_set_soft1 - [x] add commands::ulimit::limit_set_soft2 - [x] add commands::ulimit::limit_set_hard1 - [x] add commands::ulimit::limit_set_hard2 - [x] add commands::ulimit::limit_set_invalid1 - [x] add commands::ulimit::limit_set_invalid2 - [x] `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - [x] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - [x] `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - [x] `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library |
||
|
fd77114d82
|
Add format meta command (#11334)
|
||
|
e290fa0e68
|
Add stor family of commands (#11170)
# Description This PR adds the `stor` family of commands. These commands are meant to create, open, insert, update, delete, reset data in an in-memory sqlite database. This is really an experiment to see how creatively we can use an in-memory database. ``` Usage: > stor Subcommands: stor create - Create a table in the in-memory sqlite database stor delete - Delete a table or specified rows in the in-memory sqlite database stor export - Export the in-memory sqlite database to a sqlite database file stor import - Import a sqlite database file into the in-memory sqlite database stor insert - Insert information into a specified table in the in-memory sqlite database stor open - Opens the in-memory sqlite database stor reset - Reset the in-memory database by dropping all tables stor update - Update information in a specified table in the in-memory sqlite database Flags: -h, --help - Display the help message for this command Input/output types: ╭─#─┬──input──┬─output─╮ │ 0 │ nothing │ string │ ╰───┴─────────┴────────╯ ``` ### Examples ## stor create ```nushell ❯ stor create --table-name nudb --columns {bool1: bool, int1: int, float1: float, str1: str, datetime1: datetime} ╭──────┬────────────────╮ │ nudb │ [list 0 items] │ ╰──────┴────────────────╯ ``` ## stor insert ```nushell ❯ stor insert --table-name nudb --data-record {bool1: true, int1: 2, float1: 1.1, str1: fdncred, datetime1: 2023-04-17} ╭──────┬───────────────╮ │ nudb │ [table 1 row] │ ╰──────┴───────────────╯ ``` ## stor open ```nushell ❯ stor open | table -e ╭──────┬────────────────────────────────────────────────────────────────────╮ │ │ ╭─#─┬id─┬bool1┬int1┬float1┬──str1───┬─────────datetime1──────────╮ │ │ nudb │ │ 0 │ 1 │ 1 │ 2 │ 1.10 │ fdncred │ 2023-04-17 00:00:00 +00:00 │ │ │ │ ╰───┴───┴─────┴────┴──────┴─────────┴────────────────────────────╯ │ ╰──────┴────────────────────────────────────────────────────────────────────╯ ``` ## stor update ```nushell ❯ stor update --table-name nudb --update-record {str1: toby datetime1: 2021-04-17} --where-clause "bool1 = 1" ╭──────┬───────────────╮ │ nudb │ [table 1 row] │ ╰──────┴───────────────╯ ❯ stor open | table -e ╭──────┬─────────────────────────────────────────────────────────────────╮ │ │ ╭─#─┬id─┬bool1┬int1┬float1┬─str1─┬─────────datetime1──────────╮ │ │ nudb │ │ 0 │ 1 │ 1 │ 2 │ 1.10 │ toby │ 2021-04-17 00:00:00 +00:00 │ │ │ │ ╰───┴───┴─────┴────┴──────┴──────┴────────────────────────────╯ │ ╰──────┴─────────────────────────────────────────────────────────────────╯ ``` ## insert another row ```nushell ❯ stor insert --table-name nudb --data-record {bool1: true, int1: 5, float1: 1.1, str1: fdncred, datetime1: 2023-04-17} ╭──────┬────────────────╮ │ nudb │ [table 2 rows] │ ╰──────┴────────────────╯ ❯ stor open | table -e ╭──────┬────────────────────────────────────────────────────────────────────╮ │ │ ╭─#─┬id─┬bool1┬int1┬float1┬──str1───┬─────────datetime1──────────╮ │ │ nudb │ │ 0 │ 1 │ 1 │ 2 │ 1.10 │ toby │ 2021-04-17 00:00:00 +00:00 │ │ │ │ │ 1 │ 2 │ 1 │ 5 │ 1.10 │ fdncred │ 2023-04-17 00:00:00 +00:00 │ │ │ │ ╰───┴───┴─────┴────┴──────┴─────────┴────────────────────────────╯ │ ╰──────┴────────────────────────────────────────────────────────────────────╯ ``` ## stor delete (specific row(s)) ```nushell ❯ stor delete --table-name nudb --where-clause "int1 == 5" ╭──────┬───────────────╮ │ nudb │ [table 1 row] │ ╰──────┴───────────────╯ ``` ## insert multiple tables ```nushell ❯ stor create --table-name nudb1 --columns {bool1: bool, int1: int, float1: float, str1: str, datetime1: datetime} ╭───────┬────────────────╮ │ nudb │ [table 1 row] │ │ nudb1 │ [list 0 items] │ ╰───────┴────────────────╯ ❯ stor insert --table-name nudb1 --data-record {bool1: true, int1: 2, float1: 1.1, str1: fdncred, datetime1: 2023-04-17} ╭───────┬───────────────╮ │ nudb │ [table 1 row] │ │ nudb1 │ [table 1 row] │ ╰───────┴───────────────╯ ❯ stor create --table-name nudb2 --columns {bool1: bool, int1: int, float1: float, str1: str, datetime1: datetime} ╭───────┬────────────────╮ │ nudb │ [table 1 row] │ │ nudb1 │ [table 1 row] │ │ nudb2 │ [list 0 items] │ ╰───────┴────────────────╯ ❯ stor insert --table-name nudb2 --data-record {bool1: true, int1: 2, float1: 1.1, str1: fdncred, datetime1: 2023-04-17} ╭───────┬───────────────╮ │ nudb │ [table 1 row] │ │ nudb1 │ [table 1 row] │ │ nudb2 │ [table 1 row] │ ╰───────┴───────────────╯ ``` ## stor delete (specific table) ```nushell ❯ stor delete --table-name nudb1 ╭───────┬───────────────╮ │ nudb │ [table 1 row] │ │ nudb2 │ [table 1 row] │ ╰───────┴───────────────╯ ``` ## stor reset (all tables are deleted) ```nushell ❯ stor reset ``` ## stor export ```nushell ❯ stor export --file-name nudb.sqlite3 ╭──────┬───────────────╮ │ nudb │ [table 1 row] │ ╰──────┴───────────────╯ ❯ open nudb.sqlite3 | table -e ╭──────┬────────────────────────────────────────────────────────────────────╮ │ │ ╭─#─┬id─┬bool1┬int1┬float1┬──str1───┬─────────datetime1──────────╮ │ │ nudb │ │ 0 │ 1 │ 1 │ 5 │ 1.10 │ fdncred │ 2023-04-17 00:00:00 +00:00 │ │ │ │ ╰───┴───┴─────┴────┴──────┴─────────┴────────────────────────────╯ │ ╰──────┴────────────────────────────────────────────────────────────────────╯ ❯ open nudb.sqlite3 | schema | table -e ╭────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ │ ╭──────┬──────────────────────────────────────────────────────────────────────────────────────────────────╮ │ │ tables │ │ │ ╭───────────────┬──────────────────────────────────────────────────────────────────────────────╮ │ │ │ │ │ nudb │ │ │ ╭─#─┬─cid─┬───name────┬─────type─────┬─notnull─┬───────default────────┬─pk─╮ │ │ │ │ │ │ │ │ columns │ │ 0 │ 0 │ id │ INTEGER │ 1 │ │ 1 │ │ │ │ │ │ │ │ │ │ │ 1 │ 1 │ bool1 │ BOOLEAN │ 0 │ │ 0 │ │ │ │ │ │ │ │ │ │ │ 2 │ 2 │ int1 │ INTEGER │ 0 │ │ 0 │ │ │ │ │ │ │ │ │ │ │ 3 │ 3 │ float1 │ REAL │ 0 │ │ 0 │ │ │ │ │ │ │ │ │ │ │ 4 │ 4 │ str1 │ VARCHAR(255) │ 0 │ │ 0 │ │ │ │ │ │ │ │ │ │ │ 5 │ 5 │ datetime1 │ DATETIME │ 0 │ STRFTIME('%Y-%m-%d │ 0 │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ %H:%M:%f', 'NOW') │ │ │ │ │ │ │ │ │ │ │ ╰─#─┴─cid─┴───name────┴─────type─────┴─notnull─┴───────default────────┴─pk─╯ │ │ │ │ │ │ │ │ constraints │ [list 0 items] │ │ │ │ │ │ │ │ foreign_keys │ [list 0 items] │ │ │ │ │ │ │ │ indexes │ [list 0 items] │ │ │ │ │ │ │ ╰───────────────┴──────────────────────────────────────────────────────────────────────────────╯ │ │ │ │ ╰──────┴──────────────────────────────────────────────────────────────────────────────────────────────────╯ │ ╰────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ ``` ## Using with `query db` ```nushell ❯ stor open | query db "select * from nudb" ╭─#─┬id─┬bool1┬int1┬float1┬──str1───┬─────────datetime1──────────╮ │ 0 │ 1 │ 1 │ 5 │ 1.10 │ fdncred │ 2023-04-17 00:00:00 +00:00 │ ╰───┴───┴─────┴────┴──────┴─────────┴────────────────────────────╯ ``` ## stor import ```nushell ❯ stor open # note, nothing is returned. there is nothing in memory, atm. ❯ stor import --file-name nudb.sqlite3 ╭──────┬───────────────╮ │ nudb │ [table 1 row] │ ╰──────┴───────────────╯ ❯ stor open | table -e ╭──────┬────────────────────────────────────────────────────────────────────╮ │ │ ╭─#─┬id─┬bool1┬int1┬float1┬──str1───┬─────────datetime1──────────╮ │ │ nudb │ │ 0 │ 1 │ 1 │ 5 │ 1.10 │ fdncred │ 2023-04-17 00:00:00 +00:00 │ │ │ │ ╰───┴───┴─────┴────┴──────┴─────────┴────────────────────────────╯ │ ╰──────┴────────────────────────────────────────────────────────────────────╯ ``` TODO: - [x] `stor export` - Export a fully formed sqlite db file. - [x] `stor import` - Imports a specified sqlite db file. - [x] Perhaps feature-gate it with the sqlite feature - [x] Update `query db` to work with the in-memory database - [x] Remove `open --in-memory` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |