I have a ros (kinetic) environment set up on a raspberry pi 3 and am trying to get ros to execute upon startup via a simple bash script which calls roslaunch. Ros works in the user domain but fails when called from root.
Here is my launch_ros.sh script:
#!/bin/bash
source /home/pi/ros_catkin_ws/devel/setup.bash
export PYTHONPATH=/opt/ros/kinetic/lib/python2.7/dist-packages
roslaunch my_pkg pkg_launch.launch
When I run sudo /home/pi/Desktop/ros_launch.sh the roscore crashes with
ERROR: cannot launch node of type [rosout/rosout]: can't locate node
[rosout] in package [rosout] failed to start core service [/rosout]
The traceback for the exception was written to the log file
But, if I comment out
source /home/pi/ros_catkin_ws/devel/setup.bash
and execute /home/pi/Desktop/ros_launch.sh, ros works fine.
Also worthy of noting is if I leave the above source line uncommented when running in the user domain I get the same error as I do in the root. I think this might be pointing me to the solution but I am still very new to ros.
Has anyone come across this issue and found a solution?
In order to run a node as root after changing your shell to root using commands like sudo -i, You can source your current bash profile thats located inside your normal user .bashrc and use it inside root shell.
Try the following code:
#!/bin/bash
source /opt/ros/kinetic/setup.bash
source /home/pi/ros_catkin_ws/devel/setup.bash
export PYTHONPATH=/opt/ros/kinetic/lib/python2.7/dist-packages
roslaunch my_pkg pkg_launch.launch
You need to source your workspace devel to be able to find your own package.
But, you need to source ROS devel to be able to use roscd, roslaunch, ...
In the code below I added:
source /opt/ros/kinetic/setup.bash
to source ROS and be able to use it.
PS: If it's still not working you should try a short delay before running roslaunch.
I was accidentally in a conda environment (base only) and it was messing up big-time. Try disabling any Python virtual environments.
It really worked and it inspired me to report that I didn't have rosnode as a program when I was planning to call ROS scripts in my own applications. Calling source .bashrc directly from the Raspberry Pi's system would refresh the terminal, but there was no way for my program to take over. The solution was to place the required ROS environment scripts in a separate script like name init_env.sh and then call source init_env.sh before any other ROS scripts were executed.
Related
I have enabled golangci-lint file watcher in GoLand but when I save file I got error like below one:
msg="Running error: context loading failed: no go files to analyze"
After some debugging I found that this error comes when I run golangci-lint without activating my virtual env.
So my question is how do I tell file watcher to run golangci-lint after activating virtual environment?
So, In summary I want this:
Before running any file watcher command, Run this command
source .my_virtual_env_folder/bin/activate
This command is basically activates virtual environment.
I am new to GoLand. I tried to do google search but no luck.
I found a workaround.
Make a executable file, write all the commands there. We have full control on which commands do we want to run and in which order. Then in file watcher "Program", paste the absolute path of this file.
I just wrote source <name_of_the_env>/bin/activate at the top of file and then wrote my main command.
This way it activated the virtual environment and then call the command.
Iam failing while integrating pio to the CLion IDE. I included the PATH variable to the ~/.profile file (three different ways) as:
export PATH=$PATH:~/.platformio/penv/bin
export PATH=$PATH:home/jonas/.platformio/penv/bin
export PATH="~/.platformio/penv/bin":$PATH
and can run the pio – version (and also the equivalent platformio) without sudo privelegies.
But when I’m trying to create a new pio project in CLion I always get
```Cannot run programm ./home/jonas/.platformio/penv/bin” (in directory “/tmp”): error=13, Permission denied``
Ok, I got it working. The problem was that the path to pio was not complete. The path (/home/jonas/.platformio/penv/bin/home/jonas/.platformio/penv/bin) points to the folder but not to the file to run. The full path is:
/home/jonas/.platformio/penv/bin/pio (or platformio).
However, in the create project window, you don’t even get to correct the path and it was automatically created during installation. This is a bit confusing.
I need to activate a virtualenv Python enviroment on my NanoPI NEO with Armbian (Debian-based). I created a simple script to do so:
#!/bin/bash
echo "Activating application's virtual enviroment..."
source /mpoint/bin/activate
echo "Running main app.."
python /mpoint/mpoint.py
I chmodded all the necessary files, and copied the mentioned script to init.d and update-rc.d'd it.
Problem is, from what I understand I need to run that script as source, that is the script creates its own instance with the enviroment, then closes. Other questions mention various solutions, but none of them answer my question - how can I run this as source at startup?
It could be that you don't have to activate the virtual environment at all. Generally one only needs to call the Python interpreter in the virtual environment's bin directory explicitly. In your case the following should be good enough: /mpoint/bin/python /mpoint/mpoint.py.
I have a windows machine with CygWin installed on it. I do not hold any admin privileges, so, forget about changing environment variables which apply to all user and etc...
Scenario:
When I execute CygWin and type the following command to execute Maven, it works perfectly:
/cygdrive/c/maven/apache-maven-3.5.0/bin/mvn
However, when I create the file .profile as below:
alias mvn="cygdrive/c/maven/apache-maven-3.5.0/bin/mvn"
After restarting CygWing and executing the command "mvn", the following message is sent: No such file or directory.
Any suggestions?
Thanks in advance.
For any of you who may have the same problem, the way I solved this was basically adding a "sh" at the beginning of the command:
elias mvn="sh /cygdrive/c/maven/apache-maven-3.5.0/bin/mvn"
Cheers.
I'm trying to use bash as the shell on Windows for a GitLab CI Runner.
concurrent = 1
check_interval = 0
[[runners]]
name = "DESKTOP-RQTQ13S"
url = "https://example.org/ci"
token = "fooooooooooooooooooobaaaaaaaar"
executor = "shell"
shell = "bash"
[runners.cache]
Unfortunately I can not find an option to specify the actual shell program that the CI Runner should use. By default, it just tries to run bash which it can not find. I don't know why, because when I open up a Windows command line and enter bash it works.
Running with gitlab-ci-multi-runner 1.9.4 (8ce22bd)
Using Shell executor...
ERROR: Build failed (system failure): Failed to start process: exec: "bash": executable file not found in %PATH%
I tried adding a file bash.cmd to my user directory containing
#"C:\Program Files\Git\usr\bin\bash.exe" -l
That gives me this strange error:
Running with gitlab-ci-multi-runner 1.9.4 (8ce22bd)
Using Shell executor...
Running on DESKTOP-RQTQ13S...
/usr/bin/bash: line 43: /c/Users/niklas/C:/Users/niklas/builds/aeb38de4/0/niklas/ci-test.tmp/GIT_SSL_CAINFO: No such file or directory
ERROR: Build failed: exit status 1
Is there a way to properly configure this?
There are two issues going on here, and both can probably be solved.
gitlab-runner cannot find bash
gitlab-runner doesn't combine unix-style and Windows-style paths very well.
You have essentially succeeded in solving the first one by creating the bash.cmd file. But if you're curious about why it didn't work without it, my guess is that bash runs in your command prompt because the directory that contains it (e.g. in your case "C:\Program Files\Git\usr\bin") is included in the PATH environment variable for your user account. But perhaps you are running the gitlab-runner in the system account, which might not have the same PATH.
So the first thing to do is just check your system's PATH variable and add the bin directory if necessary (i.e. using the System applet in the Control Panel as described here or here). Just make sure you restart your machine after you make the change, because the change isn't applied until after you restart. That should make bash work, even when called from a service running in the system or admin account.
As for the strange error you got after creating bash.cmd, that was due to the second issue. Paths are often really hard to get right when combining bash and Windows. Gitlab-runner is probably trying to determine whether the build path is relative or absolute, and ends up prepending the windows path with what it thinks is the working directory ($PWD). This looks like a bug, but gitlab still has not fixed it (as of version 9.0 of the runner!!) and probably never will. Maybe they have decided it is not a bug or that it is due to bugs in underlying software or tools that they can't fix or that it would be too difficult to fix. Anyway, I've discovered a work-around. You can specify the base path for builds in the config.toml file. If you use a unix-style path, it fixes the problem.
On windows, config.toml is usually in the same folder as your gitlab-runner.exe (or gitlab-multi-runner-amd64.exe etc). Open that file in your favorite text editor. Then find the [[runners]] section and add two lines similar to the following.
builds_dir="/c/gitlab-runner/builds/"
cache_dir="/c/gitlab-runner/cache/"
The path you use should be the "bash version" of whatever directory you want gitlab-runner to use for storing builds etc. Importantly if you are using cygwin, you would use a path similar to /cygdrive/c/... instead of just /c/... (which is appropriate for msys-git or standalone MSYS2 etc).
Here's an example of a config.toml file:
[[runners]]
name = "windows"
url = "https://your.server.name"
token = "YOUR_SECRET_TOKEN"
executor = "shell"
shell = "bash"
builds_dir="/c/gitlab-runner/builds/"
cache_dir="/c/gitlab-runner/cache/"
It looks like you're attempting to link gitlab-ci up with the Windows Subsystem for Linux (which can be accessed by typing bash at the Windows command prompt)? I doubt that this is supported directly by Gitlab's runner configuration.
Instead, I would suggest using Powershell with your shell executor.
Executor = 'shell'
Shell = 'powershell'
You can then drop down into Bash in the scripts you call from .gitlab-ci.yml.
Given that it's bad practice to execute more than very trivial shell scripts within the .gitlab-ci.yml itself (as opposed to calling out to an external script), you lose little by being forced to use a native Windows shell.