unlink doesn't complain if it tries to operate on a file that doesn't exist

[briandfoy]

I don't know if unlink should succeed or not for a file that doesn't exist. I would expect it to fail but if it doesn't I'm not bothered. Whatever the answer it would be nice to see it noted in the docs.

Here's what I was doing on 2018.04:

my @files = <a.txt b.txt c.txt d.txt e.txt /etc/hosts>;
say 'Exists: ', @files.grep: *.IO.e;

my @unlinked-files = unlink @files;
say 'All: ', @files;
say 'Removed: ', @unlinked-files;

my @error-files = @files.Set (-) @unlinked-files.Set;

say 'Problems: ', @error-files;

And some output:

Exists: (a.txt b.txt c.txt /etc/hosts)
All: [a.txt b.txt c.txt d.txt e.txt /etc/hosts]
Removed: [a.txt b.txt c.txt d.txt e.txt]
Problems: [set(/etc/hosts)]

[rafaelschipiura]

It copies the way Perl 5 does it and it in turns copies the way it's done in C.

Don't know if there is a motive for it being that way, but I think the documentation should certainly have a note about it.

[briandfoy]

Perl 5's unlink returns a count and doesn't count the files that were missing.

[JJ]

Unlink behaves exactly as indicated in the documentation, which I have only clarified a little bit. It fails if you call it as a method, it returns an array as it does in your example above if called as a subroutine. If you want a count of the number of files, call .elems on the result.

[briandfoy]

None of those statements address the original issue and the documentation is still unclear and incomplete on the original issue. Why was this closed without resolution?

[JJ]

Let's see:

I don't know if unlink should succeed or not for a file that doesn't exist.

The documents don't know either. However. they say:

The subroutine form returns the names of the files that were successfully deleted. The method form returns True on success, or fails with X::IO::Unlink if the operation could not be completed.

So it clearly says:

• It succeeds if called as a subroutine, no matter what.
• it fails on with a particular exception if it can't delete a file, only if called as a method.

I would expect it to fail but it it doesn't matter I'm not bothered.

That's OK. It fails, or not, depending on how you call it, but since you're not bothered either way, I guess that's properly addressed.

Whatever the answer it would be nice to see it noted in the docs.

It is in the docs exactly as above, and it's been there for 3 years already. Only change has been to specify that only those files that can be deleted are actually deleted. No surprise there.

Perl 5's unlink returns a count and doesn't count the files that were missing.

Right. Perl 6 works exactly as you noted in your example, which matches exactly what has been in the documentation for 3 years.

None of those statements address the original issue and the documentation is still unclear and incomplete on the original issue. Why was this closed without resolution?

The behavior you noted is as expected, it's documented in a precise way, I revised the documentation, made a small precision, and made the call to close this issue, since it's, as explained above, well, a non-issue. We thank you for the report, that help us improve the documentation, even in little ways, and feel free to open any more issues on anything you consider necessary; just not this one. 👍

[briandfoy]

I don't appreciate your attitude here. I'll refrain from further participation.

[JJ]

What do you mean exactly by "my attitude" here?

[JJ]

OK, I get it now after @zoffixznet 's patch and @rafaelschipiura explanations in the IRC channel. All the *.txt files did not exist to start with. So the documentation was actually wrong because it returned those files deleted and those that didn't exist. I don't know if that behavior is exactly as intended, and I'm sorry for, I guess my attitude. I guess the patch makes it clear now, and again my apologies.

[zoffixznet]

since you're not bothered either way, I guess that's properly addressed

In the future, a simple "Which portion needs further clarification?" would go a longer way, IMO.

[JJ]

Right. If I had read more thoroughly the title, and not only the post, it would have been clearer from the beginning too. Again my apologies.

[rafaelschipiura]

@briandfoy I'm not liking your attitude here. He already apologized for the misunderstanding, stop stalking him if you are not going to engage in a constructive manner.

[labster]

I would expect it to fail but if it doesn't I'm not bothered.

since you're not bothered either way, I guess that's properly addressed

sigh