Gal Schlezinger

It is not, as the multishell is an ephemeral resource (a shell session-specific symlink)

There's no way to provide that. But we might have a way in the near future.

I should have changed the name of the feature. It is not `XDG_DATA_HOME`, but the standard data locations for each OS. `~/Library/Application Support/fnm` seems to be the standard per https://docs.rs/dirs/latest/dirs/fn.data_dir.html...

> It seems that I cannot reopen the issue on my own. didn't know that. sorry. I understand your frustration, but I also agree with https://github.com/dirs-dev/directories-rs/issues/47#issuecomment-478337412 that being said, maybe...

it's worth to mention that I do not like to use `~/Library/` stuff in a CLI too. I share the sentiment.

I will try to take a look at that. I agree that Application Data is not a good idea. That still sounds odd that it fails though. Since we introduced...

I think it’s fairly finished. I’ll take another look and will release it on the next version. The only problem is node-build not supporting spaces in the installation path

New MacOS version removes `python@2` so build scripts fail. I think that the best solution is to have a precompiled repo: that would be both fast and easy to install.

It's enough for basic usage. But if we want `--use-on-cd` we might want to add functions or whatever it is called in nushell. I really want to try nushell again...

hey there. There is no good solution unfortunately. 1. these are not directories but symlinks. They don't really harm your computer but feel free to remove them: `rm $(dirname $FNM_MULTISHELL_PATH)/*`...