"Are you sure you want to proceed?" after installation and login into desktop
After installing Fnm and restarting my computer I get a dialog box like this:

OS: Pop OS 19.10 Shell: Bash
after checking my .profile it turns out it's sourcing the bashrc file here:
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
at the bottom of .bashrc I have:
export PATH='"$INSTALL_DIR"':$PATH
eval "`fnm env --multi`"
However, there seems to be some error output that according to this: https://askubuntu.com/questions/587868/are-you-sure-you-want-to-proceed-message-on-login
it is causing the dialog.
I was able to fix this by using the following command:
eval "$(fnm env --multi 2>& /dev/null)"
Hopefully this helps someone else running into the same issue.
Thanks
Does your $INSTALL_DIR have a value, such as in fnm's installation script?
https://github.com/Schniz/fnm/blob/2ec304504600f5e82c34db24c48ae3f79f15de9e/.ci/install.sh#L5
sorry, I copied the wrong thing.
it does:
export PATH=/home/adan/.fnm:$PATH
eval "$(fnm env --multi 2> /dev/null)"
Interesting. What does fnm env --multi 1> /dev/null prints?
@Schniz nothing that's printable. which is weird
I would consider this a minor issue since the workaround solves my issue
I have the exact same issue with the "Are you sure you want to proceed" dialog, also with Pop!OS:
$ uname -a
Linux pop-os 5.11.0-7614-generic #15~1618626693~20.10~ecb25cd-Ubuntu SMP Thu Apr 22 16:00:45 UTC x86_64 x86_64 x86_64 GNU/Linux
The workaround
eval "$(fnm env --multi 2> /dev/null)"
also fixes it for me.
Do you know why? I don't use PopOS
I tried everything I could think of, and like OP I couldn't figure out why this is occurring. Under no circumstances could I make eval "$(fnm env)" produce any output which is apparently what the askubuntu (and other various StackOverflow) questions said were the cause. I just glad to have found a workaround because it was extremely annoying. My "Are you sure you want to proceed" dialog was raised by X11, not even gdm which hadn't even started yet; and often, the mouse cursor wouldn't show so I couldn't even click the "ok" button.
I guess it's worth pointing out that Pop!OS by default uses Xorg not Wayland. This might be why few people have seen this issue.
I ran into the same issue on Ubuntu 21.04. The workaround resolved the issue for me.
I would consider this a minor issue since the workaround solves my issue
Not being able to boot into desktop isn't really a minor issue. Even when a workaround exists. @Schniz Maybe this workaround can be documented somewhere in the README?
hmm, feel free to open a PR. I am not sure I understand the issue ๐ @Barabazs
Please reopen. The issue is still there and the workaround works.
Pop!_OS 21.04
- eval "$(fnm env)"
+ eval "$(fnm env 2> /dev/null)"
Hi! sure, I will reopen.
Can you please explain what can we do so we wouldn't have the 2> /dev/null? I don't think we're emitting anything via stderr. And AFAIK file descriptor 2 (stderr) should not affect eval, like: eval $(echo "HI" 1> &2).
Maybe there's something I'm missing? I would like to avoid telling people to 2> /dev/null, and if you can help out and identify what is the difference, I will be glad. I'm not a PopOS user myself, so this is baffling to me.
Maybe we can even try with something like `eval "$(echo 'export HI=ho')"
Hi, @Schniz, I piped errors output into a file, so this is the error that's getting raised. Any redirection of 2> silences the error. I'm on Ubuntu 22.04 by the way. Also note this only works when fnm env ... is in .bashrc, even though my root and local users are using zsh.
error: process ID out of range
Usage:
ps [options]
Try 'ps --help <simple|list|output|threads|misc|all>'
or 'ps --help <s|l|o|t|m|a>'
for additional help text.
For more details see ps(1).
error: Can't infer shell!
fnm can't infer your shell based on the process tree.
Maybe it is unsupported? we support the following shells:
* bash
* zsh
* fish
* powershell
@dhvcc can you try not to infer your shell? fnm env --shell=bash :)
@Schniz I can confirm it works that way. Should the README add this argument for .bashrc setup (I guess https://github.com/Schniz/fnm/blob/e49bd1f4077ee02695c4a9da451321d9191dec76/.ci/install.sh#L189 also)?
If it will be useful to anyone, I had this issue on Ubuntu 20.04(newly installed), and putting eval "$(fnm env --multi 2>& /dev/null)" into .bashrc fixed it(however using zsh as a primary shell).
Itโs be extremely helpful if someone can find the root cause of the issue instead of talking about workarounds. I stopped using Linux for desktop years ago and canโt really reproduce.
A set of fnm stickers will be sent to they who solve this issue! (And once I learn how the post office works..)
~~I was previously on v1.26.0 and solved my problem (similar to the OP) by deleting $HOME/.fnm removing the extra lines from .bashrc and then updating to the latest version (1.32.0).~~
EDIT: After a reboot, I'm getting the error again...