Missing documentation on when quotes are / are not preserved for an argument
Describe the bug
see https://github.com/nushell/nushell/issues/6577#issuecomment-1250241095 for current state
Old stuff ls, rm... have a, inconsistent behavior depending on how the file path is provided, event though is strictly equivalent from the point of view of the user. The use case that led to this observation was to pass a file between quotes (spaces in path, multi platform).
How to reproduce
first define a variable containing the string of a file path (file must exist), the second line show the result of creating the string with quotes:
> let x = "/home/mmunoz/MMU/TEMP/somefile.txt"
> print $"\"($x)\""
"/home/mmunoz/MMU/TEMP/somefile.txt"
now, with ls (but rm acts the same, for example), for the user the three invocations are the "same", but one fails :
> ls "/home/mmunoz/MMU/TEMP/somefile.txt"
╭───┬────────────────────────────────────┬──────┬──────┬────────────────╮
│ # │ name │ type │ size │ modified │
├───┼────────────────────────────────────┼──────┼──────┼────────────────┤
│ 0 │ /home/mmunoz/MMU/TEMP/somefile.txt │ file │ 0 B │ 11 minutes ago │
╰───┴────────────────────────────────────┴──────┴──────┴────────────────╯
> ls $x
╭───┬────────────────────────────────────┬──────┬──────┬──────────────╮
│ # │ name │ type │ size │ modified │
├───┼────────────────────────────────────┼──────┼──────┼──────────────┤
│ 0 │ /home/mmunoz/MMU/TEMP/somefile.txt │ file │ 0 B │ a minute ago │
╰───┴────────────────────────────────────┴──────┴──────┴──────────────╯
> ls $"\"($x)\""
Error: nu::shell::directory_not_found (link)
× Directory not found
╭─[entry #60:1:1]
1 │ ls $"\"($x)\""
· ─────┬─────
· ╰── directory not found
╰────
Expected behavior
The last case should not fail, it is a pretty standard use for "quoting" a file path with spaces and have a uniform processing across OSes.
Screenshots
No response
Configuration
linux nushell 0.68.1
Additional context
No response
I'm a bit against this, ls $"\"($x)\"" is actually ls "\"/home/mmunoz/MMU/TEMP/somefile.txt\"" you bring the quote itself to ls, I think it has the reason to fail.
For your print example:
> let x = "/home/mmunoz/MMU/TEMP/somefile.txt"
> print $"\"($x)\""
"/home/mmunoz/MMU/TEMP/somefile.txt"
you can find that print $x and print $"\"($x)\"" are actually different.
Okay, I see your point (the "$\" one, the unnecessary extra quotes is wrong, i should have used ls $"($x)" my mistake, I am juggling between nu -c "command" style which require this construct and native nu commands like in the example).
The thing that led to adding quotes is that the behavior of "quoting is implicitly kept" (or not) should be documented somewhere (it is an important mechanism for shell scripting, same as https://github.com/nushell/nushell/issues/6352#issue-1342955777 where expansion behavior is important and should be documented) ; here I assumed the behavior was the same as the linux shell, so I tried to add (too much) quotes.
Here nushell and linux shell behave differently, in linux, for a path with spaces (or not) the quoting is not implicitly preserved), so ls $x does not work in linux shell but does work in nushell :
(linux)
> x="/home/MMU/PATH WITH SPACES/somefile.txt"
> ls $x
ls: cannot access '/home/MMU/TMP/PATH': No such file or directory !!!
ls: cannot access 'WITH': No such file or directory !!!
ls: cannot access 'SPACES/somefile.txt': No such file or directory !!!
> ls "$x"
'/home/MMU/TMP/PATH WITH SPACES/somefile.txt'
(nushell)
> let x = "/home/MMU/TMP/PATH WITH SPACES/somefile.txt"
> ls $x
(works fine)
> ls $"($x)"
(works fine)
Maybe, like #6352, this is more and issue of documentation ? (and title should be changed accordingly if so)
Maybe, like https://github.com/nushell/nushell/issues/6352, this is more and issue of documentation ? (and title should be changed accordingly if so)
Yeah, I think it's more about documentation issue :)
For the following example you given:
(nushell)
> let x = "/home/MMU/TMP/PATH WITH SPACES/somefile.txt"
> ls $x
(works fine)
> ls $"($x)"
(works fine)
I think that works as expected
I think that works as expected
Well, I was just saying that the behavior is different from linux shell. (to kown if it "work as expected", I would have to know the specs / doc about the behavior :) ) Title changed to reflect, and edit on first comment to redirect to useful comment.