Get the fish outta here.

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.

Per their uninstall FAQ:

So my first step:

derek@t480s ~> chsh -s /bin/bash
Changing shell for derek.
Password: 
Shell changed.
derek@t480s ~> 

Done. No problem.

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.

It must still have the hook in it’s mouth? :rofl:

2 Likes

Make sure you aren’t launching fish in your .bashrc and that konsole is not set to open fish in your konsole profile.

Konsole profiles both 1 and 2:

.bashrc has one line:

source /etc/profile

/etc/profile is as follows:

# /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 found this in /etc/bash.bashrc - exec fish. . . . is this my problem?

#
# /etc/bash.bashrc
#

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

[[ $DISPLAY ]] && shopt -s checkwinsize

PS1='[\u@\h \W]\$ '

case ${TERM} in
  xterm*|rxvt*|Eterm|aterm|kterm|gnome*)
    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'

    ;;
  screen*)
    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033_%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'
    ;;
esac

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

if [[ $(ps --no-header --pid=$PPID --format=cmd) != "fish" ]]
then
	exec fish
fi

Yes :wink:

Remove those 4 lines

Just making 100% sure -

if [[ $(ps --no-header --pid=$PPID --format=cmd) != "fish" ]]
then
	exec fish
fi

Just flat out remove them?

Edit: I got tired of waiting for you. I tried it. . . and Konsole pulls up in bash (thank f*cking God, I’m so tired of seeing this nonsense.)

AND KONSOLE STILL WORKS

You’re a God amongst men.

Why the hell is that so difficult? No one should use fish ever. This thing sucks.

1 Like

Just for reference, those 4 lines basically say, “If you are not already running fish, switch to fish.”

1 Like

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.

Thanks as always!

2 Likes

I have fish installed, and I don’t have this “execute fish” snippet in /etc/bash.bashrc. I wonder how it got there in the first place.

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.

1 Like

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 :crazy_face:

1 Like

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.

Yes that’s what i’ve meant by system-wide…Basically anything that is not interactive shell and runs your POSIX scripts instead of bash :upside_down_face:

default word perhaps would be better though :thinking:

1 Like

I don’t know if there is such a thing as a system-wide shell, but if there is, changing it would still be OK.

The only way to trigger that issue is to replace /bin/sh with a different shell.

1 Like

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.

3 Likes

When we fish we “ALWAYS” blame the bait! :wink:

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