How do you use environment variables and aliases to simplify your relative paths in CLI? (original) (raw)
Last updated on Oct 17, 2024
Powered by AI and the LinkedIn community
If you work with the command-line interface (CLI), you know how important it is to navigate efficiently through your directories and files. Sometimes, you may need to use long and complex relative paths to access or modify your data. This can be tedious and error-prone, especially if you have to repeat the same commands over and over. Fortunately, there are two handy tools that can help you simplify your relative paths in CLI: environment variables and aliases. In this article, you will learn what they are, how to create and use them, and some best practices to keep in mind.
Top experts in this article
Selected by the community from 7 contributions. Learn more
Another use for environment variables is application security. It's best practice to never hard code application passwords into the software you're developing. Instead use an ".env" file or set an evironment variable, and configure your program to check for that variable. This ensures important passwords are not replicated into central code repositories.
Environment variables can be seen like user-defined constants that are created for portability and to shorten CLI syntax (to avoid writing too long lines). They are also an element of the OS, used for defining paths and config settings and can be assimilated with a key-value pairs. I mostly defined env vars related to date and time and as path shortcuts to apps or config files. I remember that, in the first years of Windows, user had to add the path of a new installed app into PATH env variable, manually, otherwise app didn't start. Nowadays, most of the modern installers do add their application’s path to the PATH environment variable automatically.
Long, often repeated commands, are a perfect usecase for Aliases. I'm thinking of Docker container startup, shutdown and cleanup operations.
Aliases appeared as a necessity to automate repetitive typing of same syntax. They are defining chunks of syntax that you use frequently they looks like a simple short variable name that you insert as a shortcut in you CLI coding to avoid writing too much or too often the same thing. They can be created to be temporary (for the current terminal session) or permanent. You can use aliases to create custom command you need in your day-to-day work to get faster and simplify your typing.
Another great thing is to add the aliases that you use frequently to your ~/.bashrc file so that this is retained in your session logins for the future as aliases only are retained within a current login session and don't forget to run source ~/.bashrc to 'reload your environment/login settings' (if you don't want to log-out and in again).
How to simplify relative paths with environment variables and aliases?
One way to simplify relative paths with environment variables and aliases is to create them for your common or frequently used directories and files. For example, if you often work with the project folder /home/user/projects, you can create an environment variable called PROJECTS and an alias called pj. Then, you can use them to quickly change to the project directory or to access its files. For example, cd PROJECTSorpjdocs/report.txt.Anotherwaytosimplifyrelativepathswithenvironmentvariablesandaliasesistousethemforcomplexorlongcommandsthatinvolvemultiplepathsoroptions.Forexample,ifyouoftencopyfilesfromonedirectorytoanotherwithcertainflags,youcancreateanaliasthatcombinesthecpcommandwiththepathsandflags.Then,youcanuseittoexecutethecommandwithasingleword.Forexample,aliasbackup="cp−r−u−vPROJECTS or pj docs/report.txt. Another way to simplify relative paths with environment variables and aliases is to use them for complex or long commands that involve multiple paths or options. For example, if you often copy files from one directory to another with certain flags, you can create an alias that combines the cp command with the paths and flags. Then, you can use it to execute the command with a single word. For example, alias backup="cp -r -u -v PROJECTSorpjdocs/report.txt.Anotherwaytosimplifyrelativepathswithenvironmentvariablesandaliasesistousethemforcomplexorlongcommandsthatinvolvemultiplepathsoroptions.Forexample,ifyouoftencopyfilesfromonedirectorytoanotherwithcertainflags,youcancreateanaliasthatcombinesthecpcommandwiththepathsandflags.Then,youcanuseittoexecutethecommandwithasingleword.Forexample,aliasbackup="cp−r−u−vDATA $BACKUP".
- Another good use to this is for ssh-ing into multiple environments with varying or different settings.. eg opening tunnels or proxies on a different ports with the same user can be given different aliases eg alias me_docker='ssh USER@USER@USER@HOSTNAME -L 8520:localhost:8250' or when you do regular git pulls from master you can have an alias such as alias gpm='cd ~; git checkout master && git pull origin master; clear'
What are some best practices for using environment variables and aliases?
When using CLI, environment variables and aliases can make your life easier but can also cause confusion or errors if you don't follow best practices. It's important to choose meaningful and descriptive names for your environment variables and aliases, avoiding names that are already reserved or used by other commands or programs. Uppercase letters should be used for environment variables and lowercase letters for aliases to help distinguish them and avoid conflicts or collisions. Additionally, document your environment variables and aliases in a file or comment to remember how to use them or share with others. Lastly, be mindful when using environment variables and aliases in scripts or pipelines as they may not work as expected if not defined or exported properly.
- 👉Best practices in naming and documenting env variables and aliases help to maintain consistent style even when team componence is changing. Any user must be able to find fast what is the meaning of an env var or alias and also to where this definition is stored. 👉Do not define or store in an env var or alias any personal data or secrets like passwords or API keys. 👉Test the scripts/pipelines before usage to validate they work as expected. 👉Use version control for config files to track the changes over time. 👉For env variables, take care of their scope and case sensitivity. 👉For aliases, take care that they may work only in interactive unless explicitly sourced. Verify the compatibility with the environment where pipeline runs.
Thanks for your feedback
Your feedback is private. Like or react to bring the conversation to your network.
``
More relevant reading
``