Manjaro default .bashrc explained - for dummies?

Hey there, just wondering if anyone has any material at hand that breaks down the default additions to the Manjaro .bashrc, explaining what each section of it does. I know the file itself has comments, but some of it is pretty technical and obtuse, while others are very short and not very descriptive.

Link to the .bashrc:

I searched the forum and checked on Google, but couldn’t find anything definite, so sorry if it’s already there somewhere.

In particular, I am wondering about:

[ -r /usr/share/bash-completion/bash_completion ] && . /usr/share/bash-completion/bash_completion


[[ $- != *i* ]] && return

This one:

Change the window title of X terminals 
case ${TERM} in
                PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/\~}\007"'
                PROMPT_COMMAND='echo -ne "\033_${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/\~}\033\\"'

This one:

xhost +local:root > /dev/null 2>&1

And this one:

complete -cf sudo

For the colorful PS1 section, I am not sure what this means:

#Try to use the external file
# first to take advantage of user additions.  Use internal bash
# globbing instead of external grep binary.

If there’s a writeup somewhere that covers the whole thing, I’d love to see it.


1 Like

If /usr/share/bash-completion/bash_completion is readable, source the file.

A standalone period followed by a space is an internal shell command, and is synonymous with the internal command source. What this does is read the commands from a text file into the current shell, as opposed to executing them in a subshell. This is also how ~/.bashrc and ~/.bash_profile are read into your shell.

The left square bracket is an internal shell command that is synonymous with the internal shell command test ─ both also exist as external commands, as specified by the POSIX standard ─ but with the difference that if you use the syntax with the left square bracket, then the right square bracket is the mandatory closing argument. The -r is a switch to [ (or test) which tests whether a particular file or directory is readable.

Basically, it tests whether a condition is true. The double ampersand ─ && ─ is a logical AND operator. So if the condition is true, then what follows after the double ampersand is executed. The inverse would be a double vertical bar ─ || ─ which is the logical OR operator. So if it had said || instead of &&, then what follows after the || is only executed if the condition on the left is false.

Otherwise put, in pseudo-code…:

[ condition ] && some_command_here

… is the same thing as…

if [ condition ]

… but in shorthand. The longer version allows for multiple commands to be grouped together. You can also do that with the shorthand version, but it’s trickier to read. :wink:

If the running shell is not an interactive shell, return to the calling function/process without doing anything.

$- lists the shell options. So the test with the double square brackets ─ which allows for more flexibility than the single square brackets ─ looks at the shell options, and if there is not ─ the exclamation point ("!") signifies a logical NOT ─ an “i” in that list of options ─ i being that the shell is interactive ─ then it executes the command return, which returns it to the calling process without exiting the shell.

That’s a case statement, which is meant to verify certain conditions. In this case, it checks whether the value of the variable ${TERM} ─ which can alternatively be spelled as simply $TERM, although there is a reason as to why curly brackets are preferred, and this has to do with concatenation ─ is in the list given, including xterm, rxvt, and so on, and if so, it’ll execute the first command, which sets the variable ${PROMPT_COMMAND}. This is an internal shell command ─ for details, see…

man bash

The case statement goes on that if ${TERM} is not in that list of terminal names, but is instead screen ─ i.e. GNU screen, a terminal multiplexer ─ it’ll define the ${PROMPT_COMMAND} differently.

xhost is a tool for allowing or disallowing connections to the running X11 server. In this case, it allows local connections from root.

> is an output redirection, which in this case ─ with 2>&1 ─ redirects both stdout and stderr to /dev/null. This is often done to get rid of command verbosity.

From the Bash manual…

complete (TAB)
Attempt to perform completion on the text before point. Bash attempts completion treating the text as a variable (if the text begins with $), username (if the text begins with ~), hostname (if the text begins with @), or command (including aliases and functions) in turn. If none of these produces a match, filename completion is attempted.

grep is a tool for searching for text ─ via regular expressions ─ in files or in pipes; a pipe is when the output of one command is routed to be the input of another command.

Globbing is the interpretation by the shell of variables and what DOS/Windows users call “wildcards” ─ e.g. * and ?.

Hope this explains things. :wink:


Super comprehensive answer, thank you for that!

Ah ok, that’s fairly straightforward then - I am familiar with source to some extent. So this basically adds bash completion if available.

Thanks for breaking it down like that, I was seeing this everywhere, cool to see bash has as this kind of shorthand for things like if statements.

So does this basically return if a command/script is just giving you some non-interactive output (like running ls or something)? What happens if you don’t have this in .bashrc, do you have to exit/return manually?

Does that mean this basically adds what terminal you are using to your prompt?

Might be slightly out of scope, but what are the benefits of this, or are there any potential downsides to allowing local connections from root to X11?

It took me a while of using Manjaro to even realise that some of the behaviour I was seeing in bash was not standard, but tailored by Manjaro, so sometimes it’s hard for me to figure out which behaviours are Manjaro specific.


I didn’t think initially of searching on the archived forum, but I also found your post there to a previous version of my question, maybe people will find it useful:

It’d be really cool if a wiki article was made for this, properly breaking this down to a granny’s tech support level of explanation. I am eager to learn about my system but have to admit sometimes my eyes glaze over when I look into scripts.

Will try to learn more bash-fu but haven’t found the time lately.


No, it pertains to whether you are running an interactive shell or not. If it’s running some non-interactive script ─ which would be running in a subshell ─ then that subshell is non-interactive, and then the command return will stop execution of the subshell and return to the calling shell or process, while if the shell is interactive ─ and thus, the condition is false ─ then the shell will continue reading and executing the commands below that line.

No, it’s a command that gets executed before the prompt is shown, and in this case, it adds the name of the terminal application to the window title.

No, you need that ─ at least, if you’re using a display manager and/or a non-modesetting video driver ─ because the display manager needs to be able to read /etc/shadow, and only a process running with UID 0 (root) can do that. The X server usually runs with root privileges, for that reason.

1 Like

If your question was adequately answered, could you then please mark the post that did so as the solution? It’ll add an expandable summary of the post to your opening post. :wink:


1 Like

I see, I will do more reading up on interactive vs. non-interactive shells.

Oh right, of course, now I understand why I have ‘konsole’ in the Window tittle on KDE. This is one of those things I assumed was just default behaviour.

So this must be a kind of standard thing people have in their .bashrc?

Of course, just selected your first answer as the solution. I still haven’t grasped the contents totally, but I will do the rest of the legwork myself, now that you have kindly pointed me in the right direction.


No, it’s distribution-dependent. Other distributions may put it in e.g. a file under /etc/profile.d/ somewhere, or in ~/.xinitrc, or some other file.

It also depends on what the default settings are when is compiled by the distro developers. :wink:

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.