cp, ls and others cannot access file that is actually present (and accessible). #10571
Description
Describe the bug
Apropos the discussion at the bottom of #10557
If a file path contains glob metachars, you cannot access it from any command that takes arguemnts that are globs (unless you do extra glob quoting).
How to reproduce
Example:
> ls **/*
╭───┬───────┬──────┬──────┬────────────────╮
│ # │ name │ type │ size │ modified │
├───┼───────┼──────┼──────┼────────────────┤
│ 0 │ a[b]d │ file │ 0 B │ 35 seconds ago │
│ 1 │ foo │ dir │ 2 B │ a minute ago │
╰───┴───────┴──────┴──────┴────────────────╯
> glob a[b]d
╭────────────╮
│ empty list │
╰────────────╯
> ucp a[b]d foo
Error: nu::shell::file_not_found
× File not found
╭─[entry #41:1:1]
1 │ ucp a[b]d foo
· ──┬──
· ╰── file not found
╰────
> cp a[b]d foo
Error: × No matches found
╭─[entry #42:1:1]
1 │ cp a[b]d foo
· ──┬──
· ╰── no matches found
╰────
> ls a[b]d
Error: × No matches found for a[b]d
╭─[entry #44:1:1]
1 │ ls a[b]d
· ──┬──
· ╰── Pattern, file or folder not found
╰────
help: no matches found
The file exists, but cannot be accessed by any of the above command.
You can access it, but need to resort to quoting in the command argument:
> ls a[b]d
Error: × No matches found for a[b]d
╭─[entry #44:1:1]
1 │ ls a[b]d
· ──┬──
· ╰── Pattern, file or folder not found
╰────
help: no matches found
> ls a[[]b[]]d
╭───┬───────┬──────┬──────┬────────────────╮
│ # │ name │ type │ size │ modified │
├───┼───────┼──────┼──────┼────────────────┤
│ 0 │ a[b]d │ file │ 0 B │ 14 minutes ago │
╰───┴───────┴──────┴──────┴────────────────╯
Expected behavior
I think user is right to expect ls, cp to be able to access the file whose name is explicitly provided. The path contains unusual, but perfectly legal chars.
Further, the user is not likely to try glob quoting with [] to workaround this issue. S/he is more likely to try string quoting with \ and get frustrated that does not work.
Screenshots
No response
Configuration
| key | value |
|---|---|
| version | 0.85.1 |
| branch | wax_glob2 |
| commit_hash | 9ced035 |
| build_os | linux-x86_64 |
| build_target | x86_64-unknown-linux-gnu |
| rust_version | rustc 1.70.0 (90c541806 2023-05-31) |
| rust_channel | 1.70.0-x86_64-unknown-linux-gnu |
| cargo_version | cargo 1.70.0 (ec8a8a0ca 2023-04-25) |
| build_time | 2023-10-01 10:13:49 -07:00 |
| build_rust_channel | debug |
| allocator | mimalloc |
| features | default, sqlite, trash, which, zip |
| installed_plugins |
Additional context
Note that we have this problem with glob characters that were supported before PR #10557, and with commands that use both the new and the old glob algorithm.
What to do? For all of the commands that take a glob as argument, with the possible exception of glob command, I think the right thing to do is first try the arg as a literal path (e.g stat the arg), only proceed to try it as a glob if the stat fails.