# Description
Running `cargo install nu` on rustc 1.71.1 (eb26296b5 2023-08-03)
produced the following error message when reaching `nu-command v0.88.0`:
```sh
error[E0659]: `open` is ambiguous
--> /home/antoine/.cargo/registry/src/index.crates.io-6f17d22bba15001f/nu-command-0.88.0/src/stor/mod.rs:30:9
|
30 | pub use open::StorOpen;
| ^^^^ ambiguous name
|
= note: ambiguous because of multiple potential import sources
= note: `open` could refer to a crate passed with `--extern`
= help: use `::open` to refer to this crate unambiguously
note: `open` could also refer to the module defined here
--> /home/antoine/.cargo/registry/src/index.crates.io-6f17d22bba15001f/nu-command-0.88.0/src/stor/mod.rs:12:1
|
12 | mod open;
| ^^^^^^^^^
= help: use `self::open` to refer to this module unambiguously
Compiling nu-cli v0.88.0
Compiling nu-lsp v0.88.0
For more information about this error, try `rustc --explain E0659`.
error: could not compile `nu-command` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `nu v0.88.0`, intermediate artifacts can be found at `/tmp/cargo-installEUsfIr`
```
# User-Facing Changes
No user-facing changes.
<!--
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:
- `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.
-->
Reverts nushell/nushell#10943
The current implementation of `arr_to_value` is unsound, as it allows
casts of arbitrary data to arbitrary types without being marked
`unsafe`.
The full safety requirements to perform both the cast and the following
unchecked access are not as clear that a simple change of `fn
arr_to_value` to `unsafe fn arr_to_value` could be blessed without
further investigation.
cc @ayax79
# Description
This PR enables a new feature that shows which externals are found in
your path via the syntax highlighter as you type.
This idea could use some improvement where it caches the items in your
path and on some trigger, expires that cache and creates a new on. Right
now, all it does is call the `which` crate on every character you type.
This could be problematic if you have hundreds of paths in your PATH or
if some of your paths in your Path point to extraordinarily slow file
systems. WSL pointing to Windows comes to mind. Either way, I've thrown
it up here for people to try and provide feedback. I think the novelty
of showing what is valid and what isn't is pretty cool. I believe
fish-shell also does this, IIRC.
# 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.
-->
Fix the breaking changes.
Get's rid of some outdated transitive dependencies.
Sadly we need to expose more of `procfs` to `nu-command` based on how
the features of `nu-system` are exposed right now.
Conditional compilation/dependencies from hell included
Supersedes #11101
closes#10845
I've opened this a little prematurely to get some questions answered
before I cleanup the code.
As I started trying to better understand GNUs `mktemp` I've realized its
kind of peculiar and we might want to change its behavior to introduce
it to nushell.
#### quiet and dry run
Does it make sense to keep the `quiet` and `dry_run` flags? I don't
think so. The GNU documentation says this about the dry run flag "Using
the output of this command to create a new file is inherently unsafe, as
there is a window of time between generating the name and using it where
another process can create an object by the same name." So yeah why keep
it? As far as quiet goes, does it make sense to silence the errors in
nushell?
#### other confusing flags
According to the [gnu
docs](https://www.gnu.org/software/coreutils/manual/html_node/mktemp-invocation.html),
the `-t` flag is deprecated and the `-p`/ `--tempdir` are the same flag
with the only difference being `--tempdir` takes an optional path, Given
that, I've broken the `-p` away from `--tempdir`. Now there is one
switch `--tmpdir`/`-t` and one named param `--tmpdir-path`/`-p`.
GNU mktemp
```
-p DIR, --tmpdir[=DIR] interpret TEMPLATE relative to DIR; if DIR is not
specified, use $TMPDIR if set, else /tmp. With
this option, TEMPLATE must not be an absolute name;
unlike with -t, TEMPLATE may contain slashes, but
mktemp creates only the final component
-t interpret TEMPLATE as a single file name component,
relative to a directory: $TMPDIR, if set; else the
directory specified via -p; else /tmp [deprecated]
```
to
nushell mktemp
```
-p, --tmpdir-path <Filepath> # named param, must provide a path
-t, --tmpdir # a switch
```
Is this a terrible idea?
What should I do?
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
# Description
This PR adds the ability to parse human readable datetime strings as
part of the `into datetime` command. I added a new `-n`/`--list-human`
parameter that produces this list to give the user an idea of what is
supported.
```nushell
❯ into datetime --list-human
╭#─┬parseable human datetime examples┬───result───╮
│0 │Today 18:30 │in 8 hours │
│1 │2022-11-07 13:25:30 │a year ago │
│2 │15:20 Friday │in 3 days │
│3 │This Friday 17:00 │in 3 days │
│4 │13:25, Next Tuesday │in a week │
│5 │Last Friday at 19:45 │3 days ago │
│6 │In 3 days │in 2 days │
│7 │In 2 hours │in 2 hours │
│8 │10 hours and 5 minutes ago │10 hours ago│
│9 │1 years ago │a year ago │
│10│A year ago │a year ago │
│11│A month ago │a month ago │
│12│A week ago │a week ago │
│13│A day ago │a day ago │
│14│An hour ago │an hour ago │
│15│A minute ago │a minute ago│
│16│A second ago │now │
│17│Now │now │
╰#─┴parseable human datetime examples┴───result───╯
```
Or with `$env.config.datetime_format.table` set.
```nushell
❯ into datetime --list-human
╭#─┬parseable human datetime examples┬──────result───────╮
│0 │Today 18:30 │11/14/23 06:30:00PM│
│1 │2022-11-07 13:25:30 │11/07/22 01:25:30PM│
│2 │15:20 Friday │11/17/23 03:20:00PM│
│3 │This Friday 17:00 │11/17/23 05:00:00PM│
│4 │13:25, Next Tuesday │11/21/23 01:25:00PM│
│5 │Last Friday at 19:45 │11/10/23 07:45:00PM│
│6 │In 3 days │11/17/23 10:12:54AM│
│7 │In 2 hours │11/14/23 12:12:54PM│
│8 │10 hours and 5 minutes ago │11/14/23 12:07:54AM│
│9 │1 years ago │11/13/22 10:12:54AM│
│10│A year ago │11/13/22 10:12:54AM│
│11│A month ago │10/15/23 11:12:54AM│
│12│A week ago │11/07/23 10:12:54AM│
│13│A day ago │11/13/23 10:12:54AM│
│14│An hour ago │11/14/23 09:12:54AM│
│15│A minute ago │11/14/23 10:11:54AM│
│16│A second ago │11/14/23 10:12:53AM│
│17│Now │11/14/23 10:12:54AM│
╰#─┴parseable human datetime examples┴──────result───────╯
```
# 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.
-->
Go from the ill-defined `enable/disable` pairs to `.use_...` builders
This alleviates unclear properties when the underlying enhancements are
enabled. Now they are enabed when entering `Reedline::read_line` and
disabled when exiting that.
Furthermore allow setting `$env.config.use_kitty_protocol` to have an
effect when toggling during runtime. Previously it was only enabled when
receiving a value from `config.nu`. I kept the warning code there to not
pollute the log. We could move it into the REPL-loop if desired
Not sure if we should actively block the enabling of `bracketed_paste`
on Windows. Need to test what happens if it just doesn't do anything we
could remove the `cfg!` switch. At least for WSL2 Windows Terminal
already supports bracketed paste. `target_os = windows` is a bad
predictor for `conhost.exe`.
Depends on https://github.com/nushell/reedline/pull/659
(pointing to personal fork)
Closes https://github.com/nushell/nushell/issues/10982
Supersedes https://github.com/nushell/nushell/pull/10998
We have three different `rustix` minor versions. For two of them with
their previous patch versions a security advisory has been released:
https://github.com/advisories/GHSA-c827-hfw6-qwvm
Bump the patch versions, to resolve the potential vulnerability.
At the moment we haven't assessed the potential impact on nushell,
whether we are exposed to the underlying issue.
The `color-backtrace` crate does not seem to either handle the terminal
modes well or operate in a way that the unwinding has not yet succeeded
to reach the backup disablement of the terminal raw mode in
`reedline::Reedline`'s `Drop` implementation.
This reverts commit d838871063.
Fixes#11029
Provides support for reading Polars structs. This allows opening of
supported files (jsonl, parquet, etc) that contain rows with structured
data.
The following attached json lines
file([receipts.jsonl.gz](https://github.com/nushell/nushell/files/13311476/receipts.jsonl.gz))
contains a customer column with structured data. This json lines file
can now be loaded via `dfr open` and will render as follows:
<img width="525" alt="Screenshot 2023-11-09 at 10 09 18"
src="https://github.com/nushell/nushell/assets/56345/4b26ccdc-c230-43ae-a8d5-8af88a1b72de">
This also addresses some cleanup of date handling and utilizing
timezones where provided.
This pull request only addresses reading data from polars structs. I
will address converting nushell data to polars structs in a future
request as this change is large enough as it is.
---------
Co-authored-by: Jack Wright <jack.wright@disqo.com>
# Description
Add an extension trait `IgnoreCaseExt` to nu_utils which adds some case
insensitivity helpers, and use them throughout nu to improve the
handling of case insensitivity. Proper case folding is done via unicase,
which is already a dependency via mime_guess from nu-command.
In actuality a lot of code still does `to_lowercase`, because unicase
only provides immediate comparison and doesn't expose a `to_folded_case`
yet. And since we do a lot of `contains`/`starts_with`/`ends_with`, it's
not sufficient to just have `eq_ignore_case`. But if we get access in
the future, this makes us ready to use it with a change in one place.
Plus, it's clearer what the purpose is at the call site to call
`to_folded_case` instead of `to_lowercase` if it's exclusively for the
purpose of case insensitive comparison, even if it just does
`to_lowercase` still.
# User-Facing Changes
- Some commands that were supposed to be case insensitive remained only
insensitive to ASCII case (a-z), and now are case insensitive w.r.t.
non-ASCII characters as well.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
---------
Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
# Description
Just throwing up this PR because color-backtrace seemed to produce more
useful backtraces. Just curious what others think.
Did this:
1. RUST_BACKTRACE=full cargo r
2. ❯ def test01 [] {
let sorted = [storm]
$sorted | range 1.. | zip ($sorted | range ..(-2))
}
3. test01
I like how it shows the code snippet.
# 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
This PR updates the trash dependency from 3.1.0 to 3.1.2 for better
support on FreeBSD.
closes#10961
# 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.
-->
<!--
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.
-->
Implements `whoami` using the `whoami` command from uutils as backend.
This is a draft because it depends on
https://github.com/uutils/coreutils/pull/5310 and a new release of
uutils needs to be made (and the paths in `Cargo.toml` should be
updated). At this point, this is more of a proof of concept 😄
Additionally, this implements a (simple and naive) conversion from the
uutils `UResult` to the nushell `ShellError`, which should help with the
integration of other utils, too. I can split that off into a separate PR
if desired.
I put this command in the "platform" category. If it should go somewhere
else, let me know!
The tests will currently fail, because I've used a local path to uutils.
Once the PR on the uutils side is merged, I'll update it to a git path
so that it can be tested and runs on more machines than just mine.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
New `whoami` command. This might break some users who expect the system
`whoami` command. However, the result of this new command should be very
close, just with a nicer help message, at least for Linux users. The
default `whoami` on Windows is quite different from this implementation:
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/whoami
# 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>
Reverts nushell/nushell#10812
This goes back to a version of `regex` and its dependencies that is
shared with a lot of our other dependencies. Before this we did not
duplicate big dependencies of `regex` that affect binary size and
compile time.
As there is no known bug or security problem we suffer from, we can wait
on receiving the performance improvements to `regex` with the rest of
our `regex` dependents.
This commit uses the new `CwdAwareHinter` in reedline. Closes#8883.
# Description
Currently, the history based hints show results from all directories,
while most commands make sense only in the directory they were run in.
This PR makes hints take the current directory into account.
# User-Facing Changes
Described above.
I haven't yet added a config option for this, because I personally
believe folks won't be against it once they try it out. We can add it if
people complain, there's some time before the next release.
Fish has this without a config option too.
# Tests + Formatting
If tests are needed, I'll need help as I'm not well versed with the
codebase.
(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>
Re-fixes #3674, if that is seen as desirable to do.
# Description
This PR changes the implementation of the `--features=extra` string
casing commands from Inflector to `heck`, as in PR #4081. This PR landed
a long time ago, but somewhere along the way (i can't find it) the
implementation ended up being switched back to Inflector.
# User-Facing Changes
Inflector and `heck` implement casing differently, so all of the
commands have different behavior around edge cases (consecutive
capitals, interspersed numbers and letters, etc)
### Before
```nu
G:/Dev/nu-itself/nushell> [UserID ABCdefGHI foo123bar] | str camel-case
╭───┬───────────╮
│ 0 │ userID │
│ 1 │ abcdefGHI │
│ 2 │ foo123Bar │
╰───┴───────────╯
G:/Dev/nu-itself/nushell> [UserID ABCdefGHI foo123bar] | str snake-case
╭───┬─────────────╮
│ 0 │ user_id │
│ 1 │ ab_cdef_ghi │
│ 2 │ foo_12_3bar │
╰───┴─────────────╯
```
### After
```nu
G:/Dev/nu-itself/nushell> [UserID ABCdefGHI foo123bar] | str camel-case
╭───┬───────────╮
│ 0 │ userId │
│ 1 │ abCdefGhi │
│ 2 │ foo123bar │
╰───┴───────────╯
G:/Dev/nu-itself/nushell> [UserID ABCdefGHI foo123bar] | str snake-case
╭───┬─────────────╮
│ 0 │ user_id │
│ 1 │ ab_cdef_ghi │
│ 2 │ foo123bar │
╰───┴─────────────╯
```
# Tests + Formatting
The existing string casing tests pass... because none of them relied on
any of these edge cases
# Description
Open question:
Undocumented behavior for the new argument `ambiguous` to the
`as_datetime`
methods. I cheated by passing a default (assuming empty string).
This appears like an API primarily serving the python impl:
https://pola-rs.github.io/polars/py-polars/html/reference/expressions/api/polars.Expr.str.to_datetime.html#polars-expr-str-to-datetime
# User-Facing Changes
Only dependent on breaking changes to the behavior of polars.
# Tests + Formatting
No observed changes to tests
Manually checked `dfr as-datetime`, doesn't seem to panic.
