cron calls my bash script (it's a backup script) with an empty PATH. As a result, while a line like

lvcreate --size 1G --snapshot ... 

works just fine when I run the script from a terminal, it can't find lvcreate if run from the crontab. A similar problem was described here, but I am more interested in general strategies to deal with the underlying problem.

Ideas I've come up with so far:

• As a quick workaround, I manually set PATH at the top of my script. I also could do this in the crontab. Should system-wide PATH ever change, I might need to manually update all those lines.

• A more permanent solution would be to use absolute paths in my script, e.g. substitute the call with something like /sbin/lvcreate --size 1G ... but while this would work on the Ubuntu Server where I first encountered this problem, on my Arch Linux ARM (RPi) lvcreate is located in /usr/bin/.

• I could which every command with PATH set properly, store the results and set a local alias at the top of my script, but that seems a bit messy to me.

• I thought about sourcing /etc/environment. That would work for my Ubuntu machines (and I think also for plain debian), but then again on my RPi the system-wide PATH is not set there. For the same reason (not wanting to rely on the location and/or use of certain files in various distros) I am hesitant to use .bashrc or similar.

So my question is: What is a good way to make scripts not rely on PATH being set and still keep them portable? Is there a state of the art method?

cron calls my bash script (it's a backup script) with a very sparse PATH of /usr/bin:/usr. As a result, while a line like

lvcreate --size 1G --snapshot ... 

works just fine when I run the script from a terminal, it can't find lvcreate if run from the crontab. A similar problem was described here, but I am more interested in general strategies to deal with the underlying problem.

Ideas I've come up with so far:

• As a quick workaround, I manually set PATH at the top of my script. I also could do this in the crontab. Should system-wide PATH ever change, I might need to manually update all those lines.

• A more permanent solution would be to use absolute paths in my script, e.g. substitute the call with something like /sbin/lvcreate --size 1G ... but while this would work on the Ubuntu Server where I first encountered this problem, on my Arch Linux ARM (RPi) lvcreate is located in /usr/bin/.

• I could which every command with PATH set properly, store the results and set a local alias at the top of my script, but that seems a bit messy to me.

• I thought about sourcing /etc/environment. That would work for my Ubuntu machines (and I think also for plain debian), but then again on my RPi the system-wide PATH is not set there. For the same reason (not wanting to rely on the location and/or use of certain files in various distros) I am hesitant to use .bashrc or similar.

So my question is: What is a good way to make scripts not rely on PATH being set and still keep them portable? Is there a state of the art method?