[SOLVED] Bash path string - question

[kenj70]

Pardon me, but it has been many years since I was a unix System V administrator and things have changed so much. I was following the instructions for adding the very latest static build of FFmpeg on my system...
https://www.johnvansickle.com/ffmpeg/faq/
and one of the steps requires you to move the latest FFmpeg executable to a location in the path string that is ahead or earlier in the string so that the newer version is invoked rather than the older version currently installed. This procedure is offered for those who want the very latest filters. On to my question:

My path string is: $ echo $PATH
/home/buddy/bin:/home/buddy/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bi
n:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

The problem is: The first two entries in the path string didn't even exist! How can a path string exist for non-existent directories? Shouldn't the system report an error?

-=Ken=-

[claydoh]

That is just the order of precedence. it just ignores paths that do not exist. For example, the first two are in your $HOME, which normally don't have executables unless the user puts some there.

You can use one of those if you want, but /usr/local/bin might be easier to manage, perhaps? That would put it ahead of the stock ffmpeg, and still be accessible system-wide.

whereis ffmpeg
ffmpeg: [B]/usr/bin/ffmpeg[/B] /usr/share/ffmpeg /usr/share/man/man1/ffmpeg.1.gz

Also, if it helps any:
https://snapcraft.io/ffmpeg

[chimak111]

With $PATH, I see

bash: /home/chimak111/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin: No such file or directory

This is on KDE neon 5.14.

So some message, No such file or directory, is generated if a path is missing?

[kubicle]

With $PATH, I see

bash: /home/chimak111/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin: No such file or directory

This is on KDE neon 5.14.

So some message, No such file or directory, is generated if a path is missing?

You get that error because you're trying to run $PATH (as opposed to just showing it [echo $PATH]), since the whole contents of the envvar $PATH string is not executable, you get the error (even if all the individual paths contained within the $PATH variable exist).

[jlittle]

As kubicle says, echo $PATH is what you were reaching for.

I swear by this alias, which could be defined in your $HOME/.bashrc:

$ alias   path='echo -e ${PATH//:/\\n}'
$ path
/home/john/bin
.
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

I find that much easier to read and understand than the raw $PATH.

[chimak111]

Thanks, kubicle & jlittle!

I've not had cause to deal with "$PATH" in my dealings with Linux

[kenj70]

Hey, guys, thanks for the discussion.

I do recall that the shell environment is just a text file. But I always thought the items had to be real locations. For this application I created the relevant bin directory under /home/username/.local which works just fine.

I am guessing that it is too much trouble to create the directories under $HOME during the user creation process - and since they may never be used - but it is 'convention' to utilize them when necessary.

So, this is SOLVED for me!

-=Ken=-

[kenj70]

Also, if it helps any:
https://snapcraft.io/ffmpeg

@claydoh, I overlooked your recommendation for the Snap version of FFmpeg. I tried it before trying the static build version and it was WEIRD! I had to invoke the Snap location directly since it didn't interpose itself into the PATH. The Snap FFmpeg package also includes FFplay and FFprobe which, unlike FFmpeg, had to be invoked with 'FFmpeg.FFplay' and 'FFmpeg.FFprobe'. How unusual! I asked about this on the FFmpeg subReddit and the only guy to respond claimed it was no big deal. Not to me. I like the idea of Snap, Flatpak and AppImage but they need to work without issues. Who ya' gonna call, bug busters?

This post is not really a question but provided as information. -=Ken=-

[jlittle]

...I had to invoke the Snap location directly since it didn't interpose itself into the PATH...

I'm on Cosmic, and something put /snap/bin in my PATH; I didn't. Looking at a log I keep, it first appeared in January 2017. I point this out because maybe you've got some login or startup script that sets the PATH, overwriting what Kubuntu gives you initially.

[kenj70]

Hi John Little. I'm on Neon and I think the Snap location was simply appended to my path string the first time I added a Snap package. Since it appears at the end - and FFmpeg appears in /usr/bin which is earlier/ahead in the path string - the Snap version is not picked up. I would have to uninstall the normal (older) distribution of FFmpeg or perhaps rename the FFmpeg executables to facilitate the Snap. The other problem of strange naming issues listed in post #8 would remain however.

-=Ken=-

[jlittle]

... I think the Snap location was simply appended to my path string the first time I added a Snap package...

I hadn't ever installed a snap until today.

... ffmpeg appears in /usr/bin which is earlier/ahead in the path string - the Snap version is not picked up...

Ah. The mechanism assumes that you don't install both, it would seem.

I wonder what snaps and flatpacks are for. I suspect they come from environments that don't have APT with its dependency management goodness, or the solid packaging we get from Ubuntu.

Regards, John Little

[kenj70]

I wonder what snaps and flatpacks are for.

They are, for the most part, self-contained applications which don't rely on system dependencies. They require more storage space but since our systems are much more storage rich today they are viable alternatives.

My first three years on Linux I ran Mint/Cinnamon and I could not get a version of Kdenlive newer than four years old from the repositories. That old version would crash by just adding a video file. Now, with Snap, Flatpak and AppImage it doesn't matter. If you have the disk space you can run it. I think that is a marvelous improvement for Linux users.

The current ppa version of FFmpeg is 4.03 and the new video 'chromashift' filter I want to use requires version 4.1. Until the the ppa is updated I am stuck. I tried the Snap version of FFmpeg 4.1 but it was not very well programmed and unusable in my opinion. So, I discovered you could download a "static" build - or an even newer "git snapshot." The 'chromashift' filter is still not fixed in version 4.1 but I was actually interacting with the developers on the StackExchange/super user forum and they are fixing it now. I didn't realize I was on the cutting edge, giving feedback for the app development!

-=Ken=-

[jlittle]

They are... applications which don't rely on system dependencies. ...

My first three years on Linux I ran Mint/Cinnamon and I could not get a version of Kdenlive newer than four years old from the repositories. ...

... I tried the Snap version of FFmpeg 4.1 but it was not ... unusable... an even newer "git snapshot." ... they are fixing it now...

Your story illustrates my thinking at several points:

• the six monthly Ubuntu updates are a good thing;
• the snap version didn't add much
• apt build-dep package, git clone, build and usually you're as up to date as you need to be, and ready to contribute, even with very little understanding of the source

Of course, it doesn't always work, but over the years I've done it a few times.