The warning it gives me is this:
WARNING: The scripts f2py, f2py3 and f2py3.10 are installed in '/home/minombre/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
How do I fix this?
Or can I just leave it like that?
even though I would like to fix it.
I am using for the first time linux ubuntu.
The warning message you are seeing is telling you that the scripts 'f2py', 'f2py3', and 'f2py3.10' are installed in the directory '/home/minombre/.local/bin', but this directory is not on your system's PATH. The PATH is a list of directories that your system looks in when you run a command. When you run a command, your system looks in the directories listed in the PATH for a file with that name.
You have a few options to solve this:
Add the directory '/home/minombre/.local/bin' to your system's PATH. This will allow your system to find the scripts when you run them. You can do this by editing the '.bashrc' file in your home directory and adding the following line at the end of the file:
export PATH=$PATH:/home/minombre/.local/bin
Use the full path to the script when you run it. Instead of just
running f2py, for example, you would run
'/home/minombre/.local/bin/f2py'
Use the '--no-warn-script-location' flag when you install the package.
This will suppress the warning message but it will not add the
directory to your PATH.
pip install opencv-python --no-warn-script-location
It's important to note that if you are not going to use the scripts that are giving the warning, you can safely ignore the warning.
It is also important to mention that you can also check your PATH by running in the terminal:
echo $PATH
and it will show you the list of directories.
Related
I have a kinda weird problem. I'm currently messing around with the VRX-Simulator, which simulates an unmanned-watersurface-vehicle.
For the installation I followed the guide on https://bitbucket.org/osrf/vrx/wiki/tutorials/SystemSetupInstall.
Then I tried to modify some of the files and tried to rebuild the project.
This was the point when I noticed it always used the "old" version of my simulation within gazebo.
From now on no matter what I did (I even deleted the whole catkin workspace folder) ROS somehow managed to always launch the original version of my simulation even without any build/src folder existing when I used roslaunch.
roslaunch vrx_gazebo sandisland.launch
So my question would be how can I get rid of my simulation/model and where does ros/gazebo cache my simulation?
You most probably installed the package with the command from the tutorial sudo apt install ros-melodic-vrx-gazebo. So the package launched with roslaunch vrx_gazebo sandisland.launch was not in your catkin workspace. If you want to get rid of it you can uninstall it with sudo apt remove ros-melodic-vrx-gazebo. But this is not strictly necessary.
There are several ways to find out where some ros package is located, try running some of these commands:
rospack find vrx_gazebo will show you where the package used is located
roscd vrx_gazebo will take you to the folder where it is installed something like
/opt/ros/melodic/share/vrx_gazebo
If you also followed the tutorials installing from source code then the issue most likely was not sourcing the built packages. The last line of the guide is a bit misleading. The line *Remember to run this command every time you open a new terminal. is meant to reference the command source ~/vrx_ws/devel/setup.bash
Whether the installed package or the package built from source is used depends on which order they are listed in the environment variable ROS_PACKAGE_PATH. This variable is modified by both source /opt/ros/melodic/setup.bash and source ~/vrx_ws/devel/setup.bash. So have a look at the variable after each step with printenv | grep ROS or echo $ROS_PACKAGE_PATH. Theoretically if you source your terminal in the order I had the source commands it should be using the package built from source, you can verify with the rospack find ... and roscd ... commands mentioned earlier.
In the end it is probably easier to add the sourcing commands to your .bashrc file so you would not forget to source the terminals as mentioned in the ROS installation tutorial. You can add the sourcing of the workspace to the the same file, you will just have to be aware that you would need to change the file, should you want to use a different workspace.
http://wiki.ros.org/melodic/Installation/Ubuntu#melodic.2BAC8-Installation.2BAC8-DebEnvironment.Environment_setup
relevant command from the tutorial:
echo "source /opt/ros/melodic/setup.bash" >> ~/.bashrc
you could do the same for the workspace:
echo "source ~/vrx_ws/devel/setup.bash" >> ~/.bashrc
And after running those commands run exec bash to get the changes into the current terminal. All future terminals will have those commands already loaded.
I have cloned and built the waf script using:
./waf-light configure
Then to build my project (provided by Gomspace) I need to add waf and the eclipse.py to my path. So far I haven't found better than this setenv script:
WAFROOT=~/git/waf/
export PYTHONPATH=$WAFROOT/waflib/extras/:$PYTHONPATH
export PATH=~/git/waf/:$PATH
Called with:
source setenv
This is somehow a pretty ugly solution. Is there a more elegant way to install waf?
You don't install waf. The command you found correctly builds waf: /waf-light configure build Then for each project you create, you put the built waf script into that projects root directory. I can't find a reference, but this is the way in which waf:s primary author Thomas Nagy wants the tool to be used. Projects that repackage waf to make the tool installable aren't "officially sanctioned."
There are advantages and disadvantages with non-installation:
Disadvantages:
You have to add the semi-binary 100kb large waf file to your repository.
Because the file contains binary code, people can have legal objections to distributing it.
Advantages:
It doesn't matter if new versions of waf break the old API.
Users don't need to install waf before compiling the project -- having Python on the system is enough.
Fedora (at least Fedora 22) has a yum package for waf, so you could see that it's possible to do a system install of waf, albeit with a hack.
After you run something like python3 ./waf-light configure build, you'll get a file called waf that's actually a Python script with some binary data at the end. If you put it into /usr/bin and run it as non-root, you'll get an error because it fails to create a directory in /usr/bin. If you run it as root, you'll get the new directory and /usr/bin/waf runs normally.
Here's the trick that I learned from examining the find_lib() function in the waf Python script.
Copy the waf to /usr/bin/waf
As root, run /usr/bin/waf. Notice that it creates a directory. You'll see something like /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18
mv that directory to /usr/lib, dropping the . in the directory name, e.g. mv /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18 /usr/lib/waf-2.0.19-b2f63c807a4215294bf6005410c74c18
If you want to use waf with Python3, repeat Steps 2-3 running the Python script /usr/bin/waf under Python3. Under Python3, the directory names will start with .waf3-/waf3- instead instead of .waf-/waf-.
(Optional) Remove the binary data at the end of /usr/bin/waf.
Now, non-root should be able to just use /usr/bin/waf.
That said, here's something to consider, like what another answer said: I believe waf's author intended waf to be embedded in projects so that each project can use its own version of waf without fear that a project will fail to build when there are newer versions of waf. Thus, the one-global-version use case seems to be not officially supported.
I was having some trouble installing the gem libv8. Apparently I need to have python installed. I installed Python and was attempting to update my path with command from another forum:
SET PATH=C:[Ruby Directory]\bin;C:[Python Directory]
or in my case:
SET PATH=C:\Ruby192\bin;C:\Python27
I am not strong with paths and I can't figure out what I did. Now my environment can't find my Ruby directory.
Can someone explain what I did and how I might fix it?
That is most likely because your PATH variable already had a bunch of stuff that you simply throwed away with that line:
echo %PATH%
# a bunch of stuff
SET PATH=C:\Ruby192\bin;C:\Python27
echo %PATH%
# C:\Ruby192\bin;C:\Python27
You can try to append to it instead instead:
set PATH=%PATH%;C:\Ruby192\bin;C:\Python27
echo %PATH%
# a bunch of stuff plus C:\Ruby192\bin;C:\Python27
This change will be avalid for your terminal session only. Closing it and open again should restore the default path. If you need to make it permanent, you need to change your path throught the windows (for example, following this instructions)
In NodeJS/NPM, you can create a package.json and run npm install to install all your dependencies in a folder within your project: ./node_modules. (A project can be an app or another module/package.)
Ruby also has a "bundler" system (using a .bundle file) that keeps track of gems specific to a dir (ie project).
Does LuaRocks have similar conventions? Or is it recommeneded to install everything to /usr or $HOME?
So far I've been able to get similiar functionality, but I have to create a custom LuaRocks config file and specify --tree=my_local_lua_rocks_dir every time I want to install a rock. Granted, I can always create a bash script. The point is that it seems I'm going against a convention.
It is possible to install rocks into a directory under the current directory, using the --tree flag:
luarocks install --tree ./lua_modules lpeg
And then you have to configure your package.path and package.cpath variables in Lua (settable via LUA_PATH and LUA_CPATH environment variables) so it finds the modules installed inside it. There are several ways to do this conveniently: this tutorial explains how to do it, with more examples.
Instead of using Vert, I've decided to just edit the LuaRocks config file:
In /etc/luarocks/config.lua :
rocks_servers = {
[[http://rocks.moonscript.org/]],
[[http://luarocks.org/repositories/rocks]]
}
rocks_trees = {
[[/usr/local]],
[[./my_dir]]
}
./my_dir is relative to the pwd you're in, not to the location of the config file. Of course, change my_dir to whatever you want.
"The order of the rock_trees matters: When installing rocks, LuaRocks tries to pick a location to store the rock starting from the bottom of the list; when loading rocks in runtime, LuaRocks scans from the top of the list." From: http://luarocks.org/en/Config_file_format
Then in your .bashrc:
eval `luarocks path`
export PATH=$PATH:my_dir/bin
However, for certain commands you now have to specify the tree or it will give you a confusing error:
luarocks make --tree=my_dir
I am following the tutorial : http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniexamp.html
when I reach the part where I am supposed to set the library path :
Unix or Linux:
LD_LIBRARY_PATH=`pwd`
export LD_LIBRARY_PATH
Windows NT/2000/95:
set PATH=%path%;
Neither of these work in cygwin. I keep getting an error when trying to run my program.
Cygwin doesn't use LD_LIBRARY_PATH, it looks for shared libraries in PATH, so try:
export PATH=`pwd`:$PATH
That will add the current directory to the front of the PATH.
Is that
LD_LIBRARY_PATH=$(pwd)
and you just messed up the html, or are you really running:
LD_LIBRARY_PATH=pwd
If the latter, try adding the $() to get the current working directory into the path. Also, you can
echo $LD_LIBRARY_PATH
to ensure it contains what you want. You might consider doing
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$(pwd)
to avoid discarding previous contents of the path.