Open ryanccn opened 2 years ago
@Schniz
hey there. There is no good solution unfortunately.
rm $(dirname $FNM_MULTISHELL_PATH)/*
fnm env --pid=$$
but we don't.du $(dirname $FNM_MULTISHELL_PATH)
return 0 bytes, so I am not concerned about it. should I?Maybe this is useful: https://stackoverflow.com/questions/18221348/exit-hook-working-both-on-bash-and-zsh
Thanks for this!!!
Hello~ I don't know why fnm needs to create multishells symlinks. Even if you enter the same path again, it still creates a new and different symlinks. I don't understand why it was designed this way.
Hello~ I don't know why fnm needs to create multishells symlinks. Even if you enter the same path again, it still creates a new and different symlinks. I don't understand why it was designed this way.
@fengyinxu It's because each shell instance can be using its own version of Node.js, so each multishell symlink is specific to one shell instance.
Hello~ I don't know why fnm needs to create multishells symlinks. Even if you enter the same path again, it still creates a new and different symlinks. I don't understand why it was designed this way.
@fengyinxu It's because each shell instance can be using its own version of Node.js, so each multishell symlink is specific to one shell instance.
Typically, what we need is a different version of Nodejs for each project, not each shell instance. I'm not familiar with rust. I'm curious as to why fnm designed it this way (cache, multishells) What is the need for this design. I see there is a PR #865 associated with the issue, but it's a pity that the PR has not been merged now.
@fengyinxu Commands like fnm use
change the node version the shell is using; even .node-version
and engines.node
support set the node version in the shell where you cd
ed into the project.
Is there a reason for not creating these symlinks in $TMPDIR
? 🤔
For fish shell user:
function fnm_clean_up --on-event fish_exit
rm -r $FNM_MULTISHELL_PATH
end
the problem with using hooks is that almost no one exits their shell cleanly, so that hook will not be called. Maybe fish works better than what I tested?
Is there a reason for not creating these symlinks in $TMPDIR? 🤔 @MunifTanjim
sorry for replying after more than 1 year. fnm multishells used to be in TMPDIR. Unfortunately, a MacOS change in behavior of tmpdirs made them clean up on hibernation instead of reboot. we had bug reports in this regard, which the new multishell directory fixed. I didn't find any literature about this change but changing the directory fixed it for good, so we left it like that.
I think it's a good tradeoff to have: symlinks are mostly 0-sized and fast, and working software is better than broken software
Is there a way to add a cleanup command? Maybe add the pid
of the shell as a prefix for FNM_MULTISHELL_PATH
file. And the cleanup command can remove the file if the process for that pid
is not running anymore?
Or maybe just add the pid
prefix part, and no need to add the command. People who wants to cleanup can write their own script?
the problem with pid is that it isn't a shell command but an executable, so I need to use ppid
for the parent id, but that doesn't cut it either, because what if you have a "setup script" that calls fnm for your shell?
# my .zshrc
eval "$(~/.config/setup-fnm)"
# ~/setup
fnm env --use-on-cd
then we need to traverse the process tree to understand what's the closest shell
however we can do fnm env --pid $PID
as an optional argument which will tell "This is the current shell". again it will be problematic when it is composed in another script, but might help cleaning up stuff if necessary
I don't think there's a good and easy solution here. do you have something in mind?
tldr the main concern is that using PID might hurt composition
It would be great if
fnm
supported cleaning up the cache directory. Currently, I have 2398 directories in the cache directory, and I think that having a command (which maybe runs periodically when you run anyfnm
command?)that removes everything in that directory is better than having to do so manually while the folders build up.