"Wildcard has no match" exception is unergonomic

[tesujimath]

What new feature should Elvish have?

I see that the exception throwing by default when wildcards have no match was added some time ago in response to a real issue.

However, the behaviour we have now is rather awkward. For example, when wanting to delete any file matching some set of wildcards:

> ls
a  ab  abc
> rm -f ab* bc*
Exception: wildcard has no match
  [tty 38]:1:11-13: rm -f ab* bc*
> ls
a  ab  abc

> rm -f ab*[nomatch-ok] bc*[nomatch-ok]
> ls
a

Bash is much more convenient:

> bash
$ ls
a  ab  abc
$ rm -f ab* bc*
$ ls
a

Could there be room for a rethink here?

Output of "elvish -version"

0.21.0

Code of Conduct

• I agree to follow Elvish's Code of Conduct.

[tesujimath]

Here is a more specific proposal to mitigate the awkwardness of the "wildcard has no match" exception, looping in @muesli who raised the original issue, and @xiaq obviously who is the design authority.

I suggest that the nomatch-ok global modifier for wildcards is a mistake, and should instead be the default. I noticed that it was introduced very quickly (perhaps rather hastily?) in response to that specific situation where ls lists everything if given no arguments. I think that could be solved in a more elegant way.

Suppose that the previous behaviour were re-instated, that is wildcards with no matches simply resolve to empty. This makes the awkwardness I describe above simply disappear. I suspect in general it is more convenient. It certainly seems more elegant to me, whereas the nomatch-ok modifier seems somewhat of a wart.

So then, what to do about ls *.pdf listing all files if there are no matches. That is a problem if the file list is piped somewhere, e.g. to xargs with some action that may be dangerous. I suggest that not be the idiomatic way of passing matching filenames through a pipe.

So perhaps for example instead of this unsafe practice:

> ls *.pdf | xargs rm -f

we should instead be adopting this:

> put *.pdf | to-lines | xargs rm -f

which could be made slicker, obviously.

My point is, wildcard expansion is such a fundamental part of shell behaviour that it needs to be conceptually clean, and what we have today falls short in my view.