What is the best way for an external application to extend fish PATH?

[gnzlbg]

There is this issue in rusup (the rust toolchain installer) about supporting the fish shell:

rust-lang/rustup#478 (comment)

After installation it says:

Rust is installed now. Great!

To get started you need Cargo's bin directory in your PATH environment variable.
Next time you log in this will be done automatically.

After installation it updates the PATH variable in .profile but fish doesn't read it (so the next time an user using fish shell logs in cargo, rust package manager, won't be in the user's PATH). Since fish is a very popular shell it would be nice if rustup could support it nicely.

What would be the right way for this kind of tool to:

• detect whether the user is running fish shell?
• update their path automatically (if possible)?
• detect whether the user overrides the path in its config file e.g. set -x PATH ... (without appending $PATH to it)? (in that case the user would need to update it manually)
• suggest how to manually update fish shell's PATH in a user config file (e.g. go to ~/.config/fish/config.fish and add set PATH ~/.cargo/bin $PATH).

[faho]

This has recently come up for Ubuntu's snappy in https://bugs.launchpad.net/bugs/1592558, and my answer is the same:

Since 2.3.0, fish reads configuration snippets in a couple of directories:

• "$__fish_datadir/conf.d" (will probably be "/usr/share/fish/conf.d" or something like it, is exposed via pkg-config fish --variable confdir) - this is for third-party software that is installed via a system package
• "$__fish_sysconfdir/conf.d" (e.g. "/etc/fish/conf.d") for the administrator
• "$XDG_CONFIG_HOME/fish/conf.d" (or "~/.config/fish/conf.d" if that variable is unset) for the user

So you might want to add a fish script (ending in ".fish") there. Those directories are our equivalent of /etc/profile.d.

If your directories might change, you might want to create a single file that contains one $PATH component per-line that the fish and the sh script then read (unless you really want to support newlines in your $PATH, in which case you could separate the components with ":" or NULL).

Would that work for you?

[gnzlbg]

Would using these directories work in MacOS?

[faho]

Sure, why would it not?

I mean there you could also use /etc/paths.d, which we already read, but this solution is platform-agnostic.

One caveat just appeared to me, though: Since $PATH is exported (and pretty much has to be), if you launched a fish inside another fish, you'd double-add your components. So you probably want to guard it with if not contains or similar.

[floam]

Sure, why would it not?

All of those directories would even work on OS X running by the self-contained .app bundle?

[faho]

@floam: I have no idea how the bundle thing is configured. What's $__fish_datadir and $__fish_sysconfdir in that thing?

The $HOME part should still work - it still has access to the system, after all.

[floam]

I am not near a computer but I recall they are defined in terms of the result of _NSGetExecutablePath() (man page) in fish.cpp.

[floam]

https://github.com/fish-shell/fish-shell/blob/master/src/fish.cpp#L125

[floam]

Here's what fish.app is ending up with on my system that also has fish installed by other means:

→ echo $__fish_sysconfdir 
/Applications/fish.app/Contents/Resources/base/etc/fish
→ echo $__fish_datadir 
/Applications/fish.app/Contents/Resources/base/share/fish
→ echo $__fish_help_dir 
/usr/local/share/doc
→ echo $fish_function_path 
/Users/floam/.config/fish/functions /Applications/fish.app/Contents/Resources/base/etc/fish/functions /Applications/fish.app/Contents/Resources/base/share/fish/functions
→ echo $fish_complete_path 
/Users/floam/.config/fish/completions /Applications/fish.app/Contents/Resources/base/etc/fish/completions /Applications/fish.app/Contents/Resources/base/share/fish/completions /Users/floam/.local/share/fish/generated_completions

You will need to install stuff into ~ here. Modifying the contents of an .app bundle is a no-no. Unless we want to ditto base/* into Application Support/fish (or... an app sandbox container!)?

@ridiculousfish Is it intended that $__fish_help_dir is pointing outside the app bundle?

[krader1961]

I'm not an OS X developer, just a long time user, but isn't the usual place to put local config data in $HOME/Library/Application Support/$AppName? Or possibly without the $HOME component. I have both on my system and it's not obvious what the latter is for. The $HOME based path has a lot more content; including things as the iTerm2 dynamic profile config file I created to customize my base profiles based on whether I'm running on my home server with dual 24" monitors or my laptop.

[floam]

I figured out the problem with the help dir. It's the same problem that is causing #3140.

[floam]

@krader1961 Basically, yes. A mapping in ~/Library/Application Support/fish would at least be expected for a Mac app.

Traditionally the system Library, /System/Library, is (supposed to be) for Apple. This is now enforceable with System Integrity Protection so it only recently actually is. /Library/ is the local library. ~/Library/ is for the user.

Just FYI, if you're looking for configuration files for an arbitrary Mac app you have on your system there are other places you might look:

You may have noticed that a number of apps on your machine have migrated data out of Library/Application Support and Library/Preferences (user and local) in recent years. If you see a very stale or missing ~/Library/Application Support/AppName/ it's likely now residing in a rather different state in ~/Library/Containers and/or ~/Library/GroupContainers for app sandbox.

[faho]

@gnzlbg: I'm assuming that answers your question. If you have any more, feel free to ask!

[awelkie]

What about editing the fish_user_paths variable? This seems like the preferred option from this issue

[faho]

@awelkie: fish_user_paths is strictly for the user. Adding to it from the outside might need to weird behavior, since it's universal by default (i.e. persistently stored on disk and shared between fish instances on the same machine). That means you should never unconditionally append to it since that will cause it to grow.

If you have another software project that wishes to change something about $PATH for fish, you should do what is described here. That's what this issue is about.

If you, as a user, wish to change $PATH persistently, you can use $fish_user_paths - that's what #527 is about.

[alper]

I think I would like a fish command that anybody could call to add something to the PATH permanently.

[ridiculousfish]

There is fish_add_path in the next release.