Recently I installed Zshell instead of Bash. During this, then I saw that my $PATH was 7 miles long, - so I decided to try and clean it up a bit. When I uninstalled rvm (by running rvm implode followed by rm -rf ~/.rvm) then when I restarted my terminal, I now see an error:
If I just press ENTER, then the error remains. But if I do any other command, then it disappears (ls, echo, source ~/.zshrc - you name it).
If I reboot iTerm (or start a new tab), - then the error re-appears.
The error is not being showed, - so if I activate another theme, then I can't see if there is an error.
My gut feeling tells me, that it has something to do with my path, but I'm not sure. My path is waaay shorter than before RVM was installed.
If i rename my ~/.zshrc-file, then the Powerline9k-theme gets deactivated, so I can't see if the error actually still appears or not. But I have tried it... Then a theme-less zshell just start up.
Any idea how to fix it or how to debug it?
EDIT
I just realized that it could actually have been a left-over-error, from back when I was running bash, - so I added that tag as well.
If the visual blemish disappears as soon as you execute any command as you say so, just place an echo -n at the end of your .zshrc as a quick and easy fix, if you are not up to the task of debugging and potentially causing more problems on your machine.
The issue isn't worth your time ;)
Edit: Apparently the above didn't work. See comments.
If you are interested in debugging, a good starting point would be to place set -xe (print every line that is executing and abort on any line that exits nonzero) at the beginning (after the shebang line, or as flags in the shebang) of each configuration script that is executed when you start a new interactive shell.
Also consider set -xeuo pipefail to additionally catch and abort on usage of unset shell variables and commands that return nonzero inside pipes (e.g. set -e will not abort on false | true because the overall line exited with status 0, but -o pipefail will abort on such a line). It is worth noting that these flags are bash features, but since zsh is a feature superset of bash, they work in zsh too.
Have look at their documentation on github, relevant fragment is here.
Solution:
In your ~/.zshrc find variable called POWERLEVEL9K_LEFT_PROMPT_ELEMENTS and remove rbenv.
Explanation:
The default value of POWERLEVEL9K_LEFT_PROMPT_ELEMENTS is (context dir rbenv vcs), and it is likely that rbenv is the segment producing the error - after you uninstalled rvm that segment can't execute.
Uninstall all apps that use the path and reinstall. It's the only way. Instead of rm, you use should create an alias that has a trash can.
Related
I have looked at duplicate questions. Nothing has worked.
I use Gitbash, and when using Cygwin, I source the gitbash prompt (/Git/etc/bash.bashrc) to display the same prompt. In Gitbash, the prompt works. In cygwin, the output line wraps. For example:
[ "$python_version" ] && python_version='\[\033[95;38;5;227m\]🐍'"${python_version##* } "
This line causes a wrap (only in cygwin) when appended to PS1. The minttyrc and color settings are exactly the same. Removing the color, which I think is the problem, fixes the wrap. However, I believe everything is escaped correctly, and as it doesn't wrap in gitbash, I don't know what the problem is.
The color here seems to be the issue, as removing it fixes it. But why? What is so different about the terminals? I also wonder if it could be an issue with an early escape, but PyCharm's shellcheck says it's all fine.
Wrapping example:
Cygwin:
⬢14.7.0p/new 🐍3.8.3 (venv) ❯
GitBash (ideal output):
~/Desktop/new 🐍3.8.3 ⬢14.7.0 (venv) ❯
It only occurs within the prompt (PS1 variable, aka PROMPT_COMMAND); not when actually typing out commands in the terminal.
Answer: Cygwin is trash (excuse the exaggeration). It has so many utilities but many have encountered bugs like this, and it is really a shame. I uninstalled it, removed its variables from PATH, and with C:\Program Files\Git\bin added to such, I could now ssh in using ssh -t user#host bin "bash -l". This gave me a correct prompt, in ssh or not, with no wrapping; I was able to install other utilities, such as g++, using MinGW. I hope Cygwin gets things sorted out soon, as I debugged in every single way; changed no code, uninstalled it, and then had a successful output.
edit : I ended up upgrading to macOS Catalina yesterday and replacing bash with zsh. One thing that should be noted is that the stackcommand worked previously, but despite all the tinkering not ghci
After deleting all the files that had anything to do with Haskell, I retried running curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
This second time there was an error with the command line tools so I had to install them manually with xcode-select --install. After rerunning the curl, I added the path to the environmental file to my zsh profile manually with :
. "$HOME/.ghcup/env"\
echo '. $HOME/.ghcup/env' >> "$HOME/.zshrc"
Here is the content of the env file :export PATH="$HOME/.cabal/bin:/Users/agnel/.ghcup/bin:$PATH"
Now everything seems to be working (I never reinstalled stack, but I think I might leave that to the side while I learn the basics of the language).
I installed the Haskell Platform yesterday but am having a hard time getting it to work correctly.
The firsts steps I did are:
curl -sSL https://get.haskellstack.org/ | sh
curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
On step 1. the instructions said to append /Users/.../.local/bin the PATH variable (which I did in /etc/paths. On step 2, the script was supposed to pop up a dialog box (and didn't) when installing the necessary command line tools. It also said to rerun the script once complete (which I did). The script also said I should adjust my PATH variable, and source /Users/.../.ghcup/env in my shell configuration. It asked to this automatically but failed having not found the ~/.bashrc File. (I read that on Mac in contrary to linux, only .bash_profile is loaded upon opening of a terminal window so I adjusted the path variable there manually. I've spent forever messing around with the path variables and every time I try and run "$ ghci" I get the same -bash: ghci: command not found error message. If anyone has a solution to this problem I would be very grateful for an answer. If not, could someone with a working distribution of Haskell on their computer show me what their path variables look like?
Thanks!
A simple solution would just be to restart your terminal and you are good to go.
After installing the Haskell platform for the first time on a new mac with Catalina, I also got
~> ghci
zsh: command not found: ghci
What worked in my case was to use, instead of the plain ghci,
stack ghci
To get back the familiar behaviour, I created in my homedirectory a file named .zshrc containing
alias ghci='stack ghci'
If you open a new terminal, this file will automatically be executed.
I'd be interested to know if there is another solution.
Check if the ghcup command is working or not.
If not, make sure the .zshrc file has command for execution of ghcup. It should look something like this -
[ -f "/Users/myusername/.ghcup/env" ] && source "/Users/myusername/.ghcup/env" # ghcup-env
If the file exists, simply restarting terminal will work.
If it is still not working, set GHC as default using ghcup - follow this
Every time I try to run anything in GDB, I am met with the following error message:
Error: No such file or directory
During startup program exited with code 127.
Searching around on here, I found out that this can occur when the SHELL variable is not properly set, and indeed running export SHELL=/bin/bash --login before running GDB solves the problem for the current session.
However, this is in spite of the fact that echo $SHELL spits out the desired value already. If I look closer at the command GDB is trying to execute, it typically takes the form:
/path/to/mybin -c exec /path/to/mybin --my --opts
instead of
$SHELL -c exec /path/to/mybin --my --opts
That is, GDB somehow resets SHELL to point to whatever executable I am passing it before it starts running. (I use the format gdb --args /path/to/mybin --my --opts to start GDB.) Before and after the run, SHELL has the correct value. If I try to debug three different executables in a row, each of those three executable will be used as it's own shell, obviously producing failures. If I even once run export SHELL=(acceptable shell), it will work properly for the remainder of the session.
None of my shell dotfiles (.bashrc, .profile, etc) make any reference or modification to the SHELL variable. This behavior seems completely incomprehensible to me. Does anyone have an idea what may be going on?
I am using gdb-7.7.1 in bash-4.3.11 on Ubuntu 14.04.
EDIT: I was wrong about an important detail. Running export SHELL=/bin/bash --login actually does not correct it. The same problem persists if I do that. (This is also the default value in my shell and what I see if I enter show env SHELL when gdb is not working. However, setting export SHELL=/bin/bash does correct the issue, so the login shell is somehow the issue, I guess.
The problem is almost certainly with your ~/.bashrc but it's hard to guess what it is from your description.
Step 1:
mv ~/.bashrc ~/.bashrc.save.20170411
logout and back in verify that GDB works just fine
Step 2:
Copy parts of .bashrc.save.20170411 to ~/.bashrc, and repeat logout/login cycle, until GDB stops working again.
Step 3:
Now you know part is causing trouble, and can ask a better question if you still don't understand why that chunk of .bashrc is problematic.
Whenever I start up Terminal on my Macbook Air, I get this message:
-bash: ≈: command not found
How do I fix this error? I'm running Mavericks version 10.9.4 if that helps at all.
EDIT: Fixed this error by using the bash -x method, found out it was a random '≈' character left in ~/.profile that needed to be deleted. Thanks for the answers :)
To debug you can try this:
bash -x -l
(the -l might not be needed).
I definitely agree with Barmar, there is something in your bash startup scripts.
There is not a great way to do this, but here is the protocol to remedy it.
Confirm it is your bash profile by first killing the process with a control + C if it is hung. Then do a source ~/.bash_profile and see if you get that same error.
Backup your bash profile cp ~/.bash_profile bashprofile.txt
Then comment out part of your bash profile. With text wrangler you can do a command + slash.
Save, then do a source ~/.bash_profile and see if the error still prints.
Repeat with different areas of the script until you have isolated the infected region.
I installed RVM system wide on Fedora 14, and I pretty much followed the guide to the letter. When I tried it out though:
$ type rvm | head -n1
rvm is /usr/local/bin/rvm
Most commands appear to work fine, but changing Rubies doesn't work properly. I have to keep logging off and back in for it to switch, and that doesn't seem to work every time.
Here's exactly what I did:
bash < <( curl -L http://bit.ly/rvm-install-system-wide ) as root
add my own user to the rvm group
add
[[ -s "/usr/local/lib/rvm" ]] && source "/usr/local/lib/rvm"
to the very end of ~/.bash_profile.
Log off and back in.
If I understood correctly, this is exactly what should be done. I made sure .bashrc doesn't contain a return statement.
I figure this has something to do with the environment variables that RVM sets up. Any thoughts?
Well, I found the answer.
The problem was that I was not running bash as a login shell. This basically means it doesn't execute my ~/.bash_profile.
Embarrassing thing is, on the very, very last point on the troubleshooting guide is written:
If you are using GNOME on Red Hat, CentOS or Fedora ensure that the Run command as login shell option is checked under the Title and Command tab in Profile Preferences. After changing this setting, you may need to exit your console session and start a new one before the changes take affect.
Looks like I didn't actually read the whole thing, but Wayne does need to put "Make sure you're running the shell as a login shell" on the guide itself, not just on the troubleshooting section.