"open" reports nu::shell::directory_not_found, should report nu::shell::file_not_found #10085
Description
Describe the bug
Per the title, very common command returns confusing feedback:
at 11:33:05 ❯ open "qweqwqe"
Error: nu::shell::directory_not_found
× Directory not found
╭─[entry #76:1:1]
1 │ open "qweqwqe"
· ────┬────
· ╰── directory not found
╰────
Since open only applies to files, not directories, this is confusing.
How to reproduce
Full repro above.
Expected behavior
I expect the following feedback:
at 11:33:05 ❯ open "qweqwqe"
Error: nu::shell::file_not_found
× File not found
╭─[entry #76:1:1]
1 │ open "qweqwqe"
· ────┬────
· ╰── file not found
╰────
Screenshots
No response
Configuration
| key | value |
|---|---|
| version | 0.83.1 |
| branch | |
| commit_hash | |
| build_os | linux-x86_64 |
| build_target | x86_64-unknown-linux-gnu |
| rust_version | rustc 1.71.0 (8ede3aae2 2023-07-12) |
| rust_channel | stable-x86_64-unknown-linux-gnu |
| cargo_version | cargo 1.71.0 (cfd3bbd8f 2023-06-08) |
| build_time | 2023-08-04 19:49:10 -04:00 |
| build_rust_channel | release |
| allocator | standard |
| features | default, sqlite, trash, which, zip |
| installed_plugins |
Additional context
open calls glob_from, which defaults to ShellError::DirectoryNotFound.
I am not sure whether DirectoryNotFound is a better default than FileNotFound for glob_from, but I'm pretty sure it isn't for open.
I'm happy to contribute a patch fixing open (seems very local) if that's the correct way to go, less sure about glob_from. Maybe the correct solution is to expand the glob API with a glob_files_from and use that instead where warranted?