# Description
This PR refactors `drop columns` and fixes issues #10902 and #6846.
Tables with "holes" are now handled consistently, although still
somewhat awkwardly. That is, the columns in the first row are used to
determine which columns to drop, meaning that the columns displayed all
the way to the right by `table` may not be the columns actually being
dropped. For example, `[{a: 1}, {b: 2}] | drop column` will drop column
`a` instead of `b`. Before, this would give a list of empty records.
# User-Facing Changes
`drop columns` can now take records as input.
# Description
Based of the work and discussion in #10844, this PR adds the `exec`
command for Windows. This is done by simply spawning a
`std::process::Command` and then immediately exiting via
`std::process::exit` once the child process is finished. The child
process's exit code is passed to `exit`.
# User-Facing Changes
The `exec` command is now available on Windows, and there should be no
change in behaviour for Unix systems.
# Description
`split-by` only works on a `Record`, the error type was updated to
match, and now uses a more-specific type. (Two type fixes for the price
of one!)
The `usage` was updated to say "record" as well
# User-Facing Changes
* Providing the wrong type to `split-by` now gives an error messages
with the correct required input type
Previously:
```
❯ ls | get name | split-by type
Error: × unsupported input
╭─[entry #267:1:1]
1 │ ls | get name | split-by type
· ─┬─
· ╰── requires a table with one row for splitting
╰────
```
With this PR:
```
❯ ls | get name | split-by type
Error: nu:🐚:type_mismatch
× Type mismatch.
╭─[entry #1:1:1]
1 │ ls | get name | split-by type
· ─┬─
· ╰── requires a record to split
╰────
```
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
Only generated commands need to be updated
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
# Description
Limit the test `-p nu-command --test main
commands::run_external::redirect_combine` which uses `sh` to running on
`not(Windows)` like is done for other tests assuming unixy CLI items;
`sh` doesn't exist on Windows.
# User-Facing Changes
None; this is a change to tests only.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
- Replaced `start`/`end` with span.
- Fixed standard library.
- Add `help` option.
- Add a couple more errors for invalid record types.
Resolve#10914
# Description
# User-Facing Changes
- **BREAKING CHANGE:** `error make` now takes in `span` instead of
`start`/`end`:
```Nushell
error make {
msg: "Message"
label: {
text: "Label text"
span: (metadata $var).span
}
}
```
- `error make` now has a `help` argument for custom error help.
# Description
Pretty much all operations/commands in Nushell assume that the column
names/keys in a record and thus also in a table (which consists of a
list of records) are unique.
Access through a string-like cell path should refer to a single column
or key/value pair and our output through `table` will only show the last
mention of a repeated column name.
```nu
[[a a]; [1 2]]
╭─#─┬─a─╮
│ 0 │ 2 │
╰───┴───╯
```
While the record parsing already either errors with the
`ShellError::ColumnDefinedTwice` or silently overwrites the first
occurence with the second occurence, the table literal syntax `[[header
columns]; [val1 val2]]` currently still allowed the creation of tables
(and internally records with more than one entry with the same name.
This is not only confusing, but also breaks some assumptions around how
we can efficiently perform operations or in the past lead to outright
bugs (e.g. #8431 fixed by #8446).
This PR proposes to make this an error.
After this change another hole which allowed the construction of records
with non-unique column names will be plugged.
## Parts
- Fix `SE::ColumnDefinedTwice` error code
- Remove previous tests permitting duplicate columns
- Deny duplicate column in table literal eval
- Deny duplicate column in const eval
- Deny duplicate column in `from nuon`
# User-Facing Changes
`[[a a]; [1 2]]` will now return an error:
```
Error: nu:🐚:column_defined_twice
× Record field or table column used twice
╭─[entry #2:1:1]
1 │ [[a a]; [1 2]]
· ┬ ┬
· │ ╰── field redefined here
· ╰── field first defined here
╰────
```
this may under rare circumstances block code from evaluating.
Furthermore this makes some NUON files invalid if they previously
contained tables with repeated column names.
# Tests + Formatting
Added tests for each of the different evaluation paths that materialize
tables.
# Description
as we can see in the [documentation of
`str.to_lowercase`](https://doc.rust-lang.org/std/primitive.str.html#method.to_lowercase),
not only ASCII symbols have lower and upper variants.
- `str upcase` uses the correct method to convert the string
7ac5a01e2f/crates/nu-command/src/strings/str_/case/upcase.rs (L93)
- `str downcase` incorrectly converts only ASCII characters
7ac5a01e2f/crates/nu-command/src/strings/str_/case/downcase.rs (L124)
this PR uses `str.to_lower_case` instead of `str.to_ascii_lowercase` in
`str downcase`.
# User-Facing Changes
- upcase still works fine
```nushell
~ l> "ὀδυσσεύς" | str upcase
ὈΔΥΣΣΕΎΣ
```
- downcase now works
👉 before
```nushell
~ l> "ὈΔΥΣΣΕΎΣ" | str downcase
ὈΔΥΣΣΕΎΣ
```
👉 after
```nushell
~ l> "ὈΔΥΣΣΕΎΣ" | str downcase
ὀδυσσεύς
```
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
adds two tests
- `non_ascii_upcase`
- `non_ascii_downcase`
# After Submitting
# Description
Currently the following command is broken:
```nushell
echo a o+e> 1.txt
```
It's because we don't redirect output of `echo` command. This pr is
trying to fix it.
# Description
- this PR should close#10819
# User-Facing Changes
Behaviour is similar to pre 0.86.0 behaviour of the cp command and
should as such not have a user-facing change, only compared to the
current version, were the option is readded.
# After Submitting
I guess the documentation will be automatically updated and as this
feature is no further highlighted, probably, no more work will be needed
here.
# Considerations
coreutils actually allows a third option:
```
pub enum UpdateMode {
// --update=`all`,
ReplaceAll,
// --update=`none`
ReplaceNone,
// --update=`older`
// -u
ReplaceIfOlder,
}
```
namely `ReplaceNone`, which I have not added. Also I think that
specifying `--update 'abc'` is non functional.
# Description
Fixes: #10830
The issue happened during lite-parsing, when we want to put a
`LiteElement` to a `LitePipeline`, we do nothing if relative redirection
target is empty.
So the command `echo aaa o> | ignore` will be interpreted to `echo aaa |
ignore`.
This pr is going to check and return an error if redirection target is
empty.
# User-Facing Changes
## Before
```
❯ echo aaa o> | ignore # nothing happened
```
## After
```nushell
❯ echo aaa o> | ignore
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[entry #1:1:1]
1 │ echo aaa o> | ignore
· ─┬
· ╰── expected redirection target
╰────
```
# Description
Support pattern matching against the `null` literal. Fixes#10799
### Before
```nushell
> match null { null => "success", _ => "failure" }
failure
```
### After
```nushell
> match null { null => "success", _ => "failure" }
success
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Users can pattern match against a `null` literal.
# Description
`from tsv` and `from csv` both support a `--flexible` flag. This flag
can be used to "allow the number of fields in records to be variable".
Previously, a record's invariant that `rec.cols.len() == rec.vals.len()`
could be broken during parsing. This can cause runtime errors as in
#10693. Other commands, like `select` were also affected.
The inconsistencies are somewhat hard to see, as most nushell code
assumes an equal number of columns and values.
# Before
### Fewer values than columns
```nushell
> let record = (echo "one,two\n1" | from csv --flexible | first)
# There are two columns
> $record | columns | to nuon
[one, two]
# But only one value
> $record | values | to nuon
[1]
# And printing the record doesn't show the second column!
> $record | to nuon
{one: 1}
```
### More values than columns
```nushell
> let record = (echo "one,two\n1,2,3" | from csv --flexible | first)
# There are two columns
> $record | columns | to nuon
[one, two]
# But three values
> $record | values | to nuon
[1, 2, 3]
# And printing the record doesn't show the third value!
> $record | to nuon
{one: 1, two: 2}
```
# After
### Fewer values than columns
```nushell
> let record = (echo "one,two\n1" | from csv --flexible | first)
# There are two columns
> $record | columns | to nuon
[one, two]
# And a matching number of values
> $record | values | to nuon
[1, null]
# And printing the record works as expected
> $record | to nuon
{one: 1, two: null}
```
### More values than columns
```nushell
> let record = (echo "one,two\n1,2,3" | from csv --flexible | first)
# There are two columns
> $record | columns | to nuon
[one, two]
# And a matching number of values
> $record | values | to nuon
[1, 2]
# And printing the record works as expected
> $record | to nuon
{one: 1, two: 2}
```
# User-Facing Changes
Using the `--flexible` flag with `from csv` and `from tsv` will not
result in corrupted record state.
# 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.
-->
related to
- https://github.com/nushell/nushell/pull/10770
# Description
because some people look into `unfold` already (myself included lol) and
there will be 4 weeks with that new command which has a decent section
in the release note, i fear that
https://github.com/nushell/nushell/pull/10770 is a bit too brutal,
removing `unfold` without any warning...
this PR brings `unfold` back to life.
the `unfold` command will have a deprecation warning and will be removed
in 0.88.
# User-Facing Changes
`unfold` is only deprecated, not removed.
# Tests + Formatting
# After Submitting
# Description
This PR renames the `unfold` command to `generate`.
closes#10760
# 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.
-->
# Description
Changed `group-by` behavior to accept empty list as input and return an
empty record instead of throwing an error. I also replaced
`errors_if_input_empty()` test to reflect the new expected behavior.
See #10713
# User-Facing Changes
`[] | group-by` or `[] | group-by a` now returns empty record
# Tests + Formatting
1 test for emptied table i.e. list
---------
Signed-off-by: Oscar <71343264+0scvr@users.noreply.github.com>
Add `--ignore-errors` flag to reject.
This is a PR in reference to #10215 as select has the flag, but reject
hasn't
user can now add `-i` or `--ignore-errors` flag to turn every cell path
into option.
```nushell
> let arg = [0 5 a c]
> [[a b];[1 2] [3 4] [5 6]] | reject $a | to nuon
error index to large
# ----
> let arg = [0 5 a c]
> [[a b];[1 2] [3 4] [5 6]] | reject $a -i | to nuon
[[a, b]; [1, 2], [3, 4], [5, 6]]
```
(squashed version of #10557, clean commit history and review thread)
Fixes#10571, also potentially: #10364, #10211, #9558, #9310,
# Description
Changes processing of arguments to filesystem commands that are source
paths or globs.
Applies to `cp, cp-old, mv, rm, du` but not `ls` (because it uses a
different globbing interface) or `glob` (because it uses a different
globbing library).
The core of the change is to lookup the argument first as a file and
only glob if it is not. That way,
a path containing glob metacharacters can be referenced without glob
quoting, though it will have to be single quoted to avoid nushell
parsing.
Before: A file path that looks like a glob is not matched by the glob
specified as a (source) argument and takes some thinking about to
access. You might say the glob pattern shadows a file with the same
spelling.
```
> ls a*
╭───┬────────┬──────┬──────┬────────────────╮
│ # │ name │ type │ size │ modified │
├───┼────────┼──────┼──────┼────────────────┤
│ 0 │ a[bc]d │ file │ 0 B │ 34 seconds ago │
│ 1 │ abd │ file │ 0 B │ now │
│ 2 │ acd │ file │ 0 B │ now │
╰───┴────────┴──────┴──────┴────────────────╯
> cp --verbose 'a[bc]d' dest
copied /home/bobhy/src/rust/work/r4/abd to /home/bobhy/src/rust/work/r4/dest/abd
copied /home/bobhy/src/rust/work/r4/acd to /home/bobhy/src/rust/work/r4/dest/acd
> ## Note -- a[bc]d *not* copied, and seemingly hard to access.
> cp --verbose 'a\[bc\]d' dest
Error: × No matches found
╭─[entry #33:1:1]
1 │ cp --verbose 'a\[bc\]d' dest
· ─────┬────
· ╰── no matches found
╰────
> #.. but is accessible with enough glob quoting.
> cp --verbose 'a[[]bc[]]d' dest
copied /home/bobhy/src/rust/work/r4/a[bc]d to /home/bobhy/src/rust/work/r4/dest/a[bc]d
```
Before_2: if file has glob metachars but isn't a valid pattern, user
gets a confusing error:
```
> touch 'a[b'
> cp 'a[b' dest
Error: × Pattern syntax error near position 30: invalid range pattern
╭─[entry #13:1:1]
1 │ cp 'a[b' dest
· ──┬──
· ╰── invalid pattern
╰────
```
After: Args to cp, mv, etc. are tried first as literal files, and only
as globs if not found to be files.
```
> cp --verbose 'a[bc]d' dest
copied /home/bobhy/src/rust/work/r4/a[bc]d to /home/bobhy/src/rust/work/r4/dest/a[bc]d
> cp --verbose '[a][bc]d' dest
copied /home/bobhy/src/rust/work/r4/abd to /home/bobhy/src/rust/work/r4/dest/abd
copied /home/bobhy/src/rust/work/r4/acd to /home/bobhy/src/rust/work/r4/dest/acd
```
After_2: file with glob metachars but invalid pattern just works.
(though Windows does not allow file name to contain `*`.).
```
> cp --verbose 'a[b' dest
copied /home/bobhy/src/rust/work/r4/a[b to /home/bobhy/src/rust/work/r4/dest/a[b
```
So, with this fix, a file shadows a glob pattern with the same spelling.
If you have such a file and really want to use the glob pattern, you
will have to glob quote some of the characters in the pattern. I think
that's less confusing to the user: if ls shows a file with a weird name,
s/he'll still be able to copy, rename or delete it.
# User-Facing Changes
Could break some existing scripts. If user happened to have a file with
a globbish name but was using a glob pattern with the same spelling, the
new version will process the file and not expand the glob.
# 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.
-->
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
<!--
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 allows `open` to handle files with multiple extensions; i.e it
will try to call `from tar.gz`, `from gz` when calling
```nu
open file.tar.gz
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes.
# Description
This PR renames nushell's `cp` command to `cp-old` to make room for
`ucp` to be renamed to `cp`, making the coreutils version of `cp` the
default for nushell. After some period of time, we should remove
`cp-old` entirely.
# 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.
-->
This pr fix clippy warnings in latest clippy version(1.72.0):
Unfortunally it's not easy to handle for [try
fold](https://rust-lang.github.io/rust-clippy/master/index.html#/manual_try_fold)
warning in `start command`
Refer to known issue:
> This lint doesn’t take into account whether a function does something
on the failure case, i.e., whether short-circuiting will affect
behavior. Refactoring to try_fold is not desirable in those cases.
That's the case for our code, which does something on the failure case.
So this pr is making a little refactor on `try_commands`.
# Description
Closes#10537. Basically error message was unhelpful, and this temporary
measure adds back the nice previous nushell error message. Ideally, we
would like to add a more permanent solution mentioned in the issue
[comments](https://github.com/nushell/nushell/issues/10537#issuecomment-1743686122),
but since we want to have `ucp` as `cp` on new release, this is hackier
but way simpler so this fix should do it.
Only downside is that now behavior differs from `uutils` in the sense
that:
```
uutils:
> cp a foo/ bar
ls bar
# foo/a
nushell:
>ucp a foo/ bar
# directory error (not copied) ....
```
So, since its non fatal error, uutils copies a, but nushell errors out
with nothing copied. If we go to option 3 mentioned above, then we can
decide what we want to do, and perhaps continue on a non fatal error.
# 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
---------
Co-authored-by: amtoine <stevan.antoine@gmail.com>
Implemented URL decoding as a url subcommand, created corresponding unit
tests. The logic, examples and descriptions were based on the existing
`url encode` command.
Resolves#10563
# Description
Added a new `url decode` command to compliment the existing `url
encode`, as proposed by myself in #10563.
It takes a string, list of strings or cell path and produces the
corresponding decoded strings.
# User-Facing Changes
New url subcommand `url decode`, as described above.
# Tests + Formatting
I've added unit tests for the new subcommand and ensured all actions
outlined below showed no issues.
- [x] `cargo fmt --all -- --check`
- [x] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used`
- [x] `cargo test --workspace`
- [x] `cargo run -- -c "use std testing; testing run-tests --path
crates/nu-std"`
# Description
When referring to the type use `int` consistently. Only when referring
to the concept of integer numbers use `integer`.
- Fix `random integer` to `random int` tests
- Forgot in #10520
- Use int instead of integer in error messages
- Use int type name in bits commands
- Fix messages in `for` examples
- Use int typename in `into` commands
- Use int typename in rest of commands
- Report errors in `nu-protocol` with int typename
Work for #10332
# User-Facing Changes
User errorrs should now use `int` so you can easily find the necessary
commands or type annotations.
# Tests + Formatting
Only two tests found that needed updating
# Description
This removes the old style "cd with abbreviations" that would attempt to
guess what directory you wanted to `cd` to. This would sometimes have
false positives, so we left it off by default in the config.
In the current main, we have much-improved path completions
(https://github.com/nushell/nushell/pull/10543) so you can now do `cd
a/b<tab>` and get a much better experience (because you can see the
directory you're about to cd to). This removes the need for the previous
abbreviation system.
# User-Facing Changes
This does remove the old abbreviation system. It will likely mean that
old config files that have settings for abbreviations will now get
errors.
update: here's an example of the error you'll see:
# 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.
-->
<!--
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.
-->
> [!NOTE]
> This PR description originally used examples where the `generator`
closure returned a list. It has since been updated to use records
instead.
The `unfold` command allows users to dynamically generate streams of
data. The stream is generated by repeatedly invoking a `generator`
closure. The `generator` closure accepts a single argument and returns a
record containing two optional keys: 'out' and 'next'. Each invocation,
the 'out' value, if present, is added to the stream. If a 'next' key is
present, it is used as the next argument to the closure, otherwise
generation stops.
The name "unfold" is borrowed from other functional-programming
languages. Whereas `fold` (or `reduce`) takes a stream of values and
outputs a single value, `unfold` takes a single value and outputs a
stream of values.
### Examples
A common example of using `unfold` is to generate a fibbonacci sequence.
See
[here](6ffdac103c/src/sources.rs (L65))
for an example of this in rust's `itertools`.
```nushell
> unfold [0, 1] {|fib| {out: $fib.0, next: [$fib.1, ($fib.0 + $fib.1)]} } | first 10
───┬────
0 │ 0
1 │ 1
2 │ 1
3 │ 2
4 │ 3
5 │ 5
6 │ 8
7 │ 13
8 │ 21
9 │ 34
───┴────
```
This command is particularly useful when consuming paginated APIs, like
Github's. Previously, nushell users might use a loop and buffer
responses into a list, before returning all responses at once. However,
this behavior is not desirable if the result result is very large. Using
`unfold` avoids buffering and allows subsequent pipeline stages to use
the data concurrently, as it's being fetched.
#### Before
```nushell
mut pages = []
for page in 1.. {
let resp = http get (
{
scheme: https,
host: "api.github.com",
path: "/repos/nushell/nushell/issues",
params: {
page: $page,
per_page: $PAGE_SIZE
}
} | url join)
$pages = ($pages | append $resp)
if ($resp | length) < $PAGE_SIZE {
break
}
}
$pages
```
#### After
```nu
unfold 1 {|page|
let resp = http get (
{
scheme: https,
host: "api.github.com",
path: "/repos/nushell/nushell/issues",
params: {
page: $page,
per_page: $PAGE_SIZE
}
} | url join)
if ($resp | length) < $PAGE_SIZE {
{out: $resp}
} else {
{out: $resp, next: ($page + 1)}
}
}
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
- An `unfold` generator is added to the default context.
# 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.
-->
Given the complexity of the `generator` closure's return value, it would
be good to document the semantics of `unfold` and provide some in-depth
examples showcasing what it can accomplish.
# Description
Fixes: #7085
Also closes: #7526
# User-Facing Changes
After this change, we need to use `-c` flag like this:
```nushell
[[a, b, c]; [1, 2, 3]] | rename -c { a: ham }
```
But we can rename many columns easily, here is another example:
```nushell
[[a, b, c]; [1, 2, 3]] | rename -c { a: ham, b: ham2 }
```
# Description
Closes#10441
Uses `String::to_lowercase()` when the file's extension `ext` is parsed
to allow `from_decl(format!("from {ext}"))` to return the desired output
regardless of extension case.
It doesn't work with sqlite files since those are handled earlier in the
parsing but I think is good- since there's no standard file extension
used by sqlite so a user will likely want case sensitivity in that case.
This also has the (possibly undesired) effect of making `open`
completely case insensitive, e.g. `open foo.JSON` will work on a file
named `foo.json` and vice versa. This is good on Windows as it treats
`foo.json` and `foo.JSON` as the same file, but may not be the desired
behaviour on Unix.
If this behaviour is undesired I assume it would be fixed with a
`#[cfg(not(unix))]` attribute on the `to_lowercase()` operation but that
produces slightly "uglier" code that I didn't wish to submit unless
necessary.
old behaviour:
new behaviour:
# User-Facing Changes
`open` will now present a table when `open`-ing files with captitalized
extensions rather than the file's raw data
# Tests + Formatting
new test: `parses_file_with_uppercase_extension` which tests the desired
behaviour
---------
Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
Fixes#10503
Also improves link to metacharacter help;
# Description
`glob` code was using pattern as provided by user. If that had leading
`..\`, `wax::Glob` is documented to treat them as literal chars to be
matched.
Fix is to use `wax::Glob.partition()` to split such invariant prefixes
off the pattern and tack them onto the working directory computed
separately.
Before
```
> ls ..
╭───┬───────┬──────┬──────┬───────────────╮
│ # │ name │ type │ size │ modified │
├───┼───────┼──────┼──────┼───────────────┤
│ 0 │ ../r1 │ dir │ 7 B │ 3 hours ago │
│ 1 │ ../r2 │ dir │ 3 B │ a day ago │
│ 2 │ ../r3 │ dir │ 13 B │ 4 minutes ago │
╰───┴───────┴──────┴──────┴───────────────╯
> glob ../r*
╭────────────╮
│ empty list │
╰────────────╯
```
After
```
> glob ../r*
╭───┬──────────────────────────────╮
│ 0 │ /home/bobhy/src/rust/work/r2 │
│ 1 │ /home/bobhy/src/rust/work/r1 │
│ 2 │ /home/bobhy/src/rust/work/r3 │
╰───┴──────────────────────────────╯
```
# User-Facing Changes
None
# Tests + Formatting
- 🟢 `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.
-->
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
related to
- https://github.com/nushell/nushell/pull/9973
- https://github.com/nushell/nushell/pull/9918
thanks to @jntrnr and their super useful tips on this PR, i learned
about the parser + evaluation, so 🙏
# Description
because we already have `null` as the value of the type `nothing` and as
a followup to the two other attempts of mine, i propose to remove the
redundant `$nothing` built-in variable 😋
this PR is the first step, deprecating `$nothing`.
a followup PR will remove it altogether and wait for 0.87 👍⚙️ **details**: a new `NOTHING_VARIABLE_ID = 3` has been added,
parsing `$nothing` will create it, finally a `Value::Nothing` will be
produced and a warning will be reported.
this PR already fixes the `toolkit.nu` module so that it does not throw
a bunch of warnings each time 👌
# User-Facing Changes
`$nothing` is now deprecated and will be removed in 0.87
```nushell
> $nothing
Error: × Deprecated variable
╭─[entry #1:1:1]
1 │ $nothing
· ────┬───
· ╰── `$nothing` is deprecated and will be removed in 0.87.
╰────
help: Use `null` instead
```
# Tests + Formatting
tests have been updated, especially
- `nothing_fails_string`
- `nothing_fails_int`
which use a variable called `nil` now to make sure `nothing` does not
support cell paths 👍
# After Submitting
classic deprecation mention 👍
should close https://github.com/nushell/nushell/issues/10406
# Description
when writing a script, with variables you try to `ls` or `open`, you
will get a "directory not found" error but the variable won't be
expanded and you won't be able to see which one of the variable was the
issue...
this PR adds this information to the error.
# User-Facing Changes
let's define a variable
```nushell
let does_not_exist = "i_do_not_exist_in_the_current_directory"
```
### before
```nushell
> open $does_not_exist
Error: nu:🐚:directory_not_found
× Directory not found
╭─[entry #7:1:1]
1 │ open $does_not_exist
· ───────┬───────
· ╰── directory not found
╰────
```
```nushell
> ls $does_not_exist
Error: nu:🐚:directory_not_found
× Directory not found
╭─[entry #8:1:1]
1 │ ls $does_not_exist
· ───────┬───────
· ╰── directory not found
╰────
```
### after
```nushell
> open $does_not_exist
Error: nu:🐚:directory_not_found
× Directory not found
╭─[entry #3:1:1]
1 │ open $does_not_exist
· ───────┬───────
· ╰── directory not found
╰────
help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist
```
```nushell
> ls $does_not_exist
Error: nu:🐚:directory_not_found
× Directory not found
╭─[entry #4:1:1]
1 │ ls $does_not_exist
· ───────┬───────
· ╰── directory not found
╰────
help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist
```
# Tests + Formatting
shouldn't harm anything 🤞
# After Submitting
<!--
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.
-->
Closes#5436
When I opened this issue more than a year ago, I mainly wanted the
following capacity: easily access the full env and have the hability to
update it when a new version of `nushell` comes out.
With this PR I can now do the following:
```nu
source-env ~/.config/nushell/defaults/env.nu
source ~/.config/nushell/defaults/config.nu
# Update nushell default config & env file (run this after a version update)
def update-defaults [] {
config env --default | save -f ~/.config/nushell/defaults/env.nu
config nu --default | save -f ~/.config/nushell/defaults/config.nu
}
```
Which is more than enough for me. Along with `nushell` respecting the
XDG spec on macOS (`dirs-next` should be banned for CLI tools on macOS),
this should be one of the last hurdle before fully switching for me!
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Two new switches to existing commands:
```nu
config env --default # Print the default env embedded at compile time in the binary
config nu --default # Print the default config embedded at compile time in the binary
```
# 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
> ```
-->
- Added a test for the output of `config env --default`
- Added a test for the output of `config nu --default`
# 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.
-->
Are the docs for commands generated automatically or do I need to make a
PR there too ? It's no problem if so, just point me at instructions if
there are any :)
# Description
Fixes: #10450
This pr differentiating between `--x: bool` and `--x`
Here are examples which demostrate difference between them:
```nushell
def a [--x: bool] { $x };
a --x # not allowed, you need to parse a value to the flag.
a # it's allowed, and the value of `$x` is false, which behaves the same to `def a [--x] { $x }; a`
```
For boolean flag with default value, it works a little bit different to
#10450 mentioned:
```nushell
def foo [--option: bool = false] { $option }
foo # output false
foo --option # not allowed, you need to parse a value to the flag.
foo --option true # output true
```
# User-Facing Changes
After the pr, the following code is not allowed:
```nushell
def a [--x: bool] { $x }; a --x
```
Instead, you have to pass a value to flag `--x` like `a --x false`. But
bare flag works in the same way as before.
## Update: one more breaking change to help on #7260
```
def foo [--option: bool] { $option == null }
foo
```
After the pr, if we don't use a boolean flag, the value will be `null`
instead of `true`. Because here `--option: bool` is treated as a flag
rather than a switch
---------
Co-authored-by: amtoine <stevan.antoine@gmail.com>
# Description
This PR should close#10085
Maps `DirectoryNotFound` errors to `FileNotFound`. All other errors are
left unchanged.
# User-Facing Changes
This means a user will see `FileNotFound` instead of `DirectoryNotFound`
which is more meaning full to the user.
# Description
This PR allows the `values` command to support lazy records.
closes https://github.com/nushell/nushell/issues/10417
### Before
```nushell
sys | values
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #1:1:1]
1 │ sys | values
· ─┬─ ───┬──
· │ ╰── only record or table input data is supported
· ╰── input type: record<host: record<name: string, os_version: string, long_os_version: string, kernel_version: string, hostname: string, uptime: duration, boot_time: string, sessions: list<any>>, cpu: table<name: string, brand: string, freq: int, cpu_usage: float, load_average: string, vendor_id: string>, disks: table<device: string, type: string, mount: string, total: filesize, free: filesize, removable: bool, kind: string>, mem: record<total: filesize, free: filesize, used: filesize, available: filesize, swap total: filesize, swap free: filesize, swap used: filesize>, temp: list<any>, net: table<name: string, sent: filesize, recv: filesize>>
╰────
```
### After
```nushell
❯ sys | values
╭─┬─────────────────╮
│0│{record 8 fields}│
│1│[table 16 rows] │
│2│[table 1 row] │
│3│{record 7 fields}│
│4│[list 0 items] │
│5│[table 5 rows] │
╰─┴─────────────────╯
```
# 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.
-->
# Description
Fixes: #10410
So the following script is possible:
```nushell
def a [b: any = null] { let b = ($b | default "default_b"); }
a "given_b"
```
## About the change
When parsing signature, and nushell meets something like `a: any`, it
force the parser to treat `a` as `any` type. This is what
`arg_explicit_type` means, it's only set when we goes into
`ParseMode::TypeMode`, and it will be reset to `false` if the token goes
to next argument.
so, when we have something like this: `def a [b: any = null] { $b }`,
the type of `$b` won't be overwritten.
But if we have something like this: `def a [b = null] { $b }`, the type
of `$b` is not annotated, so we make it to be `nothing`(which is the
type of null)
