Make fish_add_path more transparent

[faho]

Description

fish_add_path has a pretty tricky dual nature:

• It's usable in config.fish - you throw it in there and it does The Right Thing
• It's usable in the commandline

These two have different needs - scripted use needs it to be as quiet as possible. If a path wasn't added because it's already included, that's probably because it already ran. If a path wasn't added because it's a file, that's probably because it was a directory on another system.

Interactive use, on the other hand, suffers a bit from a lack of feedback - you do something and it either silently returns true or false, without explaining why.

We have "verbose" mode - fish_add_path -v, but that's something people need to know about, and it currently does not explain enough.

So, what this does is:

1. It makes verbose mode more informative by printing a message for each path that was eliminated and also if no path was left
2. (the spicy part) It automatically enables verbose mode if fish_add_path is used interactively, from the commandline - if you run fish_add_path /foo at your prompt, you'll get messages

That latter part is a bit naughty - numerous CLI guidelines don't like this. But I do believe it's helpful, and I don't really see an alternative - anything else requires adding a flag to get messages interactively, or adding a flag to suppress them noninteractively.

I see people on the internet fail regularly by trying to add a file instead of the directory it contains:

fish_add_path /opt/bin/texlive # <- should be /opt/bin!

and we currently have no warning about this - it will just silently return false. You'll have to run fish_add_path -v /opt/bin/texlive to get "Skipping path because it is a file instead of a directory".

Adding this means they'll get the feedback, which should make their mistake obvious - add the directory. (an alternative for this specific case is to automatically dirname any file, but the lack of information hurts in other cases as well)

TODOs:

• Changes to fish usage are reflected in user documentation/manpages.
• Tests have been added for regressions fixed
• User-visible changes noted in CHANGELOG.rst

[zanchey]

I agree this is helpful.

[mqudsi]

I think this is a good idea, but maybe for different reasons?

In particular:

I see people on the internet fail regularly by trying to add a file instead of the directory it contains:

I would like to see this error out regardless if it's being used interactively or in config.fish. After all, someone experimenting by adding it to config.fish isn't necessarily going to be trying it interactively (or even realizing that it's an option to do so).

[faho]

I would like to see this error out regardless if it's being used interactively or in config.fish

Unfortunately that would run into the same problem we had when we errored out setting $PATH with an invalid path - people sync their config to other machines, and then ssh breaks.

That's why we removed that, and why fish_add_path currently does not print an error, especially because these things aren't really exceptional - the path you gave isn't usable as a component to $PATH, so we're just not adding it.

[mqudsi]

The specific case of a path existing but being a file is distinct from the path not existing at all, and I think the odds of the path being a file on one system but a directory on another is relatively unlikely?

[faho]

The failure mode here is too awkward to print messages in rare cases. Rare messages aren't a good idea because then it's hard to know that there's sometimes a message.

I don't want to break things for people who do everything right (just copy your config to a different machine which happens to have a different file structure) in favor of people who did something wrong - try to add a file to $PATH, which is clearly broken (that's just not how $PATH works).

By contrast in interactive use there's no breakage, it's only upside. So that's a niche we can work in.

For people who aren't hardcore users, I would also assume that they'd be more likely to just run fish_add_path interactively, and even for those that don't I would assume they'd run it interactively before as a test and then add it to a config.fish they might keep in version control.

[mqudsi]

As I said, I'm not against the feature you propose. I am just questioning if there isn't more we can do.

Maybe I am missing something but I just cannot see a reasonable "correct case" you speak of that would involve a path sometimes being a directory on some machines and sometimes being a file on others. The typical Unix hierarchy both by definition and by convention would make it, to my mind, extremely improbable.

[faho]

Maybe I am missing something but I just cannot see a reasonable "correct case" you speak of that would involve a path sometimes being a directory on some machines and sometimes being a file on others

It's not whether it's incorrect or not that these systems differ like that. The systems differ in that way, and then the trigger is something as innocent as

scp config.fish user@host

and suddenly scp is broken. Even with a perfectly well-written config.fish that doesn't print anything, and doesn't have anything that someone would think prints anything (and doesn't on their system, and wouldn't on a system with another fish version)! That's why sometimes sending messages in config.fish is a bad idea, and why we're not doing that.

[mqudsi]

I guess that's a fair enough reason. Thanks.