I needed to use yt-dlp and the repo version wasn’t working correctly, probably because it’s a month old. So I uninstalled all three yt-dlp related packages, meaning yt-dlp itself and the two python-yt-dlp ones, and downloaded the upstream version.
The repo version was placed in the /usr/bin folder. I placed the upstream version in the /usr/local/bin folder since that folder is also in the path variable. Although the upstream yt-dlp file is found and it’s running OK from the root account, it is not found if launched from the user account. It’s still trying to run it from the old /usr/bin folder giving me a message that it wasn’t found there. I have to type the absolute path every time I want to use it.
Why is this happening since root can use it and since the new location is already in the path variable and I do see it when I execute printenv from the user account?
Thank you.
p.s. I have changed the upstream yt-dlp 's permissions to 755, so that it’s executable by everyone.
I hadn’t realized it was so essential for me to use PATH instead of “path variable” for human communication. Nevertheless, it seems the problem was solved after the system was restarted the next day. Here is the information you requested, although it looks like everything is as it should be.
-rwxr-xr-x 1 root root 3057594 Mar 25 19:20 /usr/local/bin/yt-dlp
As I said, today everything works as it should.
The new question is why did the system need to be restarted for bash to get updated on the new file location since the PATH was correct for both the root and the user before the restart?
Did you logout / login user before trying the upstream yt-dlp? root was apparently logged in after the install of the upstream version?
If so that might have been an important difference between user and root .
Seeing which yt-dlp while the problem was still visible might explain what was going on. That difference, if any, is gone after a reboot.
BTW, yt-dlp version 2025.03.21-1.1 is now in TW snapshot 20250324.
No, I did not log out and back in the user before trying the upstream version.
Yes, root was logged in after the install indeed. I needed to check whether the file was detected by root since it wasn’t by the user.
Do you think that a just closing the user terminal window after the install and opening a new one would also update bash? I’m asking this because root was logged in using another terminal window that I opened after the install.
I think this is not the right question. Linux tries to minimize disk access to speed up things, so if you call yt-dlp the system looks for the executable and loads it in memory (user space). When you are finished, that executable remains in memory unless the kernel reclaims that memory space because it needs more room to load other executables. So if the same user (i.e. the same userspace) calls yt-dlp again, chances are that the system retrieves the executable still in memory, without crawling the filesystem again looking for the (installed meanwhile) new version of the executable.
Logging out the user destroys the user space, so on next login the new executable is loaded.
Opening a terminal for user root creates a new user space and calling yt-dlp looks for it in the filesystem and founds the new version.
Please note that I am no kernel developer, so the description above may not be an accurate detailed technical description of what happens in memory management.
But I think that it might be enough to have a feeling for what happened in your case.
I think that you noticed that while doing a system update, generally open applications continue to work (thankfully) even if some files have been deleted or replaced meanwhile and you may need to close and restart the application to see the new version at work.
When you close a program, the kernel frees the memory. The program doesn’t “remain in memory in case the user runs it again”. I don’t know of any operating system or computer system that does what you describe.
And that would have zero effect on calling a program from the path.
As written, I am no kernel developer so maybe I misread Kernel Page Cache
The physical memory is volatile and the common case for getting data into the memory is to read it from files. Whenever a file is read, the data is put into the page cache to avoid expensive disk access on the subsequent reads.
Anyway this is OOT and I’m not going to argue.
Still wondering what the OP witnessed though.
File caching is very different from what you were describing. Any time you launch a program, it instantiates a new program (there are exceptions to that, but the program has to be coded to recognize that it’s already running and then add a tab or something like that).
As you said, though, none of that is relevant to OP’s question.
It sounded more to me like it was something related to the environment for the user, but without more info about the state in which it wasn’t working, it’s not going to be easy to diagnose, and it sounds like that time has now passed.
Wait a moment, I deleted the upstream file /usr/local/bin/yt-dlp and something interesting happened:
bruno@LT-B:~> which yt-dlp
/usr/bin/yt-dlp
bruno@LT-B:~> yt-dlp --version
bash: /usr/local/bin/yt-dlp: No such file or directory
bruno@LT-B:~>
So which yt-dlp is correct, but bash is still looking for the deleted file???
So there is definitely something going on here.
But opening a new terminal tab finds the correct answer:
Maybe the exact way I did it creates some kind of problem. Let me explain.
Opened a terminal window.
Executed sudo -i to become root.
Executed zypper remove *yt-dlp* to remove all three yt-dlp related packages.
Download and placed the upstream yt-dlp in /usr/local/bin
Changed its permissions using chmod -v 755 /usr/local/bin/yt-dlp
Executed as rootyt-dlp -U just to check if it works. It was detected correctly.
I typed exit to logout as root.
At this point I was in the same window as a user. I typed yt-dlp --version and the system responded that the file cound not be found in the /usr/bin folder where the repo version used to be.