It often occurs in a developers day that they need to install a new application and be able to access it from the command line. In most cases a nicely packaged
installer (.msi, .exe or .AppImage) is there to handle this process for you along with setting up directories and default config, all with a few clicks through a GUI.
Same goes for installing packages via a package manger like apt for Ubuntu or choco for Windows. A single command and the process is done.
Although this is incredibly convenient, not all applications ship with an installer. You may encounter application directories that have been "zipped" or "tar-balled" and once
extracted gives you access to the application and dependencies when executed from its current home. When you receive a compressed folder like this it might just be
the needed app inside or there may be a folder within called bin which contains your app. The easiest way to make the app accessible from the CLI is to add
the folder path containing it to the PATH environment variable. By adding the app directory to the PATH env. variable, we build a list of directories that are searched any time an
app is called from the command line. The few steps below will walk you through doing this in both Linux and Windows.
As an example, we are going to install the dfu-programmer CLI which allows a user to reflash Atmel AVR microcontrollers via the USB-DFU class. The contents or use of the application is not important here but rather the process. If you'd like to follow along installing a different application, feel free to do so.
- Ubuntu
- Windows
To begin, place the uncompressed app folder wherever you'd like on the filesystem. Typically when installing applications in this manner,
you would place the application in the /usr/local folder.
sudo mv dfu-programmer/ /usr/local/dfu-programmer
If we ls the app directory, we find the dfu-progammer executable. You may have another layer with a bin folder within that then contains your executable you want to
execute. Regardless of where the application actually lives we want to add the full path to its storage location, to our PATH env variable. To do so, edit the .bashrc file located in your home directory.
vi ~/.bashrc
With the .bashrc file open - Add the following line anywhere in the file.
export PATH=/usr/local/dfu-programmer:$PATH
When adding the export statements you should use the path to the folder that contains the executable and should not include the executable name.
The above line pre-pends the path to our dfu-programmer directory to the current $PATH env variable and then assigns that new list back to itself (PATH). This rc file we just edited is
loaded every time a terminal is opened and the line we added will let our current shell know about the dfu-programmer location. To re-iterate, this line adds to the enviroment variable
and does not overwrite it. This means if we have multiple applications to install in this manner, we can have multiple export statements one after another that will not overwrite one another.
To test if our changes worked, source the rc file - making our current shell aware of the new directory we've added to the PATH environment variable.
source ~/.bashrc
Now try and execute our application from any directory on the file system.
cd ~
dfu-programmer --version
If we were succesfull then we should see a version string of 1.0.0 printed on the console.
dfu-programmer 1.0.0
If the above did not work and you see something like Command X not found, did you mean:, verify that the full path to the folder containing your executable was properly added to the
.bashrc file. To guarantee the new rc file is being sourced you can close your terminal, open a new one and try the command again.
All of the commands in this guide are executed from a Powershell terminal.
To begin, place the uncompressed app folder wherever you'd like on the filesystem. Typically when installing applications in this manner, I like to place the app folder in my root C:\
directory.
mv dfu-programmer-x64-1.0.0 C:\
If we ls the app directory, we find the dfu-progammer.exe executable inside. You may have another layer with a bin folder within that then contains your executable you want to
execute. Regardless of where the application actually lives we want to add the full path to its storage location, to our PATH env variable. To do so, execute the following from Powershell.
# Add to the current users path
setx PATH "%PATH%;C:\dfu-programmer-x64-1.0.0"
# Add to all users path. Will require the PS to be ran as Administrator
# Start a new powershell as administrator
Start-process powershell -verb runas
setx /M PATH "%PATH%;C:\dfu-programmer-x64-1.0.0"
When adding to the PATH env variable you should use the path to the folder that contains the executable and should not include the executable name.
The above line appends the path to our dfu-programmer directory to the %PATH% env variable and then assigns that new list back to itself (PATH). To re-iterate, this command adds to
the enviroment variable and does not overwrite it.
In order for the PATH changes to take effect we need to close our current terminal and open a new one. Once the new terminal is open try and execute our application from any
directory on the file system.
cd ~
dfu-programmer --version
If we were succesfull then we should see a version string of 1.0.0 printed on the console.
dfu-programmer 1.0.0
If the above did not work and you see something like X : The term 'X' is not recognized as the name of a cmdlet, function, script file, or operable
program., verify that the full path to the folder containing your executable was properly added. You can verify what was added by typing $env:Path into Powershell. Your app directory
should be one of the last in the list of directories printed.
That's it! You now have access to your application via the command line and are ready to integrate the new app into your automation or general workflows.