2022-11-19 19:14:29 +01:00
|
|
|
use nu_test_support::{nu, pipeline};
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn url_parse_simple() {
|
2023-07-17 18:43:51 +02:00
|
|
|
let actual = nu!(pipeline(
|
|
|
|
r#"
|
2022-11-19 19:14:29 +01:00
|
|
|
("https://www.abc.com"
|
|
|
|
| url parse)
|
|
|
|
== {
|
|
|
|
scheme: 'https',
|
|
|
|
username: '',
|
|
|
|
password: '',
|
|
|
|
host: 'www.abc.com',
|
|
|
|
port: '',
|
|
|
|
path: '/',
|
|
|
|
query: '',
|
|
|
|
fragment: '',
|
Url split query (#14211)
Addresses the following points from #14162
> - There is no built-in counterpart to url build-query for splitting a
query string
There is `from url`, which, due to naming, is a little hard to discover
and suffers from the following point
> - url parse can create records with duplicate keys
> - url parse's params should either:
> - ~group the same keys into a list.~
> - instead of a record, be a key-value table. (table<key: string,
value: string>)
# Description
## `url split-query`
Counterpart to `url build-query`, splits a url encoded query string to
key value pairs, represented as `table<key: string, value: string>`
```
> "a=one&a=two&b=three" | url split-query
╭───┬─────┬───────╮
│ # │ key │ value │
├───┼─────┼───────┤
│ 0 │ a │ one │
│ 1 │ a │ two │
│ 2 │ b │ three │
╰───┴─────┴───────╯
```
## `url parse`
The output's `param` field is now a table as well, mirroring the new
`url split-query`
```
> 'http://localhost?a=one&a=two&b=three' | url parse
╭──────────┬─────────────────────╮
│ scheme │ http │
│ username │ │
│ password │ │
│ host │ localhost │
│ port │ │
│ path │ / │
│ query │ a=one&a=two&b=three │
│ fragment │ │
│ │ ╭───┬─────┬───────╮ │
│ params │ │ # │ key │ value │ │
│ │ ├───┼─────┼───────┤ │
│ │ │ 0 │ a │ one │ │
│ │ │ 1 │ a │ two │ │
│ │ │ 2 │ b │ three │ │
│ │ ╰───┴─────┴───────╯ │
╰──────────┴─────────────────────╯
```
# User-Facing Changes
- `url parse`'s output has the mentioned change, which is backwards
incompatible.
2024-11-06 14:35:37 +01:00
|
|
|
params: []
|
2022-11-19 19:14:29 +01:00
|
|
|
}
|
|
|
|
"#
|
|
|
|
));
|
|
|
|
assert_eq!(actual.out, "true");
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn url_parse_with_port() {
|
2023-07-17 18:43:51 +02:00
|
|
|
let actual = nu!(pipeline(
|
|
|
|
r#"
|
2022-11-19 19:14:29 +01:00
|
|
|
("https://www.abc.com:8011"
|
|
|
|
| url parse)
|
|
|
|
== {
|
|
|
|
scheme: 'https',
|
|
|
|
username: '',
|
|
|
|
password: '',
|
|
|
|
host: 'www.abc.com',
|
|
|
|
port: '8011',
|
|
|
|
path: '/',
|
|
|
|
query: '',
|
|
|
|
fragment: '',
|
Url split query (#14211)
Addresses the following points from #14162
> - There is no built-in counterpart to url build-query for splitting a
query string
There is `from url`, which, due to naming, is a little hard to discover
and suffers from the following point
> - url parse can create records with duplicate keys
> - url parse's params should either:
> - ~group the same keys into a list.~
> - instead of a record, be a key-value table. (table<key: string,
value: string>)
# Description
## `url split-query`
Counterpart to `url build-query`, splits a url encoded query string to
key value pairs, represented as `table<key: string, value: string>`
```
> "a=one&a=two&b=three" | url split-query
╭───┬─────┬───────╮
│ # │ key │ value │
├───┼─────┼───────┤
│ 0 │ a │ one │
│ 1 │ a │ two │
│ 2 │ b │ three │
╰───┴─────┴───────╯
```
## `url parse`
The output's `param` field is now a table as well, mirroring the new
`url split-query`
```
> 'http://localhost?a=one&a=two&b=three' | url parse
╭──────────┬─────────────────────╮
│ scheme │ http │
│ username │ │
│ password │ │
│ host │ localhost │
│ port │ │
│ path │ / │
│ query │ a=one&a=two&b=three │
│ fragment │ │
│ │ ╭───┬─────┬───────╮ │
│ params │ │ # │ key │ value │ │
│ │ ├───┼─────┼───────┤ │
│ │ │ 0 │ a │ one │ │
│ │ │ 1 │ a │ two │ │
│ │ │ 2 │ b │ three │ │
│ │ ╰───┴─────┴───────╯ │
╰──────────┴─────────────────────╯
```
# User-Facing Changes
- `url parse`'s output has the mentioned change, which is backwards
incompatible.
2024-11-06 14:35:37 +01:00
|
|
|
params: []
|
2022-11-19 19:14:29 +01:00
|
|
|
}
|
|
|
|
"#
|
|
|
|
));
|
|
|
|
|
|
|
|
assert_eq!(actual.out, "true");
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn url_parse_with_path() {
|
2023-07-17 18:43:51 +02:00
|
|
|
let actual = nu!(pipeline(
|
|
|
|
r#"
|
2022-11-19 19:14:29 +01:00
|
|
|
("http://www.abc.com:8811/def/ghj"
|
|
|
|
| url parse)
|
|
|
|
== {
|
|
|
|
scheme: 'http',
|
|
|
|
username: '',
|
|
|
|
password: '',
|
|
|
|
host: 'www.abc.com',
|
|
|
|
port: '8811',
|
|
|
|
path: '/def/ghj',
|
|
|
|
query: '',
|
|
|
|
fragment: '',
|
Url split query (#14211)
Addresses the following points from #14162
> - There is no built-in counterpart to url build-query for splitting a
query string
There is `from url`, which, due to naming, is a little hard to discover
and suffers from the following point
> - url parse can create records with duplicate keys
> - url parse's params should either:
> - ~group the same keys into a list.~
> - instead of a record, be a key-value table. (table<key: string,
value: string>)
# Description
## `url split-query`
Counterpart to `url build-query`, splits a url encoded query string to
key value pairs, represented as `table<key: string, value: string>`
```
> "a=one&a=two&b=three" | url split-query
╭───┬─────┬───────╮
│ # │ key │ value │
├───┼─────┼───────┤
│ 0 │ a │ one │
│ 1 │ a │ two │
│ 2 │ b │ three │
╰───┴─────┴───────╯
```
## `url parse`
The output's `param` field is now a table as well, mirroring the new
`url split-query`
```
> 'http://localhost?a=one&a=two&b=three' | url parse
╭──────────┬─────────────────────╮
│ scheme │ http │
│ username │ │
│ password │ │
│ host │ localhost │
│ port │ │
│ path │ / │
│ query │ a=one&a=two&b=three │
│ fragment │ │
│ │ ╭───┬─────┬───────╮ │
│ params │ │ # │ key │ value │ │
│ │ ├───┼─────┼───────┤ │
│ │ │ 0 │ a │ one │ │
│ │ │ 1 │ a │ two │ │
│ │ │ 2 │ b │ three │ │
│ │ ╰───┴─────┴───────╯ │
╰──────────┴─────────────────────╯
```
# User-Facing Changes
- `url parse`'s output has the mentioned change, which is backwards
incompatible.
2024-11-06 14:35:37 +01:00
|
|
|
params: []
|
2022-11-19 19:14:29 +01:00
|
|
|
}
|
|
|
|
"#
|
|
|
|
));
|
|
|
|
|
|
|
|
assert_eq!(actual.out, "true");
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn url_parse_with_params() {
|
2023-07-17 18:43:51 +02:00
|
|
|
let actual = nu!(pipeline(
|
|
|
|
r#"
|
2022-11-19 19:14:29 +01:00
|
|
|
("http://www.abc.com:8811/def/ghj?param1=11¶m2="
|
|
|
|
| url parse)
|
|
|
|
== {
|
|
|
|
scheme: 'http',
|
|
|
|
username: '',
|
|
|
|
password: '',
|
|
|
|
host: 'www.abc.com',
|
|
|
|
port: '8811',
|
|
|
|
path: '/def/ghj',
|
|
|
|
query: 'param1=11¶m2=',
|
|
|
|
fragment: '',
|
Url split query (#14211)
Addresses the following points from #14162
> - There is no built-in counterpart to url build-query for splitting a
query string
There is `from url`, which, due to naming, is a little hard to discover
and suffers from the following point
> - url parse can create records with duplicate keys
> - url parse's params should either:
> - ~group the same keys into a list.~
> - instead of a record, be a key-value table. (table<key: string,
value: string>)
# Description
## `url split-query`
Counterpart to `url build-query`, splits a url encoded query string to
key value pairs, represented as `table<key: string, value: string>`
```
> "a=one&a=two&b=three" | url split-query
╭───┬─────┬───────╮
│ # │ key │ value │
├───┼─────┼───────┤
│ 0 │ a │ one │
│ 1 │ a │ two │
│ 2 │ b │ three │
╰───┴─────┴───────╯
```
## `url parse`
The output's `param` field is now a table as well, mirroring the new
`url split-query`
```
> 'http://localhost?a=one&a=two&b=three' | url parse
╭──────────┬─────────────────────╮
│ scheme │ http │
│ username │ │
│ password │ │
│ host │ localhost │
│ port │ │
│ path │ / │
│ query │ a=one&a=two&b=three │
│ fragment │ │
│ │ ╭───┬─────┬───────╮ │
│ params │ │ # │ key │ value │ │
│ │ ├───┼─────┼───────┤ │
│ │ │ 0 │ a │ one │ │
│ │ │ 1 │ a │ two │ │
│ │ │ 2 │ b │ three │ │
│ │ ╰───┴─────┴───────╯ │
╰──────────┴─────────────────────╯
```
# User-Facing Changes
- `url parse`'s output has the mentioned change, which is backwards
incompatible.
2024-11-06 14:35:37 +01:00
|
|
|
params: [[key, value]; ["param1", "11"], ["param2", ""]]
|
|
|
|
}
|
|
|
|
"#
|
|
|
|
));
|
|
|
|
|
|
|
|
assert_eq!(actual.out, "true");
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn url_parse_with_duplicate_params() {
|
|
|
|
let actual = nu!(pipeline(
|
|
|
|
r#"
|
|
|
|
("http://www.abc.com:8811/def/ghj?param1=11¶m2=¶m1=22"
|
|
|
|
| url parse)
|
|
|
|
== {
|
|
|
|
scheme: 'http',
|
|
|
|
username: '',
|
|
|
|
password: '',
|
|
|
|
host: 'www.abc.com',
|
|
|
|
port: '8811',
|
|
|
|
path: '/def/ghj',
|
|
|
|
query: 'param1=11¶m2=¶m1=22',
|
|
|
|
fragment: '',
|
|
|
|
params: [[key, value]; ["param1", "11"], ["param2", ""], ["param1", "22"]]
|
2022-11-19 19:14:29 +01:00
|
|
|
}
|
|
|
|
"#
|
|
|
|
));
|
|
|
|
|
|
|
|
assert_eq!(actual.out, "true");
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn url_parse_with_fragment() {
|
2023-07-17 18:43:51 +02:00
|
|
|
let actual = nu!(pipeline(
|
|
|
|
r#"
|
2022-11-19 19:14:29 +01:00
|
|
|
("http://www.abc.com:8811/def/ghj?param1=11¶m2=#hello-fragment"
|
|
|
|
| url parse)
|
|
|
|
== {
|
|
|
|
scheme: 'http',
|
|
|
|
username: '',
|
|
|
|
password: '',
|
|
|
|
host: 'www.abc.com',
|
|
|
|
port: '8811',
|
|
|
|
path: '/def/ghj',
|
|
|
|
query: 'param1=11¶m2=',
|
|
|
|
fragment: 'hello-fragment',
|
Url split query (#14211)
Addresses the following points from #14162
> - There is no built-in counterpart to url build-query for splitting a
query string
There is `from url`, which, due to naming, is a little hard to discover
and suffers from the following point
> - url parse can create records with duplicate keys
> - url parse's params should either:
> - ~group the same keys into a list.~
> - instead of a record, be a key-value table. (table<key: string,
value: string>)
# Description
## `url split-query`
Counterpart to `url build-query`, splits a url encoded query string to
key value pairs, represented as `table<key: string, value: string>`
```
> "a=one&a=two&b=three" | url split-query
╭───┬─────┬───────╮
│ # │ key │ value │
├───┼─────┼───────┤
│ 0 │ a │ one │
│ 1 │ a │ two │
│ 2 │ b │ three │
╰───┴─────┴───────╯
```
## `url parse`
The output's `param` field is now a table as well, mirroring the new
`url split-query`
```
> 'http://localhost?a=one&a=two&b=three' | url parse
╭──────────┬─────────────────────╮
│ scheme │ http │
│ username │ │
│ password │ │
│ host │ localhost │
│ port │ │
│ path │ / │
│ query │ a=one&a=two&b=three │
│ fragment │ │
│ │ ╭───┬─────┬───────╮ │
│ params │ │ # │ key │ value │ │
│ │ ├───┼─────┼───────┤ │
│ │ │ 0 │ a │ one │ │
│ │ │ 1 │ a │ two │ │
│ │ │ 2 │ b │ three │ │
│ │ ╰───┴─────┴───────╯ │
╰──────────┴─────────────────────╯
```
# User-Facing Changes
- `url parse`'s output has the mentioned change, which is backwards
incompatible.
2024-11-06 14:35:37 +01:00
|
|
|
params: [[key, value]; ["param1", "11"], ["param2", ""]]
|
2022-11-19 19:14:29 +01:00
|
|
|
}
|
|
|
|
"#
|
|
|
|
));
|
|
|
|
|
|
|
|
assert_eq!(actual.out, "true");
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn url_parse_with_username_and_password() {
|
2023-07-17 18:43:51 +02:00
|
|
|
let actual = nu!(pipeline(
|
|
|
|
r#"
|
2022-11-19 19:14:29 +01:00
|
|
|
("http://user123:password567@www.abc.com:8811/def/ghj?param1=11¶m2=#hello-fragment"
|
|
|
|
| url parse)
|
|
|
|
== {
|
|
|
|
scheme: 'http',
|
|
|
|
username: 'user123',
|
|
|
|
password: 'password567',
|
|
|
|
host: 'www.abc.com',
|
|
|
|
port: '8811',
|
|
|
|
path: '/def/ghj',
|
|
|
|
query: 'param1=11¶m2=',
|
|
|
|
fragment: 'hello-fragment',
|
Url split query (#14211)
Addresses the following points from #14162
> - There is no built-in counterpart to url build-query for splitting a
query string
There is `from url`, which, due to naming, is a little hard to discover
and suffers from the following point
> - url parse can create records with duplicate keys
> - url parse's params should either:
> - ~group the same keys into a list.~
> - instead of a record, be a key-value table. (table<key: string,
value: string>)
# Description
## `url split-query`
Counterpart to `url build-query`, splits a url encoded query string to
key value pairs, represented as `table<key: string, value: string>`
```
> "a=one&a=two&b=three" | url split-query
╭───┬─────┬───────╮
│ # │ key │ value │
├───┼─────┼───────┤
│ 0 │ a │ one │
│ 1 │ a │ two │
│ 2 │ b │ three │
╰───┴─────┴───────╯
```
## `url parse`
The output's `param` field is now a table as well, mirroring the new
`url split-query`
```
> 'http://localhost?a=one&a=two&b=three' | url parse
╭──────────┬─────────────────────╮
│ scheme │ http │
│ username │ │
│ password │ │
│ host │ localhost │
│ port │ │
│ path │ / │
│ query │ a=one&a=two&b=three │
│ fragment │ │
│ │ ╭───┬─────┬───────╮ │
│ params │ │ # │ key │ value │ │
│ │ ├───┼─────┼───────┤ │
│ │ │ 0 │ a │ one │ │
│ │ │ 1 │ a │ two │ │
│ │ │ 2 │ b │ three │ │
│ │ ╰───┴─────┴───────╯ │
╰──────────┴─────────────────────╯
```
# User-Facing Changes
- `url parse`'s output has the mentioned change, which is backwards
incompatible.
2024-11-06 14:35:37 +01:00
|
|
|
params: [[key, value]; ["param1", "11"], ["param2", ""]]
|
2022-11-19 19:14:29 +01:00
|
|
|
}
|
|
|
|
"#
|
|
|
|
));
|
|
|
|
|
|
|
|
assert_eq!(actual.out, "true");
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn url_parse_error_empty_url() {
|
2023-07-17 18:43:51 +02:00
|
|
|
let actual = nu!(r#""" | url parse"#);
|
2022-11-19 19:14:29 +01:00
|
|
|
|
|
|
|
assert!(actual.err.contains(
|
Standardise the use of ShellError::UnsupportedInput and ShellError::TypeMismatch and add spans to every instance of the former (#7217)
# Description
* I was dismayed to discover recently that UnsupportedInput and
TypeMismatch are used *extremely* inconsistently across the codebase.
UnsupportedInput is sometimes used for input type-checks (as per the
name!!), but *also* used for argument type-checks. TypeMismatch is also
used for both.
I thus devised the following standard: input type-checking *only* uses
UnsupportedInput, and argument type-checking *only* uses TypeMismatch.
Moreover, to differentiate them, UnsupportedInput now has *two* error
arrows (spans), one pointing at the command and the other at the input
origin, while TypeMismatch only has the one (because the command should
always be nearby)
* In order to apply that standard, a very large number of
UnsupportedInput uses were changed so that the input's span could be
retrieved and delivered to it.
* Additionally, I noticed many places where **errors are not propagated
correctly**: there are lots of `match` sites which take a Value::Error,
then throw it away and replace it with a new Value::Error with
less/misleading information (such as reporting the error as an
"incorrect type"). I believe that the earliest errors are the most
important, and should always be propagated where possible.
* Also, to standardise one broad subset of UnsupportedInput error
messages, who all used slightly different wordings of "expected
`<type>`, got `<type>`", I created OnlySupportsThisInputType as a
variant of it.
* Finally, a bunch of error sites that had "repeated spans" - i.e. where
an error expected two spans, but `call.head` was given for both - were
fixed to use different spans.
# Example
BEFORE
```
〉20b | str starts-with 'a'
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #31:1:1]
1 │ 20b | str starts-with 'a'
· ┬
· ╰── Input's type is filesize. This command only works with strings.
╰────
〉'a' | math cos
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #33:1:1]
1 │ 'a' | math cos
· ─┬─
· ╰── Only numerical values are supported, input type: String
╰────
〉0x[12] | encode utf8
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #38:1:1]
1 │ 0x[12] | encode utf8
· ───┬──
· ╰── non-string input
╰────
```
AFTER
```
〉20b | str starts-with 'a'
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #1:1:1]
1 │ 20b | str starts-with 'a'
· ┬ ───────┬───────
· │ ╰── only string input data is supported
· ╰── input type: filesize
╰────
〉'a' | math cos
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #2:1:1]
1 │ 'a' | math cos
· ─┬─ ────┬───
· │ ╰── only numeric input data is supported
· ╰── input type: string
╰────
〉0x[12] | encode utf8
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #3:1:1]
1 │ 0x[12] | encode utf8
· ───┬── ───┬──
· │ ╰── only string input data is supported
· ╰── input type: binary
╰────
```
# User-Facing Changes
Various error messages suddenly make more sense (i.e. have two arrows
instead of one).
# 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
# 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.
2022-12-23 07:48:53 +01:00
|
|
|
"Incomplete or incorrect URL. Expected a full URL, e.g., https://www.example.com"
|
2022-11-19 19:14:29 +01:00
|
|
|
));
|
|
|
|
}
|