Im trying to use 'node-fluent-ffmpeg' to get the first frame of a video. I added 'ffmpeg' to my node-modules because it was a prerequisite for 'node-fluent-ffmpeg,' however, in my logs it says "cant find ffmpeg." I dont understand the second paragraph it the 'node-fluent-ffmpeg' documentation where it talks about this. What are they referring to by PATH and how do i properly connect these two libraries?
When you type a command like dir or ls, your system looks in a set of configured directories for that binary. PATH refers to the variable that holds the list of directories.
If the ffmpeg binary is not in a directory on your shells PATH, then you have to set the path explicitly when you run node. This is done with the FFMPEG_PATH and FFPROBE_PATH environment variables.
You check if the binaries are on your path with which.
$ which ffmpeg
/usr/local/bin/ffmpeg
$ which ffprobe
/usr/local/bin/ffprobe
If which doesn't return a path or your app is running under a different shell environment (like a service would), you can set those module variables specifically when running node.
FFMPEG_PATH=/usr/local/bin/ffmpeg \
FFPROBE_PATH=/usr/local/bin/ffprobe \
node whatever.js
In your case it will be the full path to the node_modules directory you put the ffmpeg and ffprobe binaries in.
Related
I'm new to WSL and Linux, but I'm trying to follow installation instructions for rhasspy (https://rhasspy.readthedocs.io/en/latest/installation/#windows-subsystem-for-linux-wsl). I have run the make install command successfully and the next step says I should copy rhasspy somewhere in my path but I can't quite figure out what copying to path means.
When installation is finished, copy rhasspy.sh somewhere in your PATH and rename it to rhasspy.
I added it to path but nothing changed so I was wondering if there is something I'm doing wrong. Right now when I run rhasspy on wsl it says rhasspy.sh: command not found. Any help would be really appreciated!
What it says is, put it in some place where the system will look for it when you type its name without full path in the shell.
There is an environment variable PATH that contains all those locations, separated by a :. (Check out echo $PATH.)
So, the author of these instructions leaves it up to you whether...
You want to copy the file to a location of your choice that is already in the PATH, such as /usr/local/bin or ~/bin.
Usually ~/bin is a good choice because it is per-user and doesn't pollute the system.
(Note that the directory ~/bin is added to the PATH by your .profile file only if it exists, so if you don't have this directory yet and create it now, you need to start a new login shell or run . ~/.profile1 before you can use it.)
- OR -
You want to create a new directory specifically for this application (say for example ~/opt/rhasspy) and append that directory to the PATH variable.
This can be done by adding the line export PATH=$PATH:~/opt/rhasspy to your ~/.profile file. Then, start a new login shell or reload the file using . ~/.profile1 for the changes to take effect.
If the directory in which this file is currently located is OK for you to keep permanently, then you can also just add that directory to the PATH instead of creating a new one.
Note: The PATH always contains directory paths in which the shell will look for executable files. It does not contain the actual file paths!
1: Yes, technically it is "cleaner" to log into a new shell or to run that one export statement manually instead of using . ~/.profile because the latter will apply things a second time that were already done before, so for example it can end up with the same directory in the PATH multiple times in the current session. In most cases that is fine though.
PATH is an environment variable. When you launch env, you see the list of known environment variables on your system.
In order to add something to your PATH variable, you need to take the variable, add the mentioned directory (preceeded by a semi-colon, most probably, as a separator) and store this again as the PATH variable. This can be done as follows (own example):
export PATH=$PATH:/home/this_user
the "PATH" it is referring to in linux is just inside the folder called /usr/bin. when you type a command into the terminal it looks for a program with that name inside the location. im not sure if this is the PATH you are looking for but hope it helps
I went through one of very few good dockerizing Vue.js tutorials and there is one thing I don't understand why is mandatory in Dockerfile:
# add `/app/node_modules/.bin` to $PATH
ENV PATH /app/node_modules/.bin:$PATH
COPY package.json /usr/src/app/package.json #not sure though how it relates to PATH...
I found only one explanation here which says:
We expose all Node.js binaries to our PATH environment variable and
copy our projects package.json to the app directory. Copying the JSON
file rather than the whole working directory allows us to take
advantage of Docker’s cache layers.
Still, it doesn't made me any smarter. Anyone able to explain it in plain english?
Error prevention
I think this is just a simple method of preventing an error where Docker wasn't able to find the correct executables (or any executables at all). Besides adding another layer to your image, there is in general as far as I know no downside in adding that line to your Dockerfile.
How does it work?
Adding node_modules/bin to the PATH environment variable ensures that the executables created during the npm build or the yarn build processes can be found. You could also COPY your locally builded node_modules folder to the image but it's advised to build it inside the Docker container to ensure all binaries are adapted to the underlying OS running in the container. The best practice would be to use multistage builds.
Furthermore, adding the node_modules/bin at the beginning of the PATH environment variable ensures that exactly these executables (from the node_modules folder) are used instead of any other executables which might also be installed on the system inside the Docker image.
Do I need it?
Short answer: Usually no. It should be optional.
Long answer: It should be enough to set the WORKDIR to the path where the node_modules is located for the issued RUN, CMD or ENTRYPOINT commands in your Dockerfile to find the correct binaries and therefore to successfully get executed. But I for example had a case where Docker wasn't able to find the files (I had a pretty complex setup with a so called devcontainer in VSCode). Adding the line ENV PATH /app/node_modules/.bin:$PATH solved my problem.
So, if you want to increase the stability of your Docker setup in order to make sure that everything works as expected, just add the line.
So I think the benefit of this line is to add the node_modules path from the Docker container to the list of PATHs on the relevant container. If you're on a Mac (or Linux I think) and run:
$ echo $PATH
You should see a list of paths which are used to run global commands from your terminal i.e. gulp, husky, yarn and so on.
The above command will add node_modules path to the list of PATHs in your docker container so that such commands if needed can be run globally inside the container they will work.
.bin (short for 'binaries') is a hidden directory, the period before the bin indicates that it is hidden. This directory contains executable files of your app's modules.
PATH is just a collection of directories/folders that contains executable files.
When you try to do something that requires a specific executable file, the shell looks for it in the collection of directories in PATH.
ENV PATH /app/node_modules/.bin:$PATH adds the .bin directory to this collection, so that when node tries to do something that requires a specific module's executable, it will look for it in the .bin folder.
For each command, like FROM, COPY, RUN, CMD, ..., Docker creates a image with the result of this command, and this images are called as layers. The final image is the result of merge of all layers.
If you use the COPY command to store all the code in one layer, it will be greater than store a environment variable with path of the code.
That's why the cache layers is a benefit.
For more info about layers, take a look at this very good article.
I run a lot of node projects and often have binaries located in:
.\node_modules\.bin
...relative to the projects folder. I'd like to be able to have PATH always include these directories, if they exist. I don't want to include other directories, just the one relative to the current directory. I'm familiar with
Add-PathVariable from PSCX and other Powershell basics, but how do I include a folder relative to the current dir in PATH?
Edit: as mentioned in the question, already, I expect the path to stay updated as the directory changes. This is not simply asking about how to use pwd.
You can use a relative path in Env:PATH and the binaries found will update dynamically:
Eg:
$env:PATH += ';.\node_modules\.bin'
Or with the PowerShell Community Extensions (PSCX):
Add-PathVariable '.\node_modules\.bin'
Unlike using $(pwd) the . is not immediately resolved to an absolute path, so PATH is always relative to the current working directory.
Testing this:
$ which uuid
C:\Users\username\Documents\myapp\node_modules\.bin\uuid.cmd
Then changing directory, uuid now refers to a program in a different dir:
$ cd ..\blog\
$ which uuid
C:\Users\username\Documents\blog\node_modules\.bin\uuid.cmd
It's also possible to persistently change PATH in the user or system environment:
[Environment]::SetEnvironmentVariable(($env:PATH + ';.'), 'User')
or
[Environment]::SetEnvironmentVariable(($env:PATH + ';.'), 'Machine')
Security note: when entering a command Windows will automatically search all directories in $env:PATH for files with one of the extensions listed in $env:PATHEXT and execute the first match it finds. Depending on where exactly in the search path you placed . that may even supersede system executables.
You may want to take a look at how to use package installed locally in node_modules for alternative approaches.
I have perl installed on a cluster drive at /clusterhome/myperl, and the same /clusterhome directory mounted on a workstation computer at /home/chris/cluster
Running perl obviously works fine from the cluster, but when I run /home/chris/cluster/myperl/bin/perl from my workstation, it can't find any modules. The #INC is still set to
/clusterhome/myperl/lib/site_perl/5.16.3/x86_64-linux
/clusterhome/myperl/lib/site_perl/5.16.3
/clusterhome/myperl/lib/5.16.3/x86_64-linux
/clusterhome/myperl/lib/5.16.3
This happens even with the following environment variable values prepended on the workstation:
PATH /home/chris/cluster/myperl/bin
PERL5LIB /home/chris/cluster/myperl/lib
LD_LIBRARY_PATH /home/chris/cluster/myperl/lib
MANPATH /home/chris/cluster/myperl/man
Is there a way I can get this perl to work on both the cluster and the workstation? I reinstall it often (nightly), so if extra make flags are required, it's totally fine.
The exact installation location (where to look at for module inclusion) is compiled into the binaries of perl. There are other uses for the installation directory name (for example, when compiling new modules, a bunch of compilation options are provided from these compiled-in strings).
So, you have the following options:
you make sure that the files are available on every computer in the directory where they were designed to be (symlinks: ln -s, bind mounting: mount -o bind, or mounting there upfront),
you compile a new perl for every new location.
You may also disregard this compiled-in directory, and specify the directories to be used every time you want to use perl via some command-line or environment variable. For #INC, you can use command-line option -Idirectory.
I'm trying to compile a piece of software in my home directory (OpenMPI). One of the build dependencies (autoconf) installed on my system is not the newer version asked for by the OpenMPI autogen script. I compiled and installed the newer version of autoconf in my home directory.
Is there anyway for the binary installed in my home directory to "override" the version installed on the system for my session?
I tried setting an alias which works via command line but not for the script used to generate the configure script.
Add the path to the binary you want to override to your $PATH environment variable.
Like PATH=/path/to/binary:$PATH ./compile
Your added path will then be looked up first when trying to find the compile command. It will only be valid for that execution and will not remain after command has returned. You can use export PATH=/path/to/binary/:$PATH and it will be saved for that session.
EDIT: As Eric.J states, you can use which compile which will output the path to the command, just to make sure it's the right one.
You can change the PATH environment variable so that your home directory appears before the system directory, e.g.
PATH=$HOME/bin:$PATH
You can then use the which command to ensure the correct binary is being picked up.