My BASH scrit has following line:

video_id=$(/usr/local/bin/yt-dlp --no-warnings --get-id "$ChannelPath")

it succeeds when runs from command line under certain user.

When it runs from cron, under the same user, it results in:

/usr/bin/env: python3: No such file or directory

What could be different in these two cases?

• CentOS 7
• Python 3.11.0a4

CodePudding user response：

There are some discussions whether you should use #!/usr/bin/env python or #!/usr/bin/python. Proponents of the env variant say that it is better, because env uses the PATH to find the interpreter, and opponents say that the problem with the env variant is that it uses the PATH.

I dislike env, therefore I will give you a solution without it.

From the command line type

which python3

This will give you something like

/usr/bin/python3

In /usr/local/bin/yt-dlp, replace the first line with

#!/usr/bin/python3

(the output that you got from the which command.)

Or call /usr/local/bin/yt-dlp with explicitly the right interpreter:

video_id=$(/usr/bin/python3 /usr/local/bin/yt-dlp --no-warnings --get-id "$ChannelPath")

CodePudding user response：

it succeeds when runs from command line under certain user.

When it runs from cron, under the same user, it results in:

/usr/bin/env: python3: No such file or directory

What could be different in these two cases?

The difference is the environment in which the script runs. In particular, the environment variables in it, and most particularly, the PATH.

When a user runs the script from the command line, it inherits the environment from which it was launched, which includes system-wide and possibly user-specific customizations that are engaged only for interactive shells. (For example, the contents of the user's ~/.bash_profile and / or ~/.bashrc files.) By default, when a shell is launched noninteractively (by cron, for example) it does not read or execute any environment configuration.

Evidently,

1. Your /usr/local/bin/yt-dlp is or attempts to launch a Python script that has a shebang line using /usr/bin/env to choose and launch the python3 binary. That is, the affected script starts with

   #!/usr/bin/env python3
   

   These days, that form is widely used and recommended in the Python world. The purpose is to use the PATH to locate the python3 binary to use, as opposed to hard-coding that into the script. However,

2. There is no system Python 3 installed on the machine. (That is, none installed in the default path.) The user who runs the script successfully is able to do so because they have an environment configured with some non-default directory in their PATH from which python3 can be launched.

One possible solution would be to install CentOS's Python 3:

sudo yum install python3

If you need a different version of Python 3 (CentOS 7's is version 3.6) then you can instead set an appropriate PATH in the relevant crontab file, maybe something like

PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
0 * * * * /path/to/my_script

Alternatively, you could modify your shell script to set the path there:

PATH=/usr/local/bin:$PATH
video_id=$(/usr/local/bin/yt-dlp --no-warnings --get-id "$ChannelPath")

or you could modify /usr/local/bin/yt-dip by altering its shebang (supposing that this is the affected Python script).

CodePudding user response：

I moved the python3 symlink from /usr/local/bin to /usr/bin and it works now.

/usr/local/bin was the suggested location in internet-manuals about how to compile and install Python 3.11 in CentOS7.

A better solution is to add

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

to the first line of crontab. Although it should be not /etc/crontab, but

crontab -l > crontab.txt

then edit crontab.txt

then

crontab crontab.txt