2023-04-08 12:35:16 +00:00
|
|
|
use std
|
2023-03-16 18:23:29 +00:00
|
|
|
|
2023-07-02 08:41:33 +00:00
|
|
|
#[test]
|
|
|
|
def path_add [] {
|
2023-05-27 12:45:04 +00:00
|
|
|
use std assert
|
2023-03-16 18:23:29 +00:00
|
|
|
|
2023-05-17 23:55:46 +00:00
|
|
|
let path_name = if "PATH" in $env { "PATH" } else { "Path" }
|
|
|
|
|
2024-04-16 11:08:58 +00:00
|
|
|
with-env {$path_name: []} {
|
2023-05-17 23:55:46 +00:00
|
|
|
def get_path [] { $env | get $path_name }
|
2023-06-10 18:16:17 +00:00
|
|
|
|
2023-05-17 23:55:46 +00:00
|
|
|
assert equal (get_path) []
|
2023-03-16 18:23:29 +00:00
|
|
|
|
|
|
|
std path add "/foo/"
|
2023-10-25 14:43:27 +00:00
|
|
|
assert equal (get_path) (["/foo/"] | path expand)
|
2023-03-16 18:23:29 +00:00
|
|
|
|
|
|
|
std path add "/bar/" "/baz/"
|
2023-10-25 14:43:27 +00:00
|
|
|
assert equal (get_path) (["/bar/", "/baz/", "/foo/"] | path expand)
|
2023-03-16 18:23:29 +00:00
|
|
|
|
2023-06-30 19:57:51 +00:00
|
|
|
load-env {$path_name: []}
|
2023-03-16 18:23:29 +00:00
|
|
|
|
|
|
|
std path add "foo"
|
|
|
|
std path add "bar" "baz" --append
|
2023-10-25 14:43:27 +00:00
|
|
|
assert equal (get_path) (["foo", "bar", "baz"] | path expand)
|
2023-03-16 18:23:29 +00:00
|
|
|
|
2023-10-25 14:43:27 +00:00
|
|
|
assert equal (std path add "fooooo" --ret) (["fooooo", "foo", "bar", "baz"] | path expand)
|
|
|
|
assert equal (get_path) (["fooooo", "foo", "bar", "baz"] | path expand)
|
2023-05-26 07:24:53 +00:00
|
|
|
|
2023-06-30 19:57:51 +00:00
|
|
|
load-env {$path_name: []}
|
Fix unit tests on Android (#10224)
# Description
* The path to the binaries for tests is slightly incorrect. It is
missing the build target when it is set with the `CARGO_BUILD_TARGET`
environment variable. For example, when `CARGO_BUILD_TARGET` is set to
`aarch64-linux-android`, the path to the `nu` binary is:
`./target/aarch64-linux-android/debug/nu`
rather than
`./target/debug/nu`
This is common on Termux since the default target that rustc detects can
cause problems on some projects, such as [python's `cryptography`
package](https://github.com/pyca/cryptography/issues/7248).
This technically isn't a problem specific to Android, but is more likely
to happen on Android due to the latter.
* Additionally, the existing variable named `NUSHELL_CARGO_TARGET` is in
fact the profile, not the build target, so this was renamed to
`NUSHELL_CARGO_PROFILE`. This change is included because without the
rename, the build system would be using `CARGO_BUILD_TARGET` for the
build target and `NUSHELL_CARGO_TARGET` for the build profile, which is
confusing.
* `std path add` tests were missing `android` test
# User-Facing Changes
For those who would like to build nushell on Termux, the unit tests will
pass now.
2023-09-05 08:17:34 +00:00
|
|
|
|
|
|
|
let target_paths = {
|
|
|
|
linux: "foo",
|
|
|
|
windows: "bar",
|
|
|
|
macos: "baz",
|
|
|
|
android: "quux",
|
|
|
|
}
|
2023-06-10 18:16:17 +00:00
|
|
|
|
2023-05-26 07:24:53 +00:00
|
|
|
std path add $target_paths
|
2023-10-25 14:43:27 +00:00
|
|
|
assert equal (get_path) ([($target_paths | get $nu.os-info.name)] | path expand)
|
|
|
|
|
Surprising symlink resolution for std `path add` (#13258)
# Description
The standard library's `path add` function has some surprising side
effects that I attempt to address in this PR:
1. Paths added, if they are symbolic links, should not be resolved to
their targets. Currently, resolution happens.
Imagine the following:
```nu
# Some time earlier, perhaps even not by the user, a symlink is created
mkdir real-dir
ln -s real-dir link-dir
# Then, step to now, with link-dir that we want in our PATHS variable
use std
path add link-dir
```
In the current implementation of `path add`, it is _not_ `link-dir` that
will be added, as has been stated in the command. It is instead
`real-dir`. This is surprising. Users have the agency to do this
resolution if they wish with `path expand` (sans a `--no-symlink` flag):
for example, `path add (link-dir | path expand)`
In particular, when I was trying to set up
[fnm](https://github.com/Schniz/fnm), a Node.js version manager, I was
bitten by this fact when `fnm` told me that an expected path had not
been added to the PATHS variable. It was looking for the non-resolved
link. The user in [this
comment](https://github.com/Schniz/fnm/issues/463#issuecomment-1710050737)
was likely affected by this too.
Shells, such as nushell, can handle path symlinks just fine. Binary
lookup is unaffected. Let resolution be opt-in.
Lastly, there is some convention already in place for **not** resolving
path symlinks in the [default $env.ENV_CONVERSIONS
table](https://github.com/nushell/nushell/blob/57452337ff4e228102433e99b4c6000700a9b3b2/crates/nu-utils/src/sample_config/default_env.nu#L65).
2. All existing paths in the path variable should be left untouched.
Currently, they are `path expand`-ed (including symbolic link
resolution).
Path add should mean just that: prepend/append this path.
Instead, it currently means that, _plus mutate all other paths in the
variable_.
Again, users have the agency to do this with something like `$env.PATH =
$env.PATH | split row (char esep) | path expand`.
3. Minorly, I update documentation on running tests in
`crates/nu-std/CONTRIBUTING.md`. The offered command to run the standard
library test suite was no longer functional. Thanks to @weirdan in [this
Discord
conversation](https://discord.com/channels/601130461678272522/614593951969574961/1256029201119576147)
for the context.
# User-Facing Changes
(Written from the perspective of release notes)
- The standard library's `path add` function no longer resolves symlinks
in either the newly added paths, nor the other paths already in the
variable.
# Tests + Formatting
A test for the changes working correctly has been added to
`crates/nu-std/tests/test_std.nu` under the test named
`path_add_expand`.
You can quickly verify this new test and the existing `path add` test
with the following command:
```nu
cargo run -- -c 'use crates/nu-std/testing.nu; NU_LOG_LEVEL=INFO testing run-tests --path crates/nu-std --test path_add'
```
All commands suggested in the issue template have been run and complete
without error.
# After Submitting
I'll add a release note to [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged.
2024-06-28 23:11:48 +00:00
|
|
|
load-env {$path_name: [$"(["/foo", "/bar"] | path expand | str join (char esep))"]}
|
2023-10-25 14:43:27 +00:00
|
|
|
std path add "~/foo"
|
|
|
|
assert equal (get_path) (["~/foo", "/foo", "/bar"] | path expand)
|
2023-03-16 18:23:29 +00:00
|
|
|
}
|
|
|
|
}
|
2023-05-10 12:05:01 +00:00
|
|
|
|
Surprising symlink resolution for std `path add` (#13258)
# Description
The standard library's `path add` function has some surprising side
effects that I attempt to address in this PR:
1. Paths added, if they are symbolic links, should not be resolved to
their targets. Currently, resolution happens.
Imagine the following:
```nu
# Some time earlier, perhaps even not by the user, a symlink is created
mkdir real-dir
ln -s real-dir link-dir
# Then, step to now, with link-dir that we want in our PATHS variable
use std
path add link-dir
```
In the current implementation of `path add`, it is _not_ `link-dir` that
will be added, as has been stated in the command. It is instead
`real-dir`. This is surprising. Users have the agency to do this
resolution if they wish with `path expand` (sans a `--no-symlink` flag):
for example, `path add (link-dir | path expand)`
In particular, when I was trying to set up
[fnm](https://github.com/Schniz/fnm), a Node.js version manager, I was
bitten by this fact when `fnm` told me that an expected path had not
been added to the PATHS variable. It was looking for the non-resolved
link. The user in [this
comment](https://github.com/Schniz/fnm/issues/463#issuecomment-1710050737)
was likely affected by this too.
Shells, such as nushell, can handle path symlinks just fine. Binary
lookup is unaffected. Let resolution be opt-in.
Lastly, there is some convention already in place for **not** resolving
path symlinks in the [default $env.ENV_CONVERSIONS
table](https://github.com/nushell/nushell/blob/57452337ff4e228102433e99b4c6000700a9b3b2/crates/nu-utils/src/sample_config/default_env.nu#L65).
2. All existing paths in the path variable should be left untouched.
Currently, they are `path expand`-ed (including symbolic link
resolution).
Path add should mean just that: prepend/append this path.
Instead, it currently means that, _plus mutate all other paths in the
variable_.
Again, users have the agency to do this with something like `$env.PATH =
$env.PATH | split row (char esep) | path expand`.
3. Minorly, I update documentation on running tests in
`crates/nu-std/CONTRIBUTING.md`. The offered command to run the standard
library test suite was no longer functional. Thanks to @weirdan in [this
Discord
conversation](https://discord.com/channels/601130461678272522/614593951969574961/1256029201119576147)
for the context.
# User-Facing Changes
(Written from the perspective of release notes)
- The standard library's `path add` function no longer resolves symlinks
in either the newly added paths, nor the other paths already in the
variable.
# Tests + Formatting
A test for the changes working correctly has been added to
`crates/nu-std/tests/test_std.nu` under the test named
`path_add_expand`.
You can quickly verify this new test and the existing `path add` test
with the following command:
```nu
cargo run -- -c 'use crates/nu-std/testing.nu; NU_LOG_LEVEL=INFO testing run-tests --path crates/nu-std --test path_add'
```
All commands suggested in the issue template have been run and complete
without error.
# After Submitting
I'll add a release note to [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged.
2024-06-28 23:11:48 +00:00
|
|
|
#[test]
|
|
|
|
def path_add_expand [] {
|
|
|
|
use std assert
|
|
|
|
|
|
|
|
# random paths to avoid collision, especially if left dangling on failure
|
|
|
|
let real_dir = $nu.temp-path | path join $"real-dir-(random chars)"
|
|
|
|
let link_dir = $nu.temp-path | path join $"link-dir-(random chars)"
|
|
|
|
mkdir $real_dir
|
|
|
|
let path_name = if $nu.os-info.family == 'windows' {
|
|
|
|
mklink /D $link_dir $real_dir
|
|
|
|
"Path"
|
|
|
|
} else {
|
|
|
|
ln -s $real_dir $link_dir | ignore
|
|
|
|
"PATH"
|
|
|
|
}
|
|
|
|
|
|
|
|
with-env {$path_name: []} {
|
|
|
|
def get_path [] { $env | get $path_name }
|
|
|
|
|
|
|
|
std path add $link_dir
|
|
|
|
assert equal (get_path) ([$link_dir])
|
|
|
|
}
|
|
|
|
|
|
|
|
rm $real_dir $link_dir
|
|
|
|
}
|
|
|
|
|
2023-07-02 08:41:33 +00:00
|
|
|
#[test]
|
|
|
|
def banner [] {
|
2023-05-10 12:05:01 +00:00
|
|
|
std assert ((std banner | lines | length) == 15)
|
|
|
|
}
|
2023-09-12 19:59:31 +00:00
|
|
|
|
|
|
|
#[test]
|
|
|
|
def repeat_things [] {
|
|
|
|
std assert error { "foo" | std repeat -1 }
|
|
|
|
|
|
|
|
for x in ["foo", [1 2], {a: 1}] {
|
|
|
|
std assert equal ($x | std repeat 0) []
|
|
|
|
std assert equal ($x | std repeat 1) [$x]
|
|
|
|
std assert equal ($x | std repeat 2) [$x $x]
|
|
|
|
}
|
|
|
|
}
|