> Unlike OpenVMS/TOPS-20/LispMachines/etc, mainstream POSIX file systems lack built-in versioning
We have git, which is strictly better.
> Directly related to (1), the fact that the unlink() system call is normally irreversible, and the rm command is (normally) a direct interface to unlink()
You'd be complaining about how a really_really_unlink_now_i_mean_it() syscall was irreversible, too.
> and the potential issues induced by the fact that wildcards are implemented by the shell not the command itself.
I like not having to rely on arbitrary commands implementing (or not) wildcards.
(Plus, even in the best of worlds, all commands would implement wildcards by linking in the same library, which brings us back to square one.)
> You'd be complaining about how a really_really_unlink_now_i_mean_it() syscall was irreversible, too.
Or the converse; what file (or worse hundreds/thousands of files) is using up all my disk and what's the sane way to delete all the old versions, and which files are important to keep all the old versions of?
> I like not having to rely on arbitrary commands implementing (or not) wildcards.
Indeed and being able to use meta tools like xargs. "The unreasonable effectiveness of plain text".
We have git, which is strictly better.
> Directly related to (1), the fact that the unlink() system call is normally irreversible, and the rm command is (normally) a direct interface to unlink()
You'd be complaining about how a really_really_unlink_now_i_mean_it() syscall was irreversible, too.
> and the potential issues induced by the fact that wildcards are implemented by the shell not the command itself.
I like not having to rely on arbitrary commands implementing (or not) wildcards.
(Plus, even in the best of worlds, all commands would implement wildcards by linking in the same library, which brings us back to square one.)