The Best Bashrc Ever ((LINK))

As a Linux systems administrator, I've been working on this .bashrc file for well over a decade. Over the years, I have searched through scores of .bashrc and script files collecting and improving on new ideas and features.

the best bashrc ever

This portable drop in Bash configuration file can be used on any system anywhere you use a terminal. It will detect most settings on most systems and make sure your environment has every feature available automatically without any additional effort or configuration. That was the original purpose and intention behind it.

My previous version was released in 2014. Others have contributed and made changes to it and even that older version of the extract function wound up in the default .bashrc for earlier versions of Manjaro. If you liked the older prompt from that earlier version (now with newly added Git support), download the optional .bashrc_prompt script file and place it in either your home directory or as the file /.config/bashrc/prompt.

Or just download and manually copy the .bashrc and .bashrc_help files into your home folder (the /.bashrc_help file can also be relocated to /.config/bashrc/help if you wish to remove it from your home directory).

You can change some of the settings of the script without changing your .bashrc file (handy for updates) using environment variables. You can put custom environment variables in the following locations and they will automatically be loaded:

This feature gives you the ability to add features, configurations, environment variables, and bash script code to the .bashrc without changing it. This also gives you the flexibility to add/remove things that are dependant to that particular machine. It also makes it easier to update your .bashrc file without having to make changes to the base file (which makes it more portable to other machines).

NOTE: You'll notice that if the immutable read only flag is set (to prevent scripts and applications from modifying your .bashrc file), it is removed before the update. To put it back, add this to the end of the above commands:; sudo chattr +i /home/USERNAME/.bashrc

I've used a number of different *nix-based systems of the years, and it seems like every flavor of Bash I use has a different algorithm for deciding which startup scripts to run. For the purposes of tasks like setting up environment variables and aliases and printing startup messages (e.g. MOTDs), which startup script is the appropriate place to do these?

What's the difference between putting things in .bashrc, .bash_profile, and .environment? I've also seen other files such as .login, .bash_login, and .profile; are these ever relevant? What are the differences in which ones get run when logging in physically, logging in remotely via ssh, and opening a new terminal window? Are there any significant differences across platforms (including Mac OS X (and its Terminal.app) and Cygwin Bash)?

Then you have config files that are read by "interactive" shells (as in, ones connected to a terminal (or pseudo-terminal in the case of, say, a terminal emulator running under a windowing system). these are the ones with names like .bashrc, .tcshrc, .zshrc, etc.

bash complicates this in that .bashrc is only read by a shell that's both interactive and non-login, so you'll find most people end up telling their .bash_profile to also read .bashrc with something like

.bashrc is used for non login shells. I'm not sure what that means. I know that RedHat executes it everytime you start another shell (su to this user or simply calling bash again) You might want to put aliases in there but again I am not sure what that means. I simply ignore it myself.

I added some bash alias commands for easier management inside the sudo user .bashrc file to save keystrokes when the sudo user wants to run a bash script.... these work great, however, I'd like to expand these by allowing certain alias commands to integrate with variable options defined in the stack config file.

Edit: currently Permission denied error is given if I try to simply source the stack config file inside sudo user's .bashrc file (after trying to restart bash session). The rest of the normal aliases work fine but none of the shell variables in the config file are readable with current permissions.

.bashrc is a Bash shell script that Bash runs whenever it is started interactively. It initializes an interactive shell session. You can put any command in that file that you could type at the command prompt.

You put commands here to set up the shell for use in your particular environment, or to customize things to your preferences. A common thing to put in .bashrc are aliases that you want to always be available.

Contrast .bash_profile and .profile which are only run at the start of a new login shell. (bash -l) You choose whether a command goes in .bashrc vs .bash_profile depending on whether you want it to run once or for every interactive shell start.

If you put that in .bashrc instead, every time you launched an interactive sub-shell, :/some/addition would get tacked onto the end of the PATH again, creating extra work for the shell when you mistype a command.

The purpose of a .bashrc file is to provide a place where you can set up variables, functions and aliases, define your (PS1) prompt and define other settings that you want to use every time you open a new terminal window.

REMINDER - if you change your .bashrc, be sure to start a new terminal window to make sure it works BEFORE rebooting (best practice - do it immediately after the change). If you ever mess up your .bashrc and reboot YOU MAY NOT BE ABLE TO LOGIN! Personally I also create a second 'admin' user on personal machines so that, in such an emergency (broken login), I can log into that and use then use sudo to fix my other login .bashrc file.

The exec command completely replaces the shell process by running the specified command-line. In our example, it replaces whatever the current shell is with a fresh instance of bash (with the updated configuration files).

It's best to create a user (with sudo privileges), and login as this username instead.This will create a directory for your settings, including .profile and .bashrc files as described on the previous ressource.

Depending upon your environment, you may want to add scripting to have .bashrc load automatically when you open an SSH session. I recently did a migration to a server running Ubuntu, and there, .profile, not .bashrc or .bash_profile is loaded by default. To run any scripts in .bashrc, I had to run source /.bashrc every time a session was opened, which doesn't help when running remote deploys.

Assuming an interactive shell, and you'd like to keep your current command history and also load /etc/profile (which loads environment data including /etc/bashrc and on Mac OS X loads paths defined in /etc/paths.d/ via path_helper), append your command history and do an exec of bash with the login ('-l') option:

exec will replace the current shell, such that you are not left with it when the new one exits. env will create a new empty environment, with -i we add $HOME so that your shell (usually bash) given by $SHELL can find /.profile//.bash_profile (and thus (on ubuntu or if specified) /.bashrc). Those will be sourced thanks to -l. I'm not completely sure though.

The way we can control our terminal appearance and some behavior is through the .bashrc file. That file typically gets read once when loading a new terminal window and that is where we can save some shortcuts we like to use, alter the colors of our terminal, change the behavior of the up and down arrow keys, etc.

Lets start adding features to our terminal experience by editing the /.bashrc file. I typically include comments # describing what the code is doing and where I learned how to do \(X\). The first part is controlling your bash history. I want to have a longer history than what is included by default and where duplicates are deleted.

You can change the colors of your terminal. For example, do you want directories to be shown in blue and/or bold font while executable files are shown in red. This goes in hand with the ls --color=auto shortcut to make sure that the colors are used (Mac: you might need brew install coreutils as described in this blog post). The following lines of my /.bashrc file include some old history of the colors and how I use to have other options.

As it is explained here to save alias permanently I need to execute /.bash_aliases or /.bashrc commands in terminal and add my alias there. But when I execute /.bashrc I get following error message :

The second method lets you make a separate aliases file, so you won't have to put them in .bashrc, but to a file of your choice. First, edit your /.bashrc file and add the following lines if they don't already exist, or uncomment them if they do:

It sounds to me like your only problem is simply trying to execute .bashrc when it is not executable. But this isn't the correct way to do it; whenever you make a change to this file, you should "execute" it by the command:

I'm assuming the second error was because bash_aliases does not exist. It is not required, just recommended to keep your changes separate and organized. It is only used if it exists, and you can see the test for it in .bashrc:

Whatever the command / aliased command, this way with the echo statement, quotation marks, and the symbol for appending the output of a command to a file (>>) works for me. Just replace my command for the alias command you need and enter it into your terminal.

As I recall, bashrc has, or had, a line suggesting to not use it for aliases directly. The solution is to use an external file(s). The foo and bar aliases have been added, but to add baz the bashrc file must be "sourced" (or, just open a new terminal). Example as:

Terminal preferences can contain a number of different things. Most commonly, the bashrc file contains aliases that the user always wants available. Aliases allow the user to refer to commands by shorter or alternative names, and can be a huge time-saver for those that work in a terminal regularly.