Vince Mulhollon wrote:
> I'm not OP but I have experience trying to run python scripts from
> crontab in various virtual environments and its ROUGH.

To help understand cron's environment it is always good to make a test
and see what the environment looks like.

    * * * * * (pwd;id;umask;env;) >/var/tmp/cron.env.out 2>&1

Then look at the environment. Realize that PATH is usually the
minimum system path. Things like umask and pwd might not be what you
expect. Specific environment variables that are often a problem such
as USER are not set. (Set it from LOGNAME. Or `whoami` or whatever.)
You should always set LC_ALL=C for a standard locale setting. And so
on. After you know the environment then dealing with it is not
difficult.

> /bin/sh may or may not support the source command.

In /bin/sh if there is support for "source" then it's a non-portable
extension. Always use "." in /bin/sh scripts. The "source" syntax
comes from csh.

It's easy to use "#!/usr/bin/env INTERPRETER" where INTERPRETER is
replaced with python3, perl, bash, or even sh and then it is found on
PATH via the env command's PATH lookup. That's a time honored
reliable method. Set PATH as desired and then everything works.

> You can run a /bin/sh script to call a /bin/bash script to call the
> venv Python script. Or set the SHELL env var in crontab if your
> local crontab supports that (to run /bin/bash for all crontabs
> instead of /bin/sh)

If you want bash'isms then it is perfectly okay to set this
explicitly. And then you can use bash'isms in the crontab command
lines. But it should be an explicit user choice and not a system
default.

    SHELL=/bin/bash

> Why we have to deal with /bin/sh instead of just use bash everywhere
> in 2025 is another good question, if I never see /bin/sh again I'll be
> OK.

Why we have to deal with /bin/bash instead of just using /bin/sh
everywhere in 2025 is another good question. If I never see /bin/bash
used in a script again I'll be okay. Just to give the opposite
viewpoint here. :-)

> I wish there were a scripting language you could compile with static
> linking, LOL.

I could also rant about the evils of rpath in binaries too. Static
linking is generally bad, bad, bad. Don't do it! Fortunately distro
Policy is to have dynamic linking but other software distros do it
otherwise and I don't use those distros.

Bob