Error when try installing budspencer theme for fish shell - shell

My fish conf (.config/fish/config.fish)
set -e fish_key_bindings
set -U fish_key_bindings fish_vi_key_bindings
set fish_path $HOME/.oh-my-fish
set fish_theme budspencer
. $fish_path/oh-my-fish.fish
result in error: https://gist.github.com/LuizCarvalho/925de989c306828a410a
if I remove theme and sets result in:
desenvolvimento#dp-inf015:~$ fish
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
fish: Unknown command “fish_vi_key_bindings”
Standard input: begin; fish_vi_key_bindings ;end
^
in . (source) call of file “-”,
called on standard input,
in function “__fish_reload_key_bindings”,
called on line 209 of file “/usr/share/fish/functions/__fish_config_interactive.fish”,
in function “__fish_config_interactive”,
called on line 108 of file “/usr/share/fish/config.fish”,
in function “__fish_on_interactive”,
called on standard input,
in event handler: handler for generic event “fish_prompt”
If I uninstall fish, oh-my-fish and all file conf and install again, error keeps happening...
How I can solve this?

vi bindings are in an upcoming release, but not yet in a public one. That is why you get the error.
If you want to get vi bindings working and are willing to live on the edge, you can install the latest fish from trunk. If you are using homebrew, run brew install fish --HEAD. Or if you prefer to do it the old fashioned way, there's build instructions here.
Alternatively, if you understandably prefer to remain on the most recent public release, you should delete the fish_vi_key_bindings lines from config.fish.

Related

-bash: ghci: command not found (Haskell interactive shell, Haskell installation )

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

Zshell starting with an error (showed in Powerline9k-theme)

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.

Fixing <right arrow> in bash vi input mode. Cannot type beyond last character

I'm trying to use vi mode in bash. via the .inputrc (on OSX):
set editing-mode vi
In vi insert mode, the right arrow key moves the cursor to the right, but it stops on the last character in the line. If the cursor is past the end of the line, it moves the cursor to the left. So, in sum, the farthest right you can go is to the last character in the line.
$ cd /usr/locl/bin
# Move the cursor to the middle of the line, and fix something there
$ cd /usr/local/bin
# Now move the cursor back to the end, and write a character (/)
$ cd /usr/local/bi/n
As shown above this means you cannot edit the end of the line without going into command mode (and using 'a').
I found an article which seems to indicate the version of readline/bash might be the problem. However I used brew to upgrade bash (GNU bash, version 4.3.42), and even tried to install and link readline (6.3.8), as recommend by that site. But no luck. Its possible the upgrade was done incorrectly.
This means I'm looking for one of the following:
The proper way to upgrade bash and readline in OSX terminal
A way to check the versions of bash/readline that OSX is actually using
Another fix for this bug (somehow passing in the virtualedit=onemore option in the inputrc)
Indications that the latest versions of readline might have re-introduced the bug, and solutions.
Also: if theres a similar thing with editrc
Note: I'm looking to make readline in bash act near identical to the default (for others who periodically use my terminal), but allow me to use vim mode. This means I don't need workarounds, but fixes.
Answer here: https://unix.stackexchange.com/a/222506/198846
Apparently it's a bug in the bash version shipped with OSX (3.2), it's fixed in 4.3 according to that answer. Use bash --version to check your bash version.
To fix, update bash, e.g.
macports: sudo port install bash
brew: brew install bash
Once installed bash --version will show it's updated (assuming standard brew/macports paths at the start of your $PATH)
You then have to change your default login shell (in System Preferences->Users & Groups->right click your user->advanced options->login shell) to the path of the new bash:
(default) macports: /opt/local/bin/bash
(default) brew: /usr/local/bin/bash
Changing the default login shell step is required even if which bash shows the macports/brew one.
All credit to the answer linked above.
Can't you edit .bashrc itself instead to use vi mode? The command set -o vi does it in my case (you are in edit mode initially). Also remove the .inputrc edit as the two may actually interact nefariously afterwards.

Textmate error running commands after Yosemite upgrade

I recently upgraded my Mac to Yosemite, and now many Textmate 2 commands that I used to use all the time are failing and giving the following error—in this example I tried to run the "Comment line" command by pressing ⌘/:
The same thing happens for "Run", "Toggle String / Symbol", and many other Textmate commands.
When I click "Edit Command", it takes me to a script the first line of which is:
#!/usr/bin/env ruby18
If I take the 18 off of that, it seems to work, but I would have to do it for every command. There must be a better way.
I use rbenv and long ago I set my TM_RUBY variable to $HOME/.rbenv/shims/ruby, but setting or unsetting that doesn't seem to make a difference now. I also tried adding that path to TM's PATH variable. Any other ideas?
I figured out an answer. Running ruby18 at the command line produced a "command not found" error. So I created a symlink to the system ruby (which is ruby 2.0) with that name:
ln -s /usr/bin/ruby /usr/local/bin/ruby18
That seems to have worked. Still not sure if that's the best solution. Open to any other ideas.

Customizing Octave

I am just starting with Octave and running it on my terminal so far.
Everytime I open the prompt, my command line starts with :
octave-3.4.0:1>
So I use the following to make it shorter and easier to read:
PS1('>> ')
How can I change my settings to exectute this code automatically everytime I open octave?
How top of this, is there a way to change my terminal settings to open Octave when I enter 'Octave'? The way I do it now is by using
'exec 'path/to/octave/
Thanks
You can create edit ~/.octaverc file that contains all the commands you want to execute when Octave starts up. This file is exactly like a .m Octave script file.
Just add PS1('>> ') to your ~/.octaverc file. You can use your favorite text editor or use echo on the command line:
$ echo "PS1('>> ')" >> ~/.octaverc
After that you can see the ~/.octaverc file :
$ more ~/.octaverc
It should contain the following line :
PS1('>> ')
For the second question, I am not sure if you're on OSX or Ubuntu or something else. If octave is in your search-path then you should be able to start Octave by just trying octave. Try these commands to find out what octave points to
$ which octave
/usr/bin/octave
$ type octave
octave is /usr/bin/octave
If somehow, octave is not your PATH search-path, this could be because you installed Octave at a non-standard location. You can do one of two things:
Add the folder containing your Octave executable to your PATH search-path. In bash, you can do this by adding the following line to your ~/.bashrc (or ~/.profile on MacOSX):
export PATH=~/path/to/octave/folder:${PATH}
You can create a soft symlink to your octave executable.
ln -s /path/to/octave/executable octave
This will create a symlink in your current folder. Now, as long as you're in the current folder, you'll be able to type in octave and run Octave. If you want to be able to run Octave from anywhere (and not necessarily the current folder), you need to add the current folder to your search-path (see point 1 above).
Consider using the latest release which is GNU Octave 3.8. It comes with a nice GUI if you're familiar with MATLAB.
You can customize the PS1 and any other settings on your ~/.octaverc. Please read the documentation on startup files: http://www.gnu.org/software/octave/doc/interpreter/Startup-Files.html
As for calling Octave from anywhere, you need to set the PATH variable in your shell to append the directory where Octave is installed, for instace in Bash:
export PATH=$PATH:/path/to/octave-3.8/bin
Start GNU Octave with option --traditional (but I'm not sure if this was already implemented in 3.4.x).
$ octave --traditional
GNU Octave, version 3.8.1
Copyright (C) 2014 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. For details, type 'warranty'.
Octave was configured for "x86_64-unknown-linux-gnu".
Additional information about Octave is available at http://www.octave.org.
Please contribute if you find this software useful.
For more information, visit http://www.octave.org/get-involved.html
Read http://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.
>> version
ans = 3.8.1
>>

Resources