Score:0

Ubuntu

node: not found & found depends of run method

Sonaht

10/20/23, 1:13 PM

I'm not looking for solution (ok, it would be handy too) but mostly for explanation why it works that way in Linux.

OS: Ubuntu 22.04.1 (ubuntu-22.04.1-desktop-amd64.iso)
Node.js: installed through NVM, v16.18.0

I have simple shell script:

test.sh

node --eval "console.log(123)"
sleep 2

and if I run it through terminal that way:

Click mouse right button on background in script directory in Nautilius or Nemo
Click on open terminal here
We are in terminal in folder of shell script. Now type command ./test.sh and hit enter

then everything works fine, node is called, we see 123 as output and after 2 seconds shell script is finished because of sleep command after node calling.

The most surprising part (for me I guess) is when I'd like to run that shell script directly from FileManager (system default Nautilius or installed Nemo) that way:

click right on test.sh file and click on Run as a Program

The result of it is terminal shows up with error in it: "node: not found" and after 2 seconds it closes because of sleep command.

Why there is a difference? In first try, terminal sees node.js, in second try terminal doesn't see it. And besides, how to fix it?

EDIT:

I've found some, I've installed NVM through terminal before along with one of node.js version. But now I've additionally installed Node.js through GUI (Ubuntu Software) and now both ways works. Why?

Why installing something in terminal doesn't make it work in both cases?

371

1 + 1

bash

scripts

filemanager

Esther

10/20/23, 2:40 PM

possibly it is a PATH issue, not sure what environment the "run as a program" option uses.

Score:2

Ubuntu

Esther

10/20/23, 2:47 PM

The problem is that Node installed via NVM does not appear in the PATH environment variable used by the desktop environment, but only by the PATH used by terminal processes (that source your .bashrc or similar).

This is why the terminal processes can find node just fine, but Right-click + "Run as a Program" does not work: the "Run as a Program" option just inherits the environment from your DE, and does not source your ~/.bashrc itself.

For more details about how this works, see this Unix & Linux answer. Evidently, the way Ubuntu Software installs Node, it does appear in the PATH variable that the DE uses.

The linked answer also provides for a way to set environment variables for the entire X session, so that they will be available to programs run using "Run as a Program" (put them in ~/.xsession, or in a separate file with environment variables that you source from both ~/.xsession and ~/.bashrc).

+ 16

Sonaht

10/20/23, 4:07 PM

Is it possible somehow to unify it automatically?

Esther

10/20/23, 4:08 PM

"unify" what? If you want the computer to do something, you have to tell it to do the thing.

Sonaht

10/20/23, 4:09 PM

Yes. Ideally it would be great to have a software/addon for ubuntu or for any other Linux, that would merge user paths with de paths always.

Esther

10/20/23, 4:10 PM

@Sonaht that's not always what you want. If it *is* what you want, put the PATH definition in a file, and source that file from both .bashrc and .xsession (and then when you modify PATH, it gets modified in both at the same time).

Sonaht

10/20/23, 4:13 PM

Yes, that is the way. But then that File has to be filled up manually each time I guess?

Esther

10/20/23, 4:16 PM

Instead of changing your PATH in .bashrc, you change it in that file. No difference. You can see what PATH is getting used by "Run as a Program" by making a .sh file with just `echo $PATH; sleep 2` inside, and running it using "Run as a Program". Compare the result with `echo $PATH` in a regular terminal.

Sonaht

10/20/23, 4:17 PM

But most operations like installing NVM does it by itself and there is no way to instruct it to change/write to my file instead of to .bashrc. So most things has to be done manually then - instead you know, just install things like in Windows OS.

Esther

10/20/23, 4:19 PM

you should only have to do it once. Check what is different about the PATH in terminal, and when you use "Run as a Program"

Sonaht

10/20/23, 5:37 PM

I've put some code to freshly created `.xsession` file at my home, but it wont work. It has "allow execute" makred on. Code: `PATH="$HOME/.nvm/versions/node/v16.18.0/bin:$PATH"` and it is right besides `.bashrc` and `.profile`

Esther

10/20/23, 5:38 PM

log out and back in again, .xsession only gets sourced when you log in

Sonaht

10/20/23, 5:41 PM

Yes i did it several times, even rebooting whole machine. I've changed from `.xsession` to `.xsessionrc` too, but no luck..

Esther

10/20/23, 5:44 PM

did you check what's different about PATH in a terminal and when you click "Run as a Program" (like I said in earlier comments)? if there's no difference, compare output of `printenv` in a regular terminal and in "Run as a Program" (might need to output to a file since it's long) and see what's different about the environments. Also which version of Ubuntu are you using? If 22.04 or 22.10, you will be using Wayland rather than Xorg by default, so .xsession won't work for you

Sonaht

10/20/23, 5:48 PM

Ubuntu 22.04.01. The difference between PATH in both cases was `/home/myuser/.nvm/versions/node/v16.18.0/bin`

Esther

10/20/23, 5:50 PM

sorry, it should be .xsession*rc*, rename the file, log out and in again and it should work now

Sonaht

10/20/23, 5:53 PM

still no luck, I have .xsessionrc file allowed to be executed, with content `PATH="$HOME/.nvm/versions/node/v16.18.0/bin:$PATH"`, but after log out/log in procedure still shell script shows "node: not found" in DE case. If it's Ubuntu 22.04.01, does .xsessionrc should works?

Sonaht

10/20/23, 6:03 PM

I've found that if I put that line `PATH="/home/myuser/.nvm/versions/node/v16.18.0/bin:$PATH"` at the begining of my shell script `test.sh` then the same script sees node easly in DE case. But it's not the way..

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: node: not found & found depends of run method

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.