This is awesome! For me, the exact semantics are not as important as the fact that the behavior is unified, meaning that if we need to reconsider the globbing behavior at some point, we'd change it in one place instead of 10.

glob escape sounds good as well as a way to escape globbing. We could even land just the unification and leave glob escape to a separate PR.

I thought double/single quoting was the standard way of telling any shell "this is a string. don't mess with it"?

The Nu cp command insists on at least 2 arguments and just knows that the last argument is a single path, not a glob.

Actually it remains the same, the last argument is still a single path.

I think something like: cp able noglob://bak*er charlie required user typing too much things, cp able "bak*er" charlie is more readable. Maybe it's more comfortable to users from other shells?
After reading relative issues, I think quoting something to say "this is just a string, no need to escape it" is natural.

After reading relative issues, I think quoting something to say "this is just a string, no need to escape it" is natural.

I agree with this too. However, double quotes still have to escape things to be json compliant I believe.

As I mentioned, the main value of this PR is the unification of globbing across commands. If we need to change how globbing works, this PR makes it easier to do by changing it only in one place. I'd vote for landing this.

I'm fine with landing it too,

• main needs to be merged, since we removed cp-old.
• touch "[a] b.c" works, rm `[a] b.c` also works (maybe add a test) (windows)
• rm '[a] b.c' and rm "[a] b.c" work fine (windows)
• perhaps touch should be added (could be another pr)
• perhaps ls should be added (could be another pr)
• touch "\u{1b}[31mnushell\u{1b}[0m" works but then you see a red nushell that you don't know how to remove. (real use case someone had) (ubuntu)
• rm "\u{1b}[31mnushell\u{1b}[0m" and rm '\u{1b}[31mnushell\u{1b}[0m' doesn't work (ubuntu)
• i can only see the odd file in zsh as ''$'\033''[31mnushell'$'\033''[0m' and rm $'\033'\[31mnushell$'\033'\[0m got rid of it
• string interpolation seems to work. here's my test

touch 1.txt
let a = '1'
rm $"($a).txt"

touch "[a] b.c" works, but rm [a] b.c does not work (maybe fix and add a test) (windows)

It shouldn't work, because we treated backtick quoted as a bare word.

touch "\u{1b}[31mnushell\u{1b}[0m" works but then you see a red nushell that you don't know how to remove. (real use case someone had) (ubuntu)

For such file, it's because we auto strip ansi string, maybe we need to find a way to fix such issue

It shouldn't work, because we treated backtick quoted as a bare word.

I am thinking it probably should because backticks are what we use with paths with spaces in them. I think that's why backticks work in this situation, because there is a space in the filename.

For such file, it's because we auto strip ansi string, maybe we need to find a way to fix such issue

I think this is a special issue that could be handled in a separate PR but it's interesting to me that other shells do not just create a folder literally, the encode the escape from \u{1b} to '$'\033'' before trying to create a file with "bad" characters.

I am thinking it probably should because backticks are what we use with paths with spaces in them. I think that's why backticks work in this situation, because there is a space in the filename.

Maybe we can discuss it in next meeting :-)

other shells do not just create a folder literally, the encode the escape from \u{1b} to '$'\033'' before trying to create a file with "bad" characters.

That's interesting, maybe we can fix it in that direction, like modify mkdir command. And keep in mind on touch command while we are adding it to nushell.

That's interesting, maybe we can fix it in that direction, like modify mkdir command. And keep in mind on touch command while we are adding it to nushell.

ya, i think the fix needs to be like what you're saying. we intercept escapes and encode them somehow before trying to create a file.

I just texted this again and rm with backticks works like i thought it should. maybe i did something different yesterday?

❯ touch "[a] b.c"  
❯ rm `[a] b.c`

Yeah, I agree, we can iterate on the glob semantic in separate PRs. Now it's at least uniform.

IMO, backticked word is bare word and thus should be glob-expanded. That makes sense to me.

Drive by comment, but I was reading the last changelog, and

So I'll introduce a new command called glob escape, then if user doesn't want to auto-expand the glob pattern, he can just do this: rm ($path | glob escape)

Feels very surprising.

It seems to me that this behavior is very error prone? rm $file looks like it removes a single file. What’s more, it works as if it removes only a single file most of the time, so the user won’t learn about mistakes in their mental model until the day the file is named *.

To put it in other way, I posit that with the current semantics:

• most arguments should be using | str glob-escape
• almost none will be

Is there any way to make it work the opposite way? Such that rm $file is never a glob, and rm ($file | str glob) is?

Note: although I feel very strongly about the isssue, my level of confidence here is low, I might be misunderstanding something about nu which makes this pattern not as problematic as it seems.

In supporting globbin of rm arguments, nushell is just following the lead of traditional shells

Indeed, and my understanding is that this behavior is a confirmed footgun in those shells.

For example shellcheck lints against unquoted variables:

https://www.shellcheck.net/wiki/SC2086

So, for a shell language which isn’t trying to be compatible with POSIX shell, I’d expect a different, safer semantics by default.

IMHO, this change breaks the principle of least astonishment. Considering the three following snippets:

1. let a = "a?c"
   rm $a

2. rm a?c

3. rm "a?c"

The first two are equivalent, but the last one isn't. I would expect (looking strictly at quotes) that the 1st and 3rd statement are equivalent, but instead they behave differently. Given a variable a, now the way to achieve the same behavior as 3. is:

4. let a = "a?c"
   rm ($a | str glob-escape)
   

Which looks very differently from 3.

Nu seems to pride itself in approaching things differently. Notably, given a string with spaces like

let a = "-rm ."

Then this command is safe to execute and will delete a file named -rm ., since $a is a single string:

rm $a

However, this assumption that using a variable to execute a command is safe is now broken following this change; additional arguments/flags will not be given to rm (a strength of Nushell), but $a will still be expanded.

Perhaps nushell rm should integrate with the "trash" mechanism on the underlying platform?

IMO this doesn't solve it. mv and other such commands will still move (and potentially overwrite) items, which doesn't involve the system trash.

@matklad How should the safer semantics work in practice?
If Nu does not glob rm arguments, how should the knowledgeable and careful user actually delete multiple files?

> rm a.txt b.txt c.txt                            # works, but is typo-prone and tedious

> ls *.txt | rm                                   # nope, rm doesn't accept pipeline input
Error: nu::parser::missing_positional

  × Missing required positional argument.
   ╭─[entry #9:1:1]
 1 │ ls *.txt | rm
   ╰────
  help: Usage: rm {flags} <filename> ...(rest) . Use `--help` for more information.

> ls *.txt | each  {|x| rm $x.name}              # works, is nushell - normative, but intuitive?  
╭────────────╮                                   # And what is this 'empty list' result?
│ empty list │
╰────────────╯

The rest of the world seems to have decided that the best balance between "convenience" and "safety" here is to allow globbing but to enable wastebasket or similarly named mechanism to recover from mistakes.

Building on this, I just discovered that rm --trash is a thing, and actually does work on linux. Perhaps it should be the default?

We've been asked before to make --trash the default and I think there was a PR for it but IIRC, there was something that stopped it from landing because every platform we support didn't support the trash functionality. That was years ago so that could've changed. There is already a $env.config.rm.always_trash config setting too (defaults to false).

@bobhy I personally find the behavior of fish shell quite reasonable:

15:52:45|~/tmp
λ touch '*' 'a.txt' 'b.txt' 'c.txt' && rm * && eza

15:52:56|~/tmp
λ touch '*' 'a.txt' 'b.txt' 'c.txt' && rm '*' && eza
a.txt  b.txt  c.txt

15:52:59|~/tmp
λ touch '*' 'a.txt' 'b.txt' 'c.txt' && FILE='*' rm $FILE && eza
a.txt  b.txt  c.txt

15:53:06|~/tmp
λ touch '*' 'a.txt' 'b.txt' 'c.txt' && FILE='*' eval rm $FILE && eza

Numbering and labeling these to reference them. Let me know if I interpreted them wrong.

1. globbing *, removes everything
2. non-globbing, looking for literal '*', removes nothing but literal '*' file
3. non-globbing, since it's a variable, I guess? removes nothing
4. still non-globbing, but uses eval to turn it into a glob, I guess? removes everything

Yup, that's correct, just "removes nothing" -> "removes only the file whose name is literally '*'":

λ touch '*' 'a.txt' 'b.txt' 'c.txt'  && eza
*  a.txt  b.txt  c.txt

If Nu does not glob rm arguments, how should the knowledgeable and careful user actually delete multiple files?

The spread operator could be made to work, e.g. glob *.txt | rm ...$in. It doesn't currently because rm has a required positional argument and the spread operator only spread into rest arguments (or other list contexts).

the behavior of fish shell

A principled interpretation of the behavior would be to consistently distinguish between "bareword string" and "quoted string" shapes (the any shape preserving the distinction), treating the content of "quoted strings" as final, applying the same rules to all shapes that impact semantics (at least glob and path).

The most directly equivalent constructs written in Nu would be (checked means expands glob):

• ls *
• ls '*' (0.90 feature
• with-env [FILE *] { ls $env.FILE }
• with-env [FILE *] { ^$nu.current-exe -c $'ls ($env.FILE)' } (little a eval, as a treat)

Nu-specific fun:

• ls ('*')
• '*' | ls $in
• def f [file] { ls $file }; f '*'
• def f [file: glob] { ls $file }; f '*' (syntax shape changes semantics)
• def f [file: glob] { ls $file }; f ('*') (but not through other constructs)

Thank you for all feedback!

I can try to adjust the behavior when we meet variables

Maybe look at how path is handled: a syntax shape of path will expand barewords but not strings (quoted, expression, or variable). It would mean flipping from "use str escape-glob to prevent glob expansion" to "use glob to get glob expansion from pipelines" though.

My crazy-concept idea would be for a ...pattern: glob shape to expand bareword globs directly, with everything else interacting with it as just ...pattern: path. That is, writing ls *.nu would be translated by the syntax shape into the equivalent of ls ...(glob '*.nu'). (It would probably want lazy/deferred expansion support as an optimization, though.)