Fix reading of /etc/paths on OS X

[akalin]

(and /etc/paths.d/*)

Do so by emulating the behavior of /usr/libexec/path_helper for login shells,
matching the behavior in /etc/profile.

Also add a path_helper command to reproduce the behavior of
/usr/libexec/path_helper for fish.

This also handles setting MANPATH if necessary.

Fixes issue #4336

TODOs:

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

[akalin]

This is the follow-up promised in #4337 (comment) .

[akalin]

I couldn't find a built-in way to quote a string. Thought string escape would do it, but it does something different.

[faho]

string escape will do what you want - escape a string so that it'll pass through source unharmed. It just doesn't always use single-quotes. Instead it falls back to using \\ for more complicated things.

However, I'm not quite sure why this path_helper function exists at all - you're not using it anywhere as far as I can see, and since it would run in the fish process, there's no need to output the set statements - instead, you could just directly run them. Which would also remove the need for quoting.

[akalin]

It's just a driver for debugging the path_helper logic without having to start shells and examine environment variables. I can remove it if needed.

[faho]

Yes, please! This looks like something to invoke, and it really shouldn't be.

[akalin]

Done! Please take another look.

[akalin]

Not exactly sure why I need to triple-escape the \ in \\\\\\\\$1; need to escape once because it's in a single-quoted string, another because it's a replacement string for a regexp, but I can't think of a reason for a third escape.

[akalin]

Pinging original main reviewer @krader1961.

[akalin]

Hmm, not sure why invocation/login-interactive.invoke is failing. Seems to fail on master for me, so might be unrelated. Never mind, should be fixed now.

[zanchey]

@ridiculousfish is probably the best reviewer here.

[ridiculousfish]

Thanks for doing this!

Can you please catch me up on the rationale? /usr/libexec/path_helper is meant to be consumed by shells, not exported by them, so I don't understand why we would want to implement it in fish?

[akalin]

Sure thing! My previous PR #4337 took the approach of parsing path_helper's output. However, that turned out to be more complicated and brittle, for a few reasons:

• path_helper prints out lines meant to be evaluated in csh or sh. So fish would have to parse those lines, which is more complicated than just reading the same files that path_helper does. Someone did suggest just eval'ing the csh output, but that's just scary.
• path_helper tries to escape its output, but does so half-heartedly (in particular, it doesn't handle spaces). So we'd have to unescape that output, which makes it more complicated than just parsing the files.
• By implementing the logic in fish, we avoid a fork.

If you compare this PR to #4337 , this one does seem simpler to understand. The danger of our behavior diverging from path_helper is minimal, since path_helper has barely changed since it was first implemented.

However, if you prefer the other approach, I could always resurrect #4337 .

[faho]

Note: This entire for-loop could also be replaced with set -xg $argv[1] $result - then the outer set becomes unnecessary.

[akalin]

Thanks, done!

[faho]

This looks quite nice to me.

Unfortunately, I can't really test it, so I'll leave that up to @ridiculousfish!

[ridiculousfish]

@akalin thanks for the explanation. I'm on board with emulating path_helper, but I don't understand the reason behind the second change, the "add a path_helper command to reproduce the behavior of
/usr/libexec/path_helper for fish". Who will call this function?

[akalin]

@ridiculousfish Per @faho's suggestion, I removed the path_helper function; I had it around only for debugging. Please take another look!

[ridiculousfish]

Looks good. Squash-merged as adbaddf. Thanks!!

[zanchey]

Note that this changes the behaviour from running for all shells to running for login shells only. This matches the behaviour for other shells but breaks sessions run using iTerm2's "run command" option, for example.

[akalin]

@zanchey how do people using other shells solve the problem? Perhaps we could expose a function for people to call (that does what this PR does for a login shell) if they want that behavior?

[ridiculousfish]

Nice spotting @zanchey, I switched it back to running for all shells in c0f832a.

[akalin]

Hi, just to be clear, I made it login-shell-only to match the behavior of sh/bash (since the call to path_helper is in /etc/profile). So it's intended that fish deviate from that and read the paths for every shell?

[ridiculousfish]

Nothing is really intended. I reverted that because it looked like an undocumented behavior change, and zanchey observed that it broke a use case ("Run Command" in iTerm2).

Nobody has made a case for what the right behavior should be, so it's better to not break any users who might be depending on the existing behavior.