[fish] make init hook recursion fish compatible

[mikeland73]

Summary

Hopefully this fix all the fish compatibility issues that were introduced with the init hook recursion protection. The strategy in this PR is:

• Wrap init hooks with POSIX and fish compatible wrapper. (no unset used, only export and dot source)
• Wrap scripts in POSIX compatible wrapper (but not fish).
• The script wrapper will only source init hooks once. The first time it sources it, the init hook wrapper sets an env var and proceeds to run the hook. If any command in the init hook is a devbox script, it will not call init hooks recursively because the env var is set. Once the init hook is done, it uses export to make the var empty. (export is compatible with POSIX and fish, unset is not)
• The script wrapper is not fish compatible, but that's OK because scripts are always run with sh. (I think it may be easy to make the script fish compatible by using `test if we ever decide to support that).

How was it tested?

• added devbox run calls to init hook
• Shelled in (with zsh and fish)
• Ran scripts
• Tested sourcing devbox shellenv --init-hook (with zsh and fish)

[adamdicarlo0]

Wrap init hooks with POSIX and fish compatible wrapper. (no unset used, only export and dot source)

This is not a blocker at all (just a long-term FYI); the fish docs say:

. (a single period) is an alias for the source command. The use of . is deprecated in favour of source, and . will be removed in a future version of fish.

https://fishshell.com/docs/current/cmds/source.html#:~:text=The%20use%20of%20.%20is%20deprecated%20in%20favour%20of%20source%2C%20and%20.%20will%20be%20removed%20in%20a%20future%20version%20of%20fish.

[mikeland73]

@adamdicarlo0 thanks for heads up!

If fish removes . source notation, it's gonna break more than just this. (We chose . over source because it is technically more portable)

Longer term, I think a good solution is to avoid sourcing all-together if possible, and figuring out a better way to export variables from a hook. If we don't source hooks, it becomes easier to do write cross-shell, shell-agnostic devbox projects (e.g. write your hooks in fish, but ensure they work for folks using bash). Currently this is not possible without third party tools.

I've been playing around with some hook ideas to replace our current init_hook. Trying my best to avoid sourcing and instead just running them on the user's choice of shell.

[savil]

LGTM

[sentry-io]

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

• ‼️ **syscall.Errno: error running script in Devbox: <redacted errors.withStack>: <redacted errors... go.jetpack.io/devbox/internal/shellgen in creat... View Issue

_{Did you find this useful? React with a 👍 or 👎}