Missing environment variable __VFOX_PID when using fish

[jan-bar]

          I just got this one more time

switching to existing tmux panes (shell sessions) did not change anything. but creating a new pane helped. and node in /Users/vv/.version-fox/temp/1727128800-4412/ folder has been resurrected

ps: can a suspend process influence this somehow?

Originally posted by @ZuBB in #283 (comment)

[jan-bar]

I don't usually use fish. I use the following go code and shell command to test that the go code cannot read the environment variable __VFOX_PID

Affected Code:

vfox/internal/shell/fish.go

Line 35 in be6910b

set __VFOX_PID %self;

I use set -x __VFOX_PID %self; and the go code can successfully read the environment variable

@ZuBB Could you test your problem using the modified code?

I installed the fish version using apt install -y fish: fish, version 3.6.0

[ZuBB]

@jan-bar JFYI I will try to take a look at this on Wed

[ZuBB]

@jan-bar if I got you right -x flag does the trick

but I still do not understand the issue and how -x flag is supposed to help. How is it possible that vfox suddenly stops working in the existing shell, and after the creation of a new/additional shell, the existing one starts to work again?

is it possible that 2 addons (lets say js + python) can interfere each other? I have JS turned on globally and sometimes I enable python in particular shell

[jan-bar]

vfox/internal/env/flag.go

Lines 17 to 39 in be6910b

	package env
	import (
	"os"
	"strconv"
	)
	const (
	HookFlag = "__VFOX_SHELL"
	PidFlag = "__VFOX_PID"
	)
	func IsHookEnv() bool {
	return os.Getenv(HookFlag) != ""
	}
	func GetPid() int {
	if pid := os.Getenv(PidFlag); pid != "" {
	p, _ := strconv.Atoi(pid) // Convert pid from string to int
	return p
	}
	return os.Getppid()
	}

Because the current terminal does not have a "__VFOX_PID" environment variable, vfox will fall back to using os.Getppid(). Since all your terminals have the same parent process, all your terminals actually use the same temporary directory environment.

[ZuBB]

This explains why the existing tab started to work again after creating a new one. But it does not explain why the existing tab stopped working

[jan-bar]

vfox/internal/shell/fish.go

Lines 59 to 62 in be6910b

	function cleanup_on_exit --on-process-exit %self
	"{{.SelfPath}}" env --cleanup
	end;

You may have closed a terminal over the past day, triggering a cleanup task. Since all your terminals share the temporary directory, the terminal that was not closed the previous day will be unavailable. At this time, when you open a new terminal, a new temporary directory will be created, and all other terminals will immediately reuse the environment.

[ZuBB]

That makes some sense. Thank you for your time

[ZuBB]

I have got one more issue, that might be related to this.

STR

• Open the new tmux tab;
• Set Node.js runtime to something else except default in this shell (-s);
• Do some Node.js stuff (node -v);
• Create a new tmux tab;
• Do some Node.js stuff (node -v). the default version of the runtime should be used;
• Move back to the (1st) "new" tab;
• Check node version. the version we used to set "disappear", the default one is used 😞

env is the same as in the original bug report.

PS: can you repro this bug with the fix you did here?

[jan-bar]

@ZuBB use go install github.com/version-fox/vfox@ca4d9e6 Installed version test
Is the __VFOX_PID environment variable still missing?

[ZuBB]

I installed that version and it did not help. __VFOX_PID is present

[ZuBB]

a bit better screen that may give you some additional hints

[ZuBB]

Hey, @jan-bar, can we have a new minor release with this fix? In my latest project (I ought to run it under WSL), I am getting this bug every 2 days

wrong place for this comment

[ZuBB]

@jan-bar I am sorry to bother you again on this one, but it seems like even your fix (v0.6.1-pre is a build I got by you advice) does not work

[jan-bar]

@ZuBB

There must be something wrong with your configuration. The last number in the temporary directory is not the value of the __VFOX_PID environment variable.

Below is the latest code I compiled manually, as well as the configuration of tmux and fish

Then execute tmux to start two terminals. As shown in the figure, each terminal has its own correct environment variables.

[ZuBB]

@jan-bar I am trying to find out what is wrong here. I hope you agree that two options are possible (or at least 2)

• there is some issue with either the configuration or with another software (fish shell, tmux, kitty?) at my side;
• still, there is some issue with vfox.

The case you describe is perfectly valid, but it is very basic. I am pretty sure I can replicate it on my laptop.

My workflow is slightly more complicated. I am working on a couple of projects at the same time. "working" here means that I open a new kitty window for each project. If a project requires a few shells, I start tmux within that kitty window/instance of fish shell and create as many tabs (full-size panes) as I need. When I need to switch to another project, I do "detach" in terms of tmux and close kitty's window and start over (either new kitty+new tmux or new kitty + tmux attach). In these cases, fish shells may live quite a long life.

Now, we need to think about which reason could lead to a situation when PID and CURTMPPATH may use different IDs. How can we exclude any of the options I mentioned at the start?

PS: after we discovered #375, I have only one version of node installed by vfox.

BTW, as far as I remember, when this happens, vfox loses track of which version of the node is currently active. I will try to get a proof of that next time it happens

[ZuBB]

Can I set up some hook at my side to catch a moment when ID in PID and CURTMPPATH starts to differ? if so any advice on that? maybe it will help me understand what my action leads to that

edit: I think I can set up that hook myself

[jan-bar]

@ZuBB I don't have such a complicated environment. I suggest you remove some programs for testing. For example, remove fish and use bash instead, remove tmux and use fish directly. I usually only use the bash that comes with the system, so I don't encounter such a complicated problem as yours.