Alright. Thanks to @dalto the other day → I’ve decided to rid my system of fish. It’s not been nearly as easy as I had hoped. I’ve had to timeshift several times again.
Problem: every time I remove fish with yay -R fish I no longer have access to TTY or konsole. Konsole will launch long enough to see it on the task bar and immediately dissappear. In a TTY, I’m able to enter my user name, it asks for my password, and then immediately returns to ask for my user again.
At this point I’ve tried a number of things → but this is where I currently am.
I can still access a TTY and Konsole. I STILL have coming up even after a reboot, in both TTY and Konsole. In my konsole profile - it’s showing /bin/bash though.
If I open konsole or TTY now, it STILL comes up with fish. Now here’s where I keep getting stuck. I have tried before a restart, after a restart, still in fish, and exiting fish with /bin/bash
yay -R fish
It goes through no problem. Executed fine and uninstalls.
EVERY SINGLE time I uninstall it → I’m left in a disaster. I Immediately no longer have use of Konsole or TTY. I have had to timeshift backup (via the app → timeshift --restore is unavailable since I have no way of using pacman). Root password still works - because I can still use timeshift/gparted. User password still works as I can log in no problem.
Can anyone help?
I’m on a fresh timeshift. The ONLY thing I’ve done so far is step one - chsh -s /bin/bash
What’s next?
EDIT: If applicable: I changed this to my default shell following their help guide as follows.
Also - In complete disclosure → this is Arch(fi) KDE, not EOS.
# /etc/profile
# Set our umask
umask 022
# Append "$1" to $PATH when not already in.
# This function API is accessible to scripts in /etc/profile.d
append_path () {
case ":$PATH:" in
*:"$1":*)
;;
*)
PATH="${PATH:+$PATH:}$1"
esac
}
# Append our default paths
append_path '/usr/local/sbin'
append_path '/usr/local/bin'
append_path '/usr/bin'
# Force PATH to be environment
export PATH
# Load profiles from /etc/profile.d
if test -d /etc/profile.d/; then
for profile in /etc/profile.d/*.sh; do
test -r "$profile" && . "$profile"
done
unset profile
fi
# Unload our profile API functions
unset -f append_path
# Source global bash config, when interactive but not posix or sh mode
if test "$BASH" &&\
test "$PS1" &&\
test -z "$POSIXLY_CORRECT" &&\
test "${0#-}" != sh &&\
test -r /etc/bash.bashrc
then
. /etc/bash.bashrc
fi
# Termcap is outdated, old, and crusty, kill it.
unset TERMCAP
# Man is much better than us at figuring this out
unset MANPATH
I know enough bits of code that exec fish meant that. But why would that not be part of the uninstall instructions? It’s like cancer.
I’m making a new timeshift backup now. I’ve got a lot of updates to go. My restore point was 6/1 just prior to the pacman 6 update. So I’ve got pacnew files, jack, etc to do again. But, at least my install was salvaged.
I use fish but I run it as an interactive shell. I didn’t switch the default shell it’s still bash shell I call fish from ~./bashrc using exec fish. It’s not a good idea to switch to fish as the default because it’s a bit different from the other shells.
In fact it’s very bad idea to do system wide anything other than bash on Arch system (including POSIX compliant shells)…
Because of stupid Arch not very strict policies
Those scripts don’t run in your user’s shell. They shouldn’t break no matter what your user shell is.
That is a different issue. The issue there is if you replace /bin/sh with a different implementation, those scripts break because they aren’t POSIX compliant.
I’m in a PM thread with a couple friends, and that’s one of the questions that keeps coming up. I absolutely cannot recall doing it but that doesn’t mean I didn’t. It would have been my third or fourth install at least because I never put anything new on my main machine without a successful run through on a practice machine. The reality is I must have done it somehow. The entire install process I did using their help manual. I don’t remember ever going to the wiki where I would have gotten that information.
But that’s a very good question and I don’t answer to it other than I must have done it I just don’t remember.
Reality is it’s my machine and the glory of arch is that it’s my fault. However it got there it was my fault and I should have known.
My complaint there was that some scripts from the Arch repos contain Bash-specific commands, yet their command interpreter is designated as #!/bin/sh which should only be used for strictly POSIX-compliant scripts. POSIX script is, of course, a subset of Bash, so all POSIX-compliant scripts will run with Bash, but on Arch one cannot (without a great deal of effort) use a more minimalist POSIX-compliant shell like Dash, because Dash will error on Bash-specific commands. Since Dash is up to four times faster than Bash, I would like to use it as /bin/sh, but alas, it is not meant to be on Arch, since some script authors rely on the fact that on Arch /bin/sh is Bash.
This has nothing to so with Fish, though, which is specifically an interactive shell which is not POSIX-compliant. Symlinking Fish as /bin/sh would be incredibly stupid and would break all scripts on your system, regardless whether they are strictly POSIX-compliant (like on Debian), or contain Bashisms, like on Arch.
