This change is for users who commit fish_plugins and plugin sources but
omit fish_variables. On a system where Fisher's universal variables are
unset, most Fisher commands were not working out-of-the-box:
* `fisher install <plugin>` - installs <plugin>, rewrites fish_plugins file with only <plugin>
- if <plugin> is in fish_plugins, same behavior as `fisher update`
* `fisher remove <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update` - fails with error about conflicting files, deletes fish_plugins file
* `fisher list [<regex>]` - returns nothing
As of this commit all Fisher commands work except for `fisher remove`;
Fisher still has no way of knowing which files to remove absent the
universal variable that tracks the files associated to a plugin.
It may make sense to reject calls like `fisher remove <plugin>` if the
`_fisher_<plugin>_files` universal variable is missing. Fisher could
suggest the user run `fisher update` and try again.
GitHub has decided to archive the current git.io links in a
new read-only service that will allow us to continue using
redirects for existing git.io links.
I have a docker image that can install fish, but it is version 3.0.2.
The bash-compatible mechnism fish_path=(status fish-path) command
was not added until after 3.0.2, probably 3.1.