fix broken reload/restart and preexec

[NoahGorny]

• lib: helpers: Dont reload .bash_profile in login shells
• lib: preexec: Properly return if there was a conflict in check_*_conflict

We broke some things in our recent merges!

Description

Motivation and Context

How Has This Been Tested?

Locally

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• If my change requires a change to the documentation, I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• If I have added a new file, I also added it to clean_files.txt and formatted it using lint_clean_files.sh.
• I have added tests to cover my changes, and all the new and existing tests pass.

[NoahGorny]

Hi @gaelicWizard, seems like we merged some bogus stuff in our recent merges, wanna take a look?

[gaelicWizard]

@NoahGorny, it was deliberate to remove the weird Mac-specific handling of the startup files. I expressly said so in the commit message! Bash on Mac loads startup files exactly the way it does on any other *nix. It sticks out like a sore thumb to me.

If we're reloading the shell startup file, then we should reload the file that the shell started up with. By switching on $OSTYPE, we will load the wrong file when we're in the other kind of shell.

1. All that said, I did add $BASH_IT_BASHRC more recently and it would make more sense to dispense with the conditional altogether and just use that variable to identify the file that the shell started with.

2. Alternatively, we could just load specifically bash_it.sh. The user may or may not expect all shell init to re-run.

I vote for #1. I'll do a patch shortly.

[gaelicWizard]

It's entirely possible I reversed the conditional.

Should it return success if there is a conflict, or if there isn't a conflict?

[NoahGorny]

we check ! __check_preexec_conflict when we are adding, which makes sense. If the element is in the array, there is conflict, so we should not add it. It was reversed and I fixed it here

[gaelicWizard]

(Now I need to go dig through my main branch to find out if I had fixed this and didn't pick it or if my preexec has been broken for months...)

[gaelicWizard]

(Yep, it's been broken for a couple of weeks since I added the __bp_trim_whitespace and adopted _bash-it-array-contains-element... 😢)

[gaelicWizard]

@NoahGorny, can we get the preexec fix merged asap? ♥

[NoahGorny]

@NoahGorny, it was deliberate to remove the weird Mac-specific handling of the startup files. I expressly said so in the commit message! Bash on Mac loads startup files exactly the way it does on any other *nix. It sticks out like a sore thumb to me.

If we're reloading the shell startup file, then we should reload the file that the shell started up with. By switching on $OSTYPE, we will load the wrong file when we're in the other kind of shell.

1. All that said, I did add $BASH_IT_BASHRC more recently and it would make more sense to dispense with the conditional altogether and just use that variable to identify the file that the shell started with.
2. Alternatively, we could just load specifically bash_it.sh. The user may or may not expect all shell init to re-run.

I vote for #1. I'll do a patch shortly.

Yap, such variable is the best solution

[NoahGorny]

I removed the part about the loading of the bashrc, but we should fix this asap as master is currently broken

[gaelicWizard]

@NoahGorny, I'm curious how you found a problem with the startup file reloading. In the common case, switching on OS or type of shell should usually do the same thing. What actually happened?

[NoahGorny]

@NoahGorny, I'm curious how you found a problem with the startup file reloading. In the common case, switching on OS or type of shell should usually do the same thing. What actually happened?

It breaks on WSL, as its a login shell and I only have bashrc installed there

[gaelicWizard]

a login shell and I only have bashrc installed there

🤯 A bash login shell, which doesn't load ~/.bashrc, which uses only ~/.bashrc is not a scenario which I had anticipated.

(Many Linux distributions import ~/.bashrc from /etc/profile (or a default ~/.profile) as a workaround for bash's weirdness in startup files, so I should have known better, but oops.)

EDIT: fix in #2067