I'm having an old Linux enviroment here which I currently start to move to a new Linux Server.
In the old enviroment, I found inside ~/.profile that the current working directory is being exported to PATH:
export PATH=$PATH:.
What might be the reason that the old administrator has put this inside ~/.profile? Because this only safes two characters when trying to execute a program inside the current working directory, doesn't it? (for example: ./foobar vs. foobar)
Related
In RubyMine, I have a project with many subfolders, each of which contains:
One or more standalone single-file executable Ruby programs (.rb files);
An input text file.
In older versions of RubyMine, when running one of the standalone executable programs (via Cmd+Shift+R on my Mac), the default folder in which RubyMine would look for the input file would be the same directory as the .rb file currently being executed -- which worked great.
The code used to read the file is something like:
data = File.readlines('input.txt')
However, after recently updating RubyMine to v2022.3.1, the behavior has changed, such that RubyMines now seems to be looking in the project's root directory for the file, instead of the same subdirectory as the .rb file currently being run. This produces the error:
in `readlines': No such file or directory # rb_sysopen - input.txt (Errno::ENOENT)
To correct this, I've been going into Run (menu) > Edit Configurations; and in the Edit Configurations dialog, in the configuration that RubyMine auto-created for the current executable file, changing the Working Directory value from the default of the project's root directory, to the subfolder of the current .rb file.
However, this above workaround is annoying, since I need to do it once each for every individual one of the many individual .rb executable files in my project.
My question: How can I configure my project and/or RubyMine itself to go back to the older behavior of defaulting a given .rb file to use its own directory as the default Working Directory, instead of the project's root directory?
(This question and/or its solution might also apply to other JetBrains IDEs such as IntelliJ, since they all seem to work similarly.)
The previous behaviour has been changed with https://youtrack.jetbrains.com/issue/RUBY-29236. So now yes, the logic is the following:
in case of no Ruby module, project's root will be used
in case of Rails, its home folder
otherwise the module's root
There is no option to change it in RubyMine but you can configure the configuration template using some variable there as Working directory.
I use linux. I'm working on a project where an app I wrote is launched by my runlauncher. At that time the app looks for an environment variable on the sytem. This environment variable contains a path to a text json file. I want to put this file somewhere on the sytem, not in the home directory. Where would be the appropriate place?
The environment variable is GOOGLE_APPLICATION_CREDENTIALS. The app is a flatpak app.
TLDR: Where do I put things on the system that I can read from my application that are not in the home directory?
On Linux, you need super-user rights (or sudo) if you want to write file outside $HOME directory. If you have only user right, then only $HOME directory is writable.
I'm new to WSL and Linux, but I'm trying to follow installation instructions for rhasspy (https://rhasspy.readthedocs.io/en/latest/installation/#windows-subsystem-for-linux-wsl). I have run the make install command successfully and the next step says I should copy rhasspy somewhere in my path but I can't quite figure out what copying to path means.
When installation is finished, copy rhasspy.sh somewhere in your PATH and rename it to rhasspy.
I added it to path but nothing changed so I was wondering if there is something I'm doing wrong. Right now when I run rhasspy on wsl it says rhasspy.sh: command not found. Any help would be really appreciated!
What it says is, put it in some place where the system will look for it when you type its name without full path in the shell.
There is an environment variable PATH that contains all those locations, separated by a :. (Check out echo $PATH.)
So, the author of these instructions leaves it up to you whether...
You want to copy the file to a location of your choice that is already in the PATH, such as /usr/local/bin or ~/bin.
Usually ~/bin is a good choice because it is per-user and doesn't pollute the system.
(Note that the directory ~/bin is added to the PATH by your .profile file only if it exists, so if you don't have this directory yet and create it now, you need to start a new login shell or run . ~/.profile1 before you can use it.)
- OR -
You want to create a new directory specifically for this application (say for example ~/opt/rhasspy) and append that directory to the PATH variable.
This can be done by adding the line export PATH=$PATH:~/opt/rhasspy to your ~/.profile file. Then, start a new login shell or reload the file using . ~/.profile1 for the changes to take effect.
If the directory in which this file is currently located is OK for you to keep permanently, then you can also just add that directory to the PATH instead of creating a new one.
Note: The PATH always contains directory paths in which the shell will look for executable files. It does not contain the actual file paths!
1: Yes, technically it is "cleaner" to log into a new shell or to run that one export statement manually instead of using . ~/.profile because the latter will apply things a second time that were already done before, so for example it can end up with the same directory in the PATH multiple times in the current session. In most cases that is fine though.
PATH is an environment variable. When you launch env, you see the list of known environment variables on your system.
In order to add something to your PATH variable, you need to take the variable, add the mentioned directory (preceeded by a semi-colon, most probably, as a separator) and store this again as the PATH variable. This can be done as follows (own example):
export PATH=$PATH:/home/this_user
the "PATH" it is referring to in linux is just inside the folder called /usr/bin. when you type a command into the terminal it looks for a program with that name inside the location. im not sure if this is the PATH you are looking for but hope it helps
I am quite new to Linux so I'm sorry for my newbie question,
but for about and hour now I'm trying to add Node.js to $PATH with no luck :(
I've used the following line to add Node
PATH=$PATH:node-v0.10.24-linux-arm-armv6j-vfp-hard/bin
it worked, but when I logged off the terminal and logged in again, the path disappeared.
Later I tried adding the same line to .profile , .logins.defs and .bashrc.
All didn't work so I removed the line.
Please help me with this!
P.S , when I added the line to .profile I was able to call Node, but when I changed my directory in order to navigate to a Node project directory, I received the following error:
-bash: node-v0.10.24-linux-arm-armv6j-vfp-hard/bin/node: No such file or directory
You should add an absolute path, not a relative one. You added this to your path: node-v0.10.24-linux-arm-armv6j-vfp-hard/bin. That's a relative path, not an absolute one (absolute paths start with a /). You can change your line to:
PATH=$PATH:DIR/node-v0.10.24-linux-arm-armv6j-vfp-hard/bin
where DIR is the full path of the directory containing node-v0.10.24-linux-arm-armv6j-vfp-hard.
It's probably a good idea for you to read a bit on how this all works - it's not that complicated once you see it explained. See https://superuser.com/questions/238987/how-does-unix-search-for-executable-files for an example.
You have $HOME already set to your home directory.
So you can use this in your .profile:
PATH="$PATH:$HOME:$HOME/bin:$HOME/node-v0.10.24-linux-arm-armv6j-vfp-hard/bin"
If you set it as an absolute path you will not be able to copy that .profile to another user who is set up similarly.
I see there is another question that deals with installing node.js on Debian - and must admit I am surprised it is installed per-user. So if you do the install for another login you might want to copy your .profile to the new login to solve this same issue. There would be no per-user editing required if you use the $HOME variable like this. Just a simple copy or cut and paste.
For reference, here is that other question/answer: install node.js on debian
I have recently installed a webframework play (http://www.playframework.com/) and want to have the play executable in the system path ie $PATH. But ubuntu already defines a command called play. How do I overwrite the system defined command with my framework binary path so that command play on commandline calls my framework rather than the old application.
Installation: I downloaded zipped file of the framework and upzipped in one of my personal folder which contains the docs and the executable.
Never alter the contents of installed packages. Such changes can provoke hard to find problems in the system and anyway, they will most likely be overwritten again in subsequent updates. There are other alternatives:
obviously you can chose another name for your executable
place the executable in another part of your $PATH if its a "personal installation", typically ~/bin is used for such approach. Remember that the order of entries in the $PATH variable is important, first come first serve.
use the traditional /usr/local/bin location for locally added "wild" installations, this way there is some form of clean separation between clean packages and wild installed files inside the system
store your software in some other location and prepend that to your personal or system wide $PATH variable
store your executable under another name and create an alias (see man alias for an explanation) for it which allows to call it by some name that "hides" the original command this way. For this the executable can be addressed with an absolute path, so it dies not have to be found inside the $PATH variable.
In my personal opinion options 2. and 5. and the best if it comes to "personal installations".
If you are sure you'll never use the original play command, you could just remove the binary. But in general, this isn't a good idea, since some system component you don't think of might need it, and the next update will probably restore it.
The best thing to do is to prepend the directory of your play command to the PATH, for example, using PATH=/opt/framework/bin:$PATH in your .profile (assuming your play command installs to /opt/framework/bin/play), or the script that starts your web server, or wherever you need your play command.
Remember that does not make your play command global. A common mistake is to add the path in their .profile file, then call the program from crontab - crontab scripts will not execute .profile or .bashrc.