I have set up the google assistant sdk on my Raspberry Pi as shown here: https://developers.google.com/assistant/sdk/prototype/getting-started-pi-python/run-sample
Now in order to re-run the assistant I have worked out the two commands are
$ source env/bin/activate
and
(env) $ google-assistant-demo
however I want to automate this process into a script that I can call from rc.local (followed by an &) in order to make the assistant boot from start up.
However if I run a simple script
#!/bin/bash
source env/bin/activate
google-assistant-demo
the assistant does not run inside the environment
my environment path is /home/pi/env/bin/activate
How can I have it so the script starts the environment and then runs the assistant inside the virtual environment?
EDIT: In the end I went with the following method:
using this as a base :
https://youtu.be/ohUszBxuQA4?t=774 – thanks to Eric Parisot
You will need to download the src file he uses and extract its contents into /home/pi/src/
However with a few changes.
I did not run gassist.sh as sudo, as it gave me the following error:
OpenAlsaHandle PcmOpen: No such file or directory
[7689:7702:ERROR:audio_input_processor.cc(756)] Input error
ON_MUTED_CHANGED:
{‘is_muted’: False}
ON_START_FINISHED
ON_ASSISTANT_ERROR:
{‘is_fatal’: True}
[7689:7704:ERROR:audio_input_processor.cc(756)] Input error
ON_ASSISTANT_ERROR:
{‘is_fatal’: True}
Fix: DO NOT run as sudo
If gassist.sh gives an error about RPi.GPIO you need to do https://youtu.be/ohUszBxuQA4?t=580:
$ cd /home/pi/env/bin
$ source activate
(env) $ pip install RPi.GPIO
(env) $ deactivate
And then I did sudo nano /etc/profile
and the appended this to the end:
#Harvs was here on 24/06/17
if pidof -x "gassist.sh" >/dev/null; then
echo ""
echo "/etc/profile says:"
echo "An instance of Google Assistant is already running, will not start again"
echo ""
else
echo "Starting Google Assistant..."
echo "If you are seeing this, perhaps you have SSH within seconds of reboot"
/home/pi/src/gassist.sh &
fi
And now it works perfectly, and inside the virtual enviroment :)
found solution here :https://raspberrypi.stackexchange.com/a/45089
Create a startup shell script in your root directory (I named mine "launch"), make it executable too :
sudo nano launch.sh
I wrote it that way :
#!/bin/bash
source /home/pi/env/bin/activate
/home/pi/env/bin/google-assistant-demo
Save the file
Edit the LXDE-pi autostart file
sudo nano /home/pi/.config/lxsession/LXDE-pi/autostart
Add this to the bottom of that file
./launch.sh
reboot
Scripts run from rc.local execute in the root directory (or possibly in the home directory of the root user, depending on the distro, I think?)
The easy fix is to code the full path to the environment.
#!/bin/bash
source /home/pi/env/bin/activate
google-assistant-demo
# or maybe /home/pi/google-assistant-demo
There is no need to explicitly background anything in rc.local
In the end I went with the following method:
using this as a base : https://youtu.be/ohUszBxuQA4?t=774 – thanks to Eric Parisot
However with a few changes.
You will need to download the src file he uses and extract its contents into /home/pi/src/
I did not run gassist.sh as sudo, as it gave me the following error:
OpenAlsaHandle PcmOpen: No such file or directory
[7689:7702:ERROR:audio_input_processor.cc(756)] Input error
ON_MUTED_CHANGED:
{‘is_muted’: False}
ON_START_FINISHED
ON_ASSISTANT_ERROR:
{‘is_fatal’: True}
[7689:7704:ERROR:audio_input_processor.cc(756)] Input error
ON_ASSISTANT_ERROR:
{‘is_fatal’: True}
Fix: DO NOT run as sudo
If gassist.sh gives an error about RPi.GPIO you need to do https://youtu.be/ohUszBxuQA4?t=580:
$ cd /home/pi/env/bin
$ source activate
(env) $ pip install RPi.GPIO
(env) $ deactivate
And then I did sudo nano /etc/profile and the appended this to the end:
#Harvs was here on 24/06/17
if pidof -x "gassist.sh" >/dev/null; then
echo ""
echo "/etc/profile says:"
echo "An instance of Google Assistant is already running, will not start again"
echo ""
else
echo "Starting Google Assistant..."
echo "If you are seeing this, perhaps you have SSH within seconds of reboot"
/home/pi/src/gassist.sh &
fi
And now it works perfectly, and inside the virtual enviroment, and in boot to CLI mode! :)
Related
I am trying to export ROS_MASTER_URI from a shell script and then launch roscore. In my .sh file I have:
roxterm --tab -e $SHELL -c "cd $CATKIN_WS; $srcdevel; export ROS_MASTER_URI='http://locahost:1234'; roscore -p 1234"
When I do this, however, I get the following error in the roscore tab:
WARNING: ROS_MASTER_URI [http://locahost:1234] host is not set to this machine.
When I echo the ROS_MASTER_URI in this tab, it says that it is localhost:1234, which is correct. When I manually execute these commands, it works correctly and roscore launches without any issues. I am not sure why it does not work when launched from a bash file.
It was just a typo- missed the l in localhost. All working now.
I'm trying to create an EC2 User-data script to run other scripts on boot up. However, the scripts that I run fail to recognize some commands and variables that I'd already declared. I'm running the commands as the "ubuntu" user but it still isn't working.
My user-data script looks something like this:
export user="ubuntu"
sudo su $user -c ". ./run_script"
Within the script, I have these lines:
THIS_PATH="/some/path"
echo "export SOME_PATH=$THIS_PATH" >> ~/.bashrc
source ~/.bashrc
However, the script can't run SOME_PATH/application, and echo $SOME_PATH this returns a blank line. I'm confused because $SOME_PATH/application works when I log into the EC2 using SSH and my debug logs using whoami returns "ubuntu."
Am I missing something here?
Your data script is executed as root and su command leaves $HOME and other ENV variables intact (note that sudo is redundant). "su -" does not help either
So, do not use ~ or $HOME but full path /home/ubuntu/.bashrc
I found out the problem. It seems that source ~/.bashrc isn't enough to restart the shell -- the environment variables worked after I referenced them in another bash script.
I am using the Bash on Ubuntu on Windows, the way to run bash on Windows 10. I have the Creators update installed and the Ubuntu version is 16.04.
I was playing recently with things as npm, node.js and Docker and for docker I found it is possible to install it and run it in windows and just use the client part from bash, calling directly the docker.exe file from Windows's Program Files files folder. I just update my path variable to include the path to docker as PATH=$PATH:~/mnt/e/Program\ Files/Docker/ (put in .bashrc) and then I am able to run docker from bash calling docker.exe.
But hey this bash and I dont want to write .exe at the end of the commands (programs). I can simply add an alias alias docker="docker.exe", but then I want to use lets say docker-compose and I have to add another one. I was thinking about adding a script to .bashrc that would go over path variable and search for .exe files in every path specified in the path variable and add an alias for every occurance, but it does not seem to be a very clean solution (but I guess it would serve its purpose quite well).
Is there a simple and clean solution to achieve this?
I've faced the same problem when trying to use Docker for Windows from WSL.
Had plenty of existing shell scripts that run fine under Linux and mostly under WSL too until failing due to docker: command not found. Changing everywhere docker to docker.exe would be too cumbersome and non-portable.
Tried workaround with aliases in ~/.bashrc as here at first:
shopt -s expand_aliases
alias docker=docker.exe
alias docker-compose=docker-compose.exe
But it requires every script to be run in interactive mode and still doesn't work within backticks without script modification.
Then tried exported bash functions in ~/.bashrc:
docker() { docker.exe "$#"; }
export -f docker
docker-compose() { docker-compose.exe "$#"; }
export -f docker-compose
This works. But it's still too tedious to add every needed exe.
Finally ended up with easier symlinks approach and a modified wslshim custom helper script.
Just add once to ~/.local/bin/wslshim:
#!/bin/bash -x
cd ~/.local/bin && ln -s "`which $1.exe`" "$1" || ln -s "`which $1.ps1`" "$1" || ln -s "`which $1.cmd`" "$1" || ln -s "`which $1.bat`" "$1"
Make it executable: chmod +x ~/.local/bin/wslshim
Then adding any "alias" becomes as easy as typing two words:
$ wslshim docker
+ cd ~/.local/bin
++ which docker.exe
+ ln -s '/mnt/c/Program Files/Docker/Docker/resources/bin/docker.exe' docker
$ wslshim winrm
+ cd ~/.local/bin
++ which winrm.exe
+ ln -s '' winrm
ln: failed to create symbolic link 'winrm' -> '': No such file or directory
++ which winrm.ps1
+ ln -s '' winrm
ln: failed to create symbolic link 'winrm' -> '': No such file or directory
++ which winrm.cmd
+ ln -s /mnt/c/Windows/System32/winrm.cmd winrm
The script auto picks up an absolute path to any windows executable in $PATH and symlinks it without extension into ~/.local/bin which also resides in $PATH on WSL.
This approach can be easily extended further to auto link any exe in a given directory if needed. But linking the whole $PATH would be an overkill. )
You should be able to simply set the executable directory to your PATH. Use export to persist.
Command:
export PATH=$PATH:/path/to/directory/executable/is/located/in
In my windows 10 the solution was to install git-bash and docker for windows.
in this bash, when I press "docker" it works
for example "docker ps"
I didnt need to make an alias or change the path.
you can download git-bash from https://git-scm.com/download/win
then from Start button, search "git bash".
Hope this solution good for you
I have successfully installed homestead on my mac machine and i have set path using following command
export PATH=~/.composer/vendor/bin:$PATH
but every time when i restart my machine, homestead command does not work, i would have to run export PATH=~/.composer/vendor/bin:$PATH again to fix this.
Please suggest a way to fix this. Thanks for your help.
Use a shell provisioner to put that line either in /etc/profile (for the whole system) or just ~vagrant/.profile (for just your user). Like so:
config.vm.provision "set-path", type: "shell" do |s|
s.inline = "grep "~/.composer/vendor/bin" ~vagrant/.profile &> /dev/null || echo "export PATH=~/.composer/vendor/bin:\$PATH" >> ~vagrant/.profile"
end
This does a grep to check to see if that text is in the file, and if that returns a non-zero result (||) appends that line to the end of the file.
This is the contents of my /etc/rc.local file. It is supposed to run on login on my raspberry pi, yet it just logs in in (as I'm using auto login) and then does nothing, i.e. it just sits there with pi#raspberrypi ~$_ waiting for a command. I have no idea why it's not working nor any experience with bash scripts.
It should mount a usb then run a file on said usb but it doesn't.
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
sudo /bin/mount /dev/sda1 /media/robousb
sudo python media/robousb/Robopython/usercode_old.py
exit 0
I assuming you're running Raspbian, which is pretty much Debian.
rc.local runs as root before login, so you don't need or want sudo; it may be causing an error, hence nothing happening.
User-level commands that run for any user when they log in (unlike rc.local, which runs before login) can be put into /etc/bash.bashrc. That may be more applicable to your situation, at least the second command.
Login commands for the pi user only can be put into /home/pi/.bashrc
I don't know raspberry-pi but you could try to write something into a file to see if the file is running or not. For example :
touch /tmp/test.txt
echo "$(date) => It's running" > /tmp/test.txt
If it doesn't work, I know that on some OS (fedora, rhel, centos for example), the path of that file is /etc/init.d/rc.local. It doesn't cost anything to try this path ;)
I have the exact same problem with RPi3/Jessie.
I suggest you to launch your script in the bashrc by doing
sudo emacs /home/pi/.bashrc
In my case i wrote at the EOF:
bash /home/pi/jarvis/jarvis.sh -b &
And that works well at each startup.
I have the same problem. In Raspbian forum is the solution:
Just change the first row from #!/bin/sh -e to
#!/bin/bash
Ivan X is right. You don´t need sudo command.