launcher.sh behaves differently @reboot than calling with sh

Question

I was send here from Stackoverflow. Thank you for your help.

I am using a launcher.sh for a raspberrypi 4B with Raspi os x64 to start a python script in a python env on startup. But setting the environment is problematic.

The file (test.sh) looks like:

. envname/bin/activate
echo Hi Stackoverflow

or alternatively

#!bin/bash
. envname/bin/activate
echo Hi Stackoverflow

using sh test.sh, correctly executes the shell script. However, using it at launch with crontab

@reboot sh /home/pi/test.sh >/home/pi/logs/cronlog 2>&1

I get an error:

/home/pi/test.sh: 2: .: cannot open envname/bin/activate: No such file

How to properly set source @reboot to start the env on startup?

p.s. sh is not the solution. With bin/sh and source envname/bin/activate it does not work as Ubuntu apparently uses bash rather than sh, and if sh is used the source command is not known. Bash uses . instead of source

Edit 1: Normal Ubuntu uses bash for shell, but maybe that is different on startup? Could that be a way?

Answer 1

This is a relative path:

envname/bin/activate

Presumably, when you use sh test.sh, your current working directory includes a subdirectory envname.

However, every directory not called envname could contain a directory called envname (in fact, even those called envname could have a subdirectory with the same name) and the limit on the number of directories called envname is quite high.

It may well be that this is actually the only one, but when the shell executes a command containing a relative path, it does not search through the entire filesystem looking for the first (or every) thing that matches. It looks in the current working directory. If the file is not there, it throws an error.

A script executed at boot is not run in the directory it is contained in. These are two separate things. When you execute sh, you are using an executable stored in a specific place, but it executes in the location you invoke it from, not where its binary is stored.

Scripts run at boot should use absolute paths, ie., ones rooted at /:

#!bin/bash
. /home/pi/envname/bin/activate
echo Hi Stackoverflow

This presumes the actual location of test.sh is /home/pi as in your cron entry. But to reiterate: Unless you know where the script is called from, don't assume anything. If you want to work in a specific directory, use cd with the absolute path.