autojump on ArchLinux for some reason is not working in zsh.
Although If I switch to bash it works fine.
$ sudo pacman -S autojump
autojump: does not work on zsh
$ source /usr/etc/profile.d/autojump.sh
$ j
zsh: command not found: j
$ source /usr/etc/profile.d/autojump.bash
$ j
zsh: command not found: j
autojump: works on bash
$ bash
(bash) $ source /usr/etc/profile.d/autojump.bash
(bash) $ j
autojump: ...
My environment:
$ echo $SHELL
/bin/zsh
$ zsh --version
zsh 5.0.2 (x86_64-unknown-linux-gnu)
I use autojump on OS X with zsh, so it also doesn't look like a zsh specific issue to me.
Aren’t you supposed to use autojump.zsh instead?
Though from what I see the only thing autojump.sh is doing is sourcing autojump.zsh or autojump.bash from some place so it should work with .sh. Work if maintainers of arch have patched autojump.sh: it does not expect to find autojump in /usr/etc.
If it does not work with autojump.zsh, post the output of doing (set -x ; source /usr/etc/profile.d/autojump.zsh).
There is no /usr/etc/profile.d/autojump.zsh pushed when autojump is installed via pacman. I don't know why this is the case.
However, I performed, manual user installation and added autojump plugin in my zsh configuration that takes care of sourcing the file.
I have tried above the ways,but I solved this problem by add the
source ~/.autojump/etc/profile.d/autojump.zsh
because the I have not find the /usr/etc/profile.d/autojump.zsh
I had repeated trouble with Autojump in ZSH regardless of sourcing the .zsh version. I never found a decent fix and eventually chose to stick with ZSH and stop using Autojump.
My personal solution was to switch from Autojump to FASD. It has the same functionality of Autojump via the 'z' alias. It also allows for specifically jumping to either a file or directory.
FASD has been a reliable part of my ZSH setup and surpasses the functionality of Autojump. I wrote up my experiences with FASD at greater length on my blog at Civet.ws
Related
I've been making my first quicklisp project lately and I wanted to share it. I've put it on github, but not everyone has emacs + slime + quicklisp installed so I wanted to make an executable I could put with the code.
To do this I'm using buildapp and following the steps laid out in this stackoverflow answer.
$ sbcl --no-userinit --no-sysinit --non-interactive \
--load ~/quicklisp/setup.lisp \
--eval '(ql:quickload "ltk-colorpicker")' \
--eval '(ql:write-asdf-manifest-file "quicklisp-manifest.txt")'
$ buildapp --output out \
--manifest-file quicklisp-manifest.txt \
--load-system ltk-colorpicker \
--entry colorpicker
After running those commands I get the following error:
Fatal INPUT-ERROR-IN-LOAD:
READ error during LOAD:
The symbol "*SYSTEM-DEFINITION-SEARCH-FUNCTIONS*" is not external in the ASDF/FIND-SYSTEM package.
Line: 16, Column: 90, File-Position: 15267
Stream: #<SB-INT:FORM-TRACKING-STREAM for "file /home/nathan/quicklisp/local-projects/ltk-colorpicker/dumper-2SKVI5f7.lisp" {1001B70F83}>
The main problem here is that I don't even have a clue at how to begin to fix it. I've seen this gibhub issue, but that had to do with problems with Homebrew and it never even mentions buildapp. It's all very confusing. And I hope I could get some help.
Thanks in advance for any answers.
I can reproduce the error. As suggested in the comments, you can build an up-to-date version of buildapp as follows:
$ sbcl
* (ql:quickload :buildapp)
...
* (buildapp:build-buildapp
(merge-pathnames "bin/buildapp" (user-homedir-pathname)))
This build $HOME/bin/buildapp. When I use the new binary, there is no error anymore.
You can also avoid generating an executable (that can end up being outdated) by systematically calling the buildapp::main function from Common Lisp; you will then always have the version that corresponds to the current release of quicklisp:
* (buildapp::main
'("BUILDAPP" ;; argv[0] must exist but the value is not important
"--manifest-file" "/tmp/quicklisp-manifest.txt"
"--load-system" "drakma" "--output" "/tmp/test"))
Some extra info from my point:
The solution was to use the newest version of buildapp as #coredump mentioned. I updated by going to the github page, downloading the zip and doing the following commands at the point where buildapp is stored.
$ make
$ cp buildapp /usr/bin
(This of course only works on linux.)
This is not an elegant solution but buildapp hasn't updated in 4 years, I think it's a safe enough bet. I also made a mistake with the command. The --entry part is wrong. It should have been: `--entry ltk-colorpicker::main`` where main is a function that takes one variable since that's required by the spec.
Main is just this: (main (i) (declare (ignore i)) (colorpicker))
I've been using oh-my-zsh for a while and it's working great. I'd like to use the command-line fuzzy finder plugin so I enabled it in .zshrc:
plugins=(fzf)
However if "fzf" is not installed I get a warning when opening my terminal window:
[oh-my-zsh] fzf plugin: Cannot find fzf installation directory.
Please add export FZF_BASE=/path/to/fzf/install/dir to your .zshrc
Is there a way to hide that warning message? When I install fzf with "sudo dnf install fzf" the warning dissapears, but maybe I want to clone my dotfiles on a different computer where it is not available and it's not that important to be there.
you should first install fzf, in Mac and i use the following command to install brew install fzf
You need to have fzf installed to use this plugin; otherwise remove it. It won't do anything without first installing fzf. Sudo apt install fzf
You can put the plugins= line inside an if statement that checks for the presence of fzf in your path. For example:
if [[ -n $(command -v fzf) ]] ; then
echo "fzf found, loading oh-my-zsh fzf plugin"
plugins=(vi-mode fzf)
else
echo "no fzf was found in the path"
plugins=(vi-mode)
fi
command -v is similar to which, but is superior for this context as explained in this answer.
The -n makes the [[ ]] evaluate as true whenever the $() produces a non-empty output.
For me, it was also very important that brew itself was in Path of ~/.zshenv like so:
export PATH=/opt/homebrew/bin:$PATH
Installed FZF with brew on an M1 Mac.
Otherwise, the error occurs:
[oh-my-zsh] fzf plugin: Cannot find fzf installation directory.
Please add `export FZF_BASE=/path/to/fzf/install/dir` to your .zshrc
When you install fzf by using brew, it needs to be set brew env.
You can solve to set PATH for fzf before the line of plugins=(fzf) in .zshrc file.
But, I recommand creating "$HOME/.zprofile" as following.
For m1 Mac.
# Set PATH, MANPATH, etc., for Homebrew.
eval "$(/opt/homebrew/bin/brew shellenv)"
For, intel Mac
# Set PATH, MANPATH, etc., for Homebrew.
eval "$(/usr/local/bin/brew shellenv)"
I want use oh-my-zsh jhipster plugin. I followed Jhipster guidelines using
http://www.jhipster.tech/oh-my-zsh/
After setting up everything, whenever i try to use command jh, it doesn't work. I get response
zsh: command not found
I'm not familiar with shell scripting language. Please help me.
Yes, you need to:
install zsh
install oh-my-zsh
configure your default shell to use zsh -> it is important
install jhipster-oh-my-zsh-plugin
Here the commands we do for our jhipster-devbox (on Ubuntu):
https://github.com/jhipster/jhipster-devbox/blob/master/scripts/setup.sh#L100-L112
Did you installed zsh?
I am not familiar with MAC, but it should be something like:
brew install zsh zsh-completions
here some more in-deep instructions:
http://sourabhbajaj.com/mac-setup/iTerm/zsh.html
I have been using oh-my-zsh for a while now and the docker plugin as recently stopped working for me for some reason.
I checked my ~/.zshrc file and the plugin is included
plugins=(git colored-man colorize github jira vagrant virtualenv pip python brew osx zsh-syntax-highlighting docker)
I checked the ~/.oh-my-zsh/plugins/docker directory and there is a _docker file in there. Yet when I type docker and press Tab, I get none of the autocomplete shortcuts that I used to get.
I can confirm that my git plugin works just fine but not the docker plugin. Tried doing exec zsh and source ~/.zshrc and restarted my terminal but no luck.
Am I missing something?
You might want to try and remove any .zcompdump-(...) files you may have on your user's home directory - using something like rm ~/.zcompdump* on a terminal, or some file browser - and then reload the .zschrc file with the command source ~/.zshrc or restart the terminal - whichever works best for you. See this
Then see if it works.
It seems oh-my-zsh is not loading plugins/docker/_docker file. You must add it to ~/.zshrc in an another way.
Add these lines to your ~/.zshrc file:
fpath+=($ZSH/plugins/docker)
autoload -U compinit && compinit
For me it was simply the case that I needed to launch Docker for the first time from spotlight on my Mac in order for Docker for Desktop to get the access it needed. Then the docker version command worked just fine.
Follow these steps if you are using oh-my-zsh and autocomplete is not working:
Make the following three links:
ln -s /Applications/Docker.app/Contents/Resources/etc/docker.zsh-completion /usr/local/share/zsh/site-functions/_docker
ln -s /Applications/Docker.app/Contents/Resources/etc/docker-machine.zsh-completion /usr/local/share/zsh/site-functions/_docker-machine
ln -s /Applications/Docker.app/Contents/Resources/etc/docker-compose.zsh-completion /usr/local/share/zsh/site-functions/_docker-compose
Either add autoload -Uz compinit; compinit to .zshrc or run in your shell:
echo "autoload -Uz compinit; compinit" >> .zshrc
In my case: Windows 10 + WSL2 + Hyper
I was having this error because I stopped Docker on Windows... Starting it again makes the error disappear in Hyper (thus, also in ZSH).
No .zshrc changes or additional commands to add inside.
#youhans's solution worked for me permanently. You might have permission issue to make needed adjustment on "zshrc". I have changed the permission to "read and write" and added the code snippet from #youhans's response to the end of "zshrc" file. Now completion system always works.
Before I had to type below snippet in command line whenever open a new terminal.
autoload -Uz compinit && compinit
In my case it occurred because of an alias. I had defined alias docker=docker.exe.
Removing that did it work again.
System & Environment
O.S.: Windows 10 Home, x64
Shell: Zsh (on Gitbash)
I think you may be missing ,'s in between each plugin.
plugins=(git, colored-man, colorize, github, jira, vagrant, virtualenv, pip, python, brew, osx, zsh-syntax-highlighting, docker)
Alternatively you can place each plugin on a separate line:
plugins=(
git
colored-man
colorize
github
jira
vagrant
virtualenv
pip
python
brew
osx
zsh-syntax-highlighting
docker
)
I want to call ShellCheck, a Haskell program for linting shell scripts, from a Makefile.
When I install ShellCheck via cabal install, it is installed as ~/.cabal/bin/shellcheck. So, I have configured Bash accordingly:
$ cat ~/.bashrc
export PATH="$PATH:~/.cabal/bin"
$ source ~/.bashrc
$ shellcheck -V
ShellCheck - shell script analysis tool
version: 0.3.4
license: GNU Affero General Public License, version 3
website: http://www.shellcheck.net
This enables me to run shellcheck from any directory in Bash. However, when I try to call it from a Makefile, make cannot find shellcheck.
$ cat Makefile
shlint:
-shlint lib/
shellcheck:
-shellcheck lib/**
lint: shlint shellcheck
$ make shellcheck
shellcheck lib/**
/bin/sh: 1: shellcheck: not found
make: [shellcheck] Error 127 (ignored)
I think that make is not receiving the same PATH as my normal Bash shell. How can I fix this?
Try using $HOME, not ~:
export PATH="$PATH:$HOME/.cabal/bin"
The ~-means-home-directory feature is not supported in pathnames everywhere in all shells. When make runs a recipe it doesn't use the user's shell (that would be a disaster!) it uses /bin/sh always.
On some systems (particularly Debian/Ubuntu-based GNU/Linux distributions) the default /bin/sh is not bash, but rather dash. Dash doesn't support ~ being expanded in the PATH variable.
In general, you should reserve ~ for use on the command line as a shorthand. But in scripting, etc. you should always prefer to write out $HOME.
ETA:
Also, the double-star syntax lib/** is a non-standard feature of shells like bash and zsh and will not do anything special in make recipes. It is identical to writing lib/*.
You can force make to use a different shell than /bin/sh by adding:
SHELL := /bin/bash
to your makefile, for example, but this makes it less portable (if that's an issue).