.bashrc EndeavourOS default

[theleapingfrog]

Hello,

I just wanted to know if all the stuff that is inside the .bashrc by default is necessary or if it can be removed.

Thanks,

theleapingfrog

[dalto]

You can remove anything in there you don’t want.

[theleapingfrog]

I mean will it break stuff? I know the functions can be removed. However, I am not sure the stuff up top can which I will insert below.

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

[[ -f ~/.welcome_screen ]] && . ~/.welcome_screen

_set_my_PS1() {
    PS1='[\u@\h \W]\$ '
    if [ "$(whoami)" = "liveuser" ] ; then
        local iso_version="$(grep ^VERSION= /usr/lib/endeavouros-release 2>/dev/null | cut -d '=' -f 2)"
        if [ -n "$iso_version" ] ; then
            local prefix="eos-"
            local iso_info="$prefix$iso_version"
            PS1="[\u@$iso_info \W]\$ "
        fi
    fi
}
_set_my_PS1
unset -f _set_my_PS1

ShowInstallerIsoInfo() {
    local file=/usr/lib/endeavouros-release
    if [ -r $file ] ; then
        cat $file
    else
        echo "Sorry, installer ISO info is not available." >&2
    fi
}

[dalto]

@theleapingfrog

I mean will it break stuff?

No. Although, if you remove the stuff that sets your prompt you will have a generic bash prompt.

[Kresimir]

I have a general .bashrc question:

This line:

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

is it really necessary?

As far as I know, non-interactive shell sessions do not source .bashrc, so I think that that test never succeeds and the return command never gets executed.

To answer the question in the OP: there is absolutely nothing important for normal interactive shell use in this default EndeavourOS .bashrc. It is so minimalist that it does literally nothing (at least on an installed system), so feel free to delete everything, nothing will break

NB: My question about .bashrc is not directed specifically to @theleapingfrog , but a general question to anyone who might know the answer. I just accidentally clicked on the wrong reply button.

@dalto

No. Although, if you remove the stuff that sets your prompt you will have a generic bash prompt.

This default EndeavourOS .bashrc sets the prompt to PS1='[\u@\h \W]\$ ' (unless using the live ISO), which is the generic bash prompt. So deleting everything in this .bashrc won’t even change the prompt.

[theleapingfrog]

Dont worry i would not bet able to answer .

[manuel]

I think we should redesign our default .bashrc.
Now we have some of its original purpose handled otherwise. I also believe not many users are even using the definitions in the default .bashrc.

[Kresimir]

Personally, I think this is fine for the live image, and on the installed system, I would prefer there not be any .bashrc at all. Default bash is entirely usable (unlike Zsh), and this gives user the opportunity to make his or her own .bashrc.

I don’t even have a .bashrc file, and my user’s default shell is bash (but I use Zsh in Konsole, bash is just for the TTY). Everything works fine.

We can give tips and some presets here on the forum, for those that do not know where to start.

That’s just my opinion, though.

[Scotty_Trees]

I don’t have the .bashrc file handy, but on my Solus and PopOS installs, the only thing I really added or had in the file was just adding the line “neofetch” to the line so it always started whenever I opened up a new Terminal. I try to keep things simple.

[Kresimir]

You might find this useful, @Scotty_Trees:

[Tip] A better way to add neofetch to your .bashrc

For some reason, many people like to add neofetch to their .bashrc (or .zshrc, or whatever shell rc file they are using). It seems to be the obligatory part of “ricing” your Linux install. In my opinion, neofetch is just bloated kitsch, but if you’re one of those people who like bloated kitsch, this post is for you, I hope you find it helpful. The biggest problem I see with adding neofetch to your .bashrc is that it slows down the loading of your terminal emulator. On my crappy…

[Scotty_Trees]

Just looked into that link and tested that on my PopOS since it’s what I’m currently running (perhaps it functions a bit differently on EndeavourOS). But while it does load the neofetch output instantly which is nice, the user command prompt delays for about like a second before it shows up and becomes active. Under my normal neofetch in the .bashrc file, it all loads up in about a second, so for me the performance is negligible. Usually I just have 2-3 terminal tabs open. One just to display neofetch cuz I’m a weirdo like that! And two other tabs for updates and installing/removing/tinkering with stuff. It’s cool to try to new things, thanks for sharing that, I’ll definitely keep it around somewhere to test from time to time.

[anon79501528]

This only thing I have in my .bashrc is a ref to .bash_aliases…

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi

[Feakster]

Is there a reason we use bash as the login shell? Doesn’t Arch use zsh?

[dalto]

@Feakster

Doesn’t Arch use zsh?

No. bash is a dependency of base.

That being said, Arch is very much a build it yourself type of solution so I am not sure the idea of a default shell really applies.

[Kresimir]

It’s impossible to not have bash installed on an Arch-based system. But you can use whatever shell you want for your user account, there are no restrictions on that.

Personally, I like to keep bash as my root’s and user’s shell, but for normal, everyday interactive use, I have Zsh (which I run from Konsole).

What upsets me about Arch is that there are scripts that are supposed to be POSIX compatible (#!/bin/sh) that contain bash-specific syntax (and should thus be #!/bin/bash). While theoretically possible, in practice, for example, it is very difficult to install dash and symlink it to /bin/sh and not have stuff break. This is one of the few things in which Debian-based distros are objectively better than Arch-based ones.

In Debian or 'Buntu, no package gets accepted to the repo if it contains a POSIX script with bashisms (this is because /bin/sh is dash on Debian and any such script will thus result in errors). On Arch, the standards for that are much lower, since /bin/sh is bash and scripts that use bash-specific syntax can still run. The downside to that is that POSIX scripts run up to 4 times slower on Arch than on Debian.

---

@anon79501528

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi

In my opinion, there is no point to this if statement.

If your .bash_aliases file suddenly went missing for some strange reason, wouldn’t you like an error message displayed? Testing whether it exists seems wasteful. This is usually found on pre-made .bashrc files that come with big distros and are meant to be used by many people, some who have .bash_aliases file, and some who don’t. But when you’re writing your own .bashrc, you already know that, so why test it every time you start an interactive shell session?

Keep it simple and just have:

. ~/.bash_aliases

That’s it.

[dalto]

@Kresimir

Testing whether it exists seems wasteful.

Yeah, that is 0.01 microseconds every time you source your .bashrc that you will never get back.

[Kresimir]

I suppose you then write every line in your shell scripts as:

if true; then do_stuff; fi

My point was not about saving time, but about having code that does nothing. The test is always true and .bash_aliases file always gets sourced. But if for some strange reason the file goes missing, you will want to see the error message. The test makes sense only when you sometimes have that file and sometimes don’t, but do not want to be informed about it through an error message (which is when you write the .bashrc file for mass use, but never when you do it for yourself).

[keybreak]

That’s such a bloat

[dalto]

@Kresimir

I suppose you then write every line in your shell scripts as:

I like to quite a bit more thorough than that.

• First I check to make sure that /usr/bin exists
• Then I check to make sure find is present
• Next I use find to ensure that each directory in the tree exists(one at a time)
• Only once all that is verified do I check for existence of the file

[BONK]

I take it this is before you plug yourself into your regeneration module for the evening