# Description
an example should show what happens quite clearly 😋
> **Note**
> the ugly spanned errors you'll see below are fixed in
https://github.com/nushell/nushell/pull/9039😌
in all cases we get
```
> std help commands does-not-exist-anywhere
Help pages from external command does-not-exist-anywhere:
No manual entry for does-not-exist-anywhere
Error:
× std::help::command_not_found
╭─[help:662:1]
662 │
663 │ let command = ($command | str join " ")
· ─┬─
· ╰── command not found
664 │
╰────
```
but
## ❌ before this PR
```
> std help does-not-exist-anywhere
Help pages from external command does-not-exist-anywhere:
No manual entry for does-not-exist-anywhere
```
without any error, which makes it inconsistent with all the other `std
help` commands which give errors when not finding an item 🤔
## ✔️ with this PR
```
> std help does-not-exist-anywhere
Help pages from external command does-not-exist-anywhere:
No manual entry for does-not-exist-anywhere
Error:
× std::help::item_not_found
╭─[help:740:1]
740 │
741 │ let item = ($item | str join " ")
· ─┬─
· ╰── item not found
742 │
╰────
```
# User-Facing Changes
more consistent errors when using `std help` and `std help commands`, as
shown above.
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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
```
$nothing
```
related to #8963
cc/ @melMass
# Description
just a little refactoring attempt for `input list` 😌
i wanted to refactor even more, but `Select`, `MultiSelect` and
`FuzzySelect` do not share a common trait, i could not find a nice way
to reduce the big `if` block...
# User-Facing Changes
```
$nothing
```
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
Must be fixed; (though I'd test it)
Thanks for the reference [fdncred](https://github.com/fdncred).
close#9128
---------
Signed-off-by: Maxim Zhiburt <zhiburt@gmail.com>
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
related to
https://github.com/nushell/nushell/issues/8588#issuecomment-1538624565
# Description
this PR switches the date and log level in `std log` 👍
# User-Facing Changes
the date and log level are now swapped in the `std log` format.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
Must be fixed (but I would check).
I wonder if it was a regression caused by `Value::LazyRecord`.
I mean likely the issue was before the refactoring I did.
close#9130
---------
Signed-off-by: Maxim Zhiburt <zhiburt@gmail.com>
# Description
Update polars to 0.28.
Luckily, it didn't require major changes.
# User-Facing Changes
None.
(Apart from the fact that certain error messages will stop breaking
table formatting)
# Description
This PR updates `nu-glob` to add the latest changes and updates from
`rust-lang/glob` [v0.3.1](https://github.com/rust-lang/glob).
With these changes you can do this type of globbing
```rust
/// - `?` matches any single character.
///
/// - `*` matches any (possibly empty) sequence of characters.
///
/// - `**` matches the current directory and arbitrary subdirectories. This
/// sequence **must** form a single path component, so both `**a` and `b**`
/// are invalid and will result in an error. A sequence of more than two
/// consecutive `*` characters is also invalid.
///
/// - `[...]` matches any character inside the brackets. Character sequences
/// can also specify ranges of characters, as ordered by Unicode, so e.g.
/// `[0-9]` specifies any character between 0 and 9 inclusive. An unclosed
/// bracket is invalid.
///
/// - `[!...]` is the negation of `[...]`, i.e. it matches any characters
/// **not** in the brackets.
///
/// - The metacharacters `?`, `*`, `[`, `]` can be matched by using brackets
/// (e.g. `[?]`). When a `]` occurs immediately following `[` or `[!` then it
/// is interpreted as being part of, rather then ending, the character set, so
/// `]` and NOT `]` can be matched by `[]]` and `[!]]` respectively. The `-`
/// character can be specified inside a character sequence pattern by placing
/// it at the start or the end, e.g. `[abc-]`.
```
Example - with character sequences
Example - with character sequence negation
Example - normal globbing
Example - with character sequences
Not that, if you're using a character sequence by itself, you need to
enclose it in quotes, otherwise nushell will think it's a range. But if
you already have a type of a bare word already, no quotes are necessary,
as in the last example.
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
# Description
until now, a call to `toolkit` alone would give
```bash
Error: nu:🐚:external_command
× External command failed
╭─[entry #2:1:1]
1 │ toolkit
· ───┬───
· ╰── did you mean 'toolkit clippy'?
╰────
help: No such file or directory (os error 2)
```
which i find confusing after a `use toolkit.nu` 🤔
this PR adds a `main` command to `toolkit.nu` which runs the `help`
command on the module.
# User-Facing Changes
now
```
> use toolkit.nu
> toolkit
Usage:
> toolkit
Subcommands:
toolkit check pr - run all the necessary checks and tests to submit a perfect PR
toolkit clippy - check that you're using the standard code style
toolkit fmt - check standard code formatting and apply the changes
toolkit setup-git-hooks - set up git hooks to run:
- `toolkit fmt --check --verbose` on `git commit`
- `toolkit fmt --check --verbose` and `toolkit clippy --verbose` on `git push`
toolkit test - check that all the tests pass
toolkit test stdlib - run the tests for the standard library
Flags:
-h, --help - Display the help message for this command
```
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
# Description
- prettify formatting
- move message formatting to a private function
- allow short prefixes for loggers via `--short|-s` flag
# User-Facing Changes
- allow short prefixes for loggers via `--short|-s` flag
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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: amtoine <stevan.antoine@gmail.com>
# Description
This PR moves loading the standard library before the ide commands are
executed in hopes that the standard library will no longer give check
errors. I'm not sure if this will be a big performance impact or not.
We'll have to try it and 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
# Description
this PR makes `std help` commands return a table no matter the number of
matches when using `--find`.
as proposed by Darren, this would allow users to still rely on things
like
```nushell
let blah = (std help modules -f weather | get name)
```
even if there is a single match.
# User-Facing Changes
`std help ... --find ...` now returns a table as `help ... --find ...`
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
# Description
- remove redundant `@` after `echo off`
- use `call :build` to simplify code
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
# 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.
-->
Makes in so if you run `std help <external>` it will run `man <command>`
to get help pages. This command is configurable w/ the `$env.NU_HELPER`
var.
This will close#8032
Examples:
`std help rg` will display the ripgrep help pages
Todo:
- [x] Make flags and fallback configurable
- [x] Improve the warning that it is external
- [ ] Implement `--find` for external commands
# User-Facing Changes
Users will now be able to run `std help` on external commands
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
# Description
- Log levels are now exported members of `std log`, e.g. `std log
CRITICAL_LEVEL`
- Added `std log custom` command that allows to declare custom message
format (actual message replaces `%MSG%` in the template) with
user-defined log level.
# User-Facing Changes
New possibilities included in description
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
# Description
as stated in the `0.79` release note, this PR removes the `old-alias`
and `export old-alias` commands, which were deprecated before.
# User-Facing Changes
`old-alias` is gone for good 😌
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
already mentionned in the `0.79` release note.
# Description
the plan of deprecating `source` never really came to conclusion, so i
propose to move it out of the deprecated commands in this PR.
i've moved it to `nu-command::misc`, which can be changed 👍
# User-Facing Changes
```
$nothing
```
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
# Description
- highlight directory separators with light green (for regular user) and
light red (for admin) colors respectively
- highlight colons and slashes in the right prompt with light magenta
- underline AM/PM in the right prompt
- use long options to enhance readability
How it looks in MATE Terminal with Tango color theme:
# User-Facing Changes
- highlight directory separators in light green (for regular user) and
red colors (for admin)
- highlight colons and slashes in the right prompt with light magenta
- underline AM/PM in the right prompt
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
# Description
Currently, error spans for I/O errors in an `rm` invocation always point
to the `rm` argument. This isn't ideal, because the user loses context
as to which “target” actually had a problem:
Shadow the existing `span` variable in outer scope in `rm`'s
implementation for the errors that may be detected while handling I/O
results. This is desired, because all failures from this point are
target-specific, and pointing at the argument that generated the target
instead is better. The end user should now see this:
# User-Facing Changes
* When `rm` encounters I/O errors, their spans now point to the “target”
argument associated with the error, rather than the `rm` token.
# Tests + Formatting
No tests currently cover this. I'm open to adding tests, but adding as
follow-up sounds better ATM, since this wasn't covered before.
# After Submitting
Nothing needs to be done here, AFAIK. No I/O errors are currently
demonstrated in official docs, though maybe they should be?
# Description
Follow-up of #8940. As @bobhy pointed out, it makes sense for the
behaviour of flags to match the one for positional arguments, where
default values are of type `Option<Value>` instead of
`Option<Expression>`.
# User-Facing Changes
The same ones from the original PR:
- Flag default values will now be parsed as constants.
- If the default value is not a constant, a parser error is displayed.
# Tests + Formatting
A [new
test](e34e2d35f4/src/tests/test_engine.rs (L338-L344))
has been added to verify the new restriction.
# Description
Before this PR, `math round` ignores the input if it's an `int`. This
results in the following behaviour:
```
> 123 | math round --precision -1
123
```
When the correct result is 120.
Now `int values` are converted to `float values` before actually
rounding up the number in order to take advantage of the float
implementation.
Fixes#9049.
# Description
The previous behaviour broke for me because I didn't have `sh` in my
path for my nu script. I think we shouldn't assume that just because a
file ends with `.sh` it should be executed with `sh`. `sh` might not be
available or the script might contain a hashbang for a different shell.
The idea with this PR is that nushell shouldn't assume anything about
executable files and just execute them. Later on we can think about how
non-executable files should be executed if we detect they are a script.
# User-Facing Changes
This may break some people's scripts or habits if they have wrong
assumptions about `.sh` files. We can tell them to add a hashbang and +x
bit to execute shell scripts, or prepend `bash`. If this a common
assumption something like this should be added to the book
# Tests + Formatting
I only tested manually and that did work
# After Submitting
Co-authored-by: Jelle Besseling <jelle@bigbridge.nl>
cc/ @fdncred
# Description
in the examples of `std bench` there is an expanded table without
explicitely expanding it...
this PR adds a `table -e` to the `std bench` call in the example.
# User-Facing Changes
the help page of `std bench` now does make sense 😌
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
# Description
This PR impacts the nushell sqlite history only.
This is the first PR that enables history isolation in nushell for the
sqlite history. Hopefully, we can continue building on this.
This PR allows "history isolation" which means that other nushell
session's history won't be available in the current session when using
the uparrow/downarrow history navigation. This change only impacts the
uparrow downarrow history navigation.
What remains to be done is making ctrl+r history menu respect this
setting too. Right now, the history menu will still show you all entries
from all sessions.
The history command also shows all history items from all sessions. This
may remain unchanged since you can just filter by history session right
now.
This also fixes a bug where the session id is 0 in the sqlite history
since my April 18th reedline PR.
Closes#9064
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
# Description
this PR moves the three individual call to `load_standard_library` in
the "Nushell branches" of `run.rs` into a single one, before the `if`,
in `main.rs`.
# User-Facing Changes
```
$nothing
```
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
Should close on of the points in
- https://github.com/nushell/nushell/issues/8813
# Description
this PR uses the new `--columns` option for `find` to filter the results
of the `std help` commands on the `usage`, `name` and `search_terms`
columns.
# User-Facing Changes
the `--find` option of `std help` commands should match more closely the
built-in `help` commands output.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
Should close on of the points in
- https://github.com/nushell/nushell/issues/8813
# Description
before this PR, we had a problem
```
cargo run -- -c '{
modules: ((help modules | get name) == (std help modules | get name))
aliases: ((help aliases | get name) == (std help aliases | get name))
externs: ((help externs | get name) == (std help externs | get name))
operators: ((help operators | get name) == (std help operators | get name))
commands: ((help commands | get name) == (std help commands | get name))
}'
```
would give
```
╭───────────┬───────╮
│ modules │ false │
│ aliases │ true │
│ externs │ true │
│ operators │ false │
│ commands │ true │
╰───────────┴───────╯
```
this PR removes the `name` sorting so that the orders are the same
between the `std` implementation and the built-in one.
> **Note**
> run the same `cargo run` command as above and see
> ```
> ╭───────────┬──────╮
> │ modules │ true │
> │ aliases │ true │
> │ externs │ true │
> │ operators │ true │
> │ commands │ true │
> ╰───────────┴──────╯
> ```
# User-Facing Changes
the operators in `std help ...` will be sorted just as the built-in
`help ...`.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
# Description
This is WIP. This generates a simplistic AST so that we can call it from
the vscode side for semantic token highlighting. The output is a
minified version of this screenshot.
The script
```
def test [arg] {
print $arg
for i in (seq 1 10) {
echo $i
}
}
```
The simplistic AST
```json
[{"content":"def","index":0,"shape":"shape_internalcall","span":{"end":15,"start":12}},{"content":"test","index":1,"shape":"shape_string","span":{"end":20,"start":16}},{"content":"[arg]","index":2,"shape":"shape_signature","span":{"end":26,"start":21}},{"content":"{\r\n ","index":3,"shape":"shape_closure","span":{"end":32,"start":27}},{"content":"print","index":4,"shape":"shape_internalcall","span":{"end":37,"start":32}},{"content":"$arg","index":5,"shape":"shape_variable","span":{"end":42,"start":38}},{"content":"for","index":6,"shape":"shape_internalcall","span":{"end":49,"start":46}},{"content":"i","index":7,"shape":"shape_vardecl","span":{"end":51,"start":50}},{"content":"in","index":8,"shape":"shape_keyword","span":{"end":54,"start":52}},{"content":"(","index":9,"shape":"shape_block","span":{"end":56,"start":55}},{"content":"seq","index":10,"shape":"shape_internalcall","span":{"end":59,"start":56}},{"content":"1","index":11,"shape":"shape_int","span":{"end":61,"start":60}},{"content":"10","index":12,"shape":"shape_int","span":{"end":64,"start":62}},{"content":")","index":13,"shape":"shape_block","span":{"end":65,"start":64}},{"content":"{\r\n ","index":14,"shape":"shape_block","span":{"end":73,"start":66}},{"content":"echo","index":15,"shape":"shape_internalcall","span":{"end":77,"start":73}},{"content":"$i","index":16,"shape":"shape_variable","span":{"end":80,"start":78}},{"content":"\r\n }","index":17,"shape":"shape_block","span":{"end":85,"start":80}},{"content":"\r\n}","index":18,"shape":"shape_closure","span":{"end":88,"start":85}}]
```
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
# Description
Add option that combines both output streams to the `run-external`
command.
This allows you to do something like this:
```nushell
let res = do -i { run-external --redirect-combine <command that prints to stdout and stderr> } | complete
if $res.exit_code != 0 {
# Only print output when command has failed.
print "The command has failed, these are the logs:"
print $res.stdout
}
```
# User-Facing Changes
No breaking changes, just an extra option.
# Tests + Formatting
Added a test that checks the new option
# 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: Jelle Besseling <jelle@bigbridge.nl>
# Description
Fix getting the cursor position, when it's at the end of the
commandline.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
# After Submitting
This PR just tidies up some tests by removing unused code:
1. If the filesystem is not touched, don't use the filesystem
playground/sandbox
2. If the filesystem is not touched, don't specify the `cwd`
3. If the command is short, don't bother wrapping it in `pipeline()`
4. If the command doesn't have quotes, don't bother with a `r#"..."#`
raw string
Part of #8670.
as can be seen
[here](https://github.com/nushell/nushell/labels?q=needs-), i've created
the `needs-triage` and `needs-core-team-attention` labels.
in this PR, i made the `needs-triage` a default label to all the issue
templates 😋
# Description
i use `std clip` to copy everything from `nushell`.
however i have the auto-expand on tables enabled and when i use `clip`
on large tables, it does not copy what i see but the collapsed data => i
have to edit the line and add `| table --expand` manually, which is a
pain to do regularly 😱
in this PR, i just add `--expand` to `std clip` to automatically expand
the data before copying it 😋
# User-Facing Changes
exploring the `Cargo.toml` of `nushell` with auto-expand, one might see
```
> open Cargo.toml | get package.metadata.binstall.overrides
╭────────────────────────┬───────────────────╮
│ │ ╭─────────┬─────╮ │
│ x86_64-pc-windows-msvc │ │ pkg-fmt │ zip │ │
│ │ ╰─────────┴─────╯ │
╰────────────────────────┴───────────────────╯
```
but then
```
open Cargo.toml | get package.metadata.binstall.overrides | clip
```
would only copy
```
╭────────────────────────┬──────────────────╮
│ x86_64-pc-windows-msvc │ {record 1 field} │
╰────────────────────────┴──────────────────╯
```
...
now
```
open Cargo.toml | get package.metadata.binstall.overrides | clip --expand
```
will copy the expanded record 👍
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
Should address the first point of
- https://github.com/nushell/nushell/issues/8696.
# Description
i've seen a few appearances of this `benchmark` idea in recent works on
`nu-std`, so i thought it would be great to add it finally.
# User-Facing Changes
a new `std bench` command to measure the performance of `nushell`
closures and code blocks.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
```
$nothing
```
# Description
Extends the `extern` syntax to allow commands that accept raw arguments.
This is mainly added to allow wrapper type scripts for external
commands.
This is an example on how this can be used:
```nushell
extern foo [...rest] {
print ($rest | str join ',' )
}
foo --bar baz -- -q -u -x
# => --bar,baz,--,-q,-u,-x
```
(It's only possible to accept a single ...varargs argument in the
signature)
# User-Facing Changes
No breaking changes, just extra possibilities.
# Tests + Formatting
Added a test for this new behaviour and ran the toolkit pr checker
# After Submitting
This is advanced functionality but it should be documented, I will open
a new PR on the book for that
Co-authored-by: Jelle Besseling <jelle@bigbridge.nl>
# Description
The `members` parameter of `use` is specified as type `any`, but it's
really a string or list of strings or `*`. So add some examples that
mention what you can specify for `members`.
Also mention `help modules` and `help std`, since you probably want to
use the standard library or another defined modules.
Sidenote: I tried to run the examples for `use` as tests like is done
for the other commands. That panics with `missing module command`. I
assume this is known.
# User-Facing Changes
`help use` now looks like this:
```nushell
Use definitions from a module, making them available in your shell.
See `help std` for the standard library module.
See `help modules` to list all available modules.
This command is a parser keyword. For details, check:
https://www.nushell.sh/book/thinking_in_nu.html
Usage:
> use <module> (members)
Flags:
-h, --help - Display the help message for this command
Parameters:
module <string>: Module or module file
(optional) members <any>: Which members of the module to import
Examples:
Define a custom command in a module and call it
> module spam { export def foo [] { "foo" } }; use spam foo; foo
foo
Define a custom command that participates in the environment in a module and call it
> module foo { export def-env bar [] { let-env FOO_BAR = "BAZ" } }; use foo bar; bar; $env.FOO_BAR
BAZ
Use a plain module name to import its definitions qualified by the module name
> module spam { export def foo [] { "foo" }; export def bar [] { "bar" } }; use spam; (spam foo) + (spam bar)
foobar
Specify * to use all definitions in a module
> module spam { export def foo [] { "foo" }; export def bar [] { "bar" } }; use spam *; (foo) + (bar)
foobar
To use commands with spaces, like subcommands, surround them with quotes
> module spam { export def 'foo bar' [] { "baz" } }; use spam 'foo bar'; foo bar
baz
To use multiple definitions from a module, wrap them in a list
> module spam { export def foo [] { "foo" }; export def 'foo bar' [] { "baz" } }; use spam ['foo', 'foo bar']; (foo) + (foo bar)
foobaz
```
# Description
This PR bumps the rust toolchain from 1.66.1 to 1.67.1
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
# Description
Previously, `par-each` acted like a `flatmap`: first mapping the data,
then applying a `flatten`. This is unlike `each`, which just maps the
data. Now `par-each` works like `each` in this regard, leaving nested
data unflattened.
Fixes#8497
# User-Facing Changes
Previously:
`[1 2 3] | par-each {|e| [$e, $e] }` --> `[1,1,2,2,3,3]`
Now:
`[1 2 3] | par-each {|e| [$e, $e] }` --> `[[1,1],[2,2],[3,3]]`
# Tests
This adds one test that verifies the lack of flattening for `par-each`.
# Description
This PR fixes a problem due to me landing an out of date PR that stopped
nushell from compiling.
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
close? #8060
Quite a bit of refactoring took place.
I believe a few improvements to collapse/expand were made.
I've tried to track any performance regressions and seems like it is
fine.
I've noticed something different now with default configuration path or
something in this regard?
So I might missed something while testing because of this.
Requires some oversight.
---------
Signed-off-by: Maxim Zhiburt <zhiburt@gmail.com>
# Description
This PR fixes an issue described in #8890 where config variables
declared in command parameters cause the warning `use `let-env config =
...` instead of `let config = ...` to be printed.
# User-Facing Changes
The user is only warned when they define a config variable with a
warning with the type `record`.
# Tests + Formatting
I think this can only be tested manually by first trying to reproduce
#8890.
To test if the warning is still printed when it's supposed to be one can
add `let config = $env.config` to the end of the `config.nu` file.
