I'm quite sure is something dealing with my Oh-my-zsh configuration, but I can't figure out what it is.
When I use a "#" symbol in my git command (but on everything else too, like 'ls #2' for instance) I get 'bad pattern' error or 'no match found'
I guess is about counting something, but I can't find where to configure it.
I.E.
➜ demo git:(adlist) git push origin adlist#3
zsh: no matches found: adlist#3
or
➜ demo git:(adlist) git push origin #3-adlist
zsh: bad pattern: #3-adlist
Use single quotes:
git push origin 'adlist#3'
git push origin #3-adlist
In zsh # is used for pattern removal. See: http://zsh.sourceforge.net/Guide/zshguide05.html under the heading Standard forms: pattern removal
You can unsetopt EXTENDED_GLOB, and this should stop # being interpreted as a part of a pattern.
If you really want to keep most of the features of EXTENDED_GLOB, but want to disable # being used for patterns, then you can disable -p '#' (you have to single quote the # argument, so that it doesn't get expanded like a pattern). This certainly works in my zsh installation, version 5.7.1, even though it is not documented in zshbuiltins(1).
Open your zshrc file:
vi ~/.zshrc
Add into end of file:
unsetopt INTERACTIVE_COMMENTS
unsetopt BAD_PATTERN
Effect your file:
source ~/.zshrc
Restart your terminal and enjoy it.
Related
I recently found this command line tool called fzf. I installed it according to the instructions and it does work, except for the CTRL-T key binding. Even though, I installed the special stuff with the key bindings as per their instructions, and I also tried installing fzf downloaded from the git repo as opposed to via homebrew, all the CTRL-T key binding does, still, is swap the last two characters.
I found this discussion about this, but none of the answers offered worked for me.
edit: you can see it in the first video here what I want to achieve.
edit 2: I'm using the Terminal of MacOs.
I use zsh with Oh My Zsh on Mac.
If I put fzf before vi-mode in the plugin setting in .zshrc like
plugins=(... fzf ... vi-mode ...)
Ctrl-t does not work showing ^T. Ctrl-r does not work, either.
But, if fzf comes AFTER vi-mode like
plugins=(... vi-mode ... fzf ...)
no problem arises.
If you clone fzf from the repository it contains a file called fzf/shell/key-bindings.zsh which refers to
fzf-file-widget() {
LBUFFER="${LBUFFER}${__fsel}"
local ret=$?
zle redisplay
typeset -f zle-line-init >/dev/null && zle-line-init
return $ret
}
zle -N fzf-file-widget
bindkey "^T" fzf-file-widget
the Control-T keybinding. This is normally sourced by your .zshrc
[ -f ~/.fzf.zsh ] && source ~/.fzf.zsh
which should contain its reference in .fzf.zsh:
source "$HOME/.fzf/shell/key-bindings.zsh"
If your keybinding does not work then your keybinding may be overwritten by your zshrc or may not be invoked by your zshrc.
If you are using zsh-vi-mode, then replace this line
[ -f ~/.fzf.zsh ] && source ~/.fzf.zsh
with this
zvm_after_init_commands+=('[ -f ~/.fzf.zsh ] && source ~/.fzf.zsh')
From zsh-vi-mode GitHub page
Psst! if you use fzf-tab, you might want to enable that also
zvm_after_init_commands+=('[ -f ~/.fzf.zsh ] && source ~/.fzf.zsh && enable-fzf-tab')
I put the below script in my .zshrc and sourced it using source ~/.zshrc
if [ -x "$(command -v fzf)" ]
then
source /usr/share/fzf/key-bindings.zsh
fi
and now key bindings (CTRL-T, CTRL-R, and ALT-C) work for me.
got the above script from how to enable hotkeys for fzf
explanation
you have key-bindings.zsh inside /usr/share/fzf or a few directories deeper.
Above script only sources key-bindings.zsh if fzf is installed.
rest of the working is part of the key-bindings.zsh, which frankly I did not bother to
understand.
OS: Manjaro GNU-Linux
I have noticed CTRL-T does not work (in bash) when I have the "vi mode" enabled by set -o vi.
I managed to make the CTRL-t key combo work as desired. There was one step I had missed.
After installing useful keybindings and fuzzy completion with /usr/local/opt/fzf/install, I updated fzf.bash manually with [ -f ~/.fzf.bash ] && source ~/.fzf.bash. After restarting the Terminal, it now works.
Edit: Also, this line needs to be added to your .bash_profile or .bashrc: source ~/.fzf.bash.
I'm trying to write a function quickgit that automatically adds, commits, and pushes with the added benefit of the commit message coming from fortune. I have the following script:
function quickgit
git add --all
git commit -m (fortune)
git push
end
Which works except the commit message is "(fortune)" instead of being a message from fortune. How do I make sure that fortune is run and expanded in my fish function?
fish has enough issues with the finer points of getting quoting just right that I'd avoid using it in scripts entirely. (See https://github.com/fish-shell/fish-shell/issues/159)
I was unable to reproduce your exact issue, but ran into ones of my own around multi-line fortunes. (see the referenced bug)
That being said, for your use case you can avoid it entirely with:
function quickgit
git add --all
fortune | git commit -F -
git push
end
Command substitution splits the output of the command on newline boundaries by default. So a multi-line fortune will pass multiple arguments to the git commit -m. That means only the first line will be handled by the -m option and the second thru n'th lines will end up being treated as file names. Try adding set -l IFS to your function to inhibit that splitting. Another approach is to capture the output in a var then interpolate the var:
set -l fortune (/usr/games/fortune)
git commit -m "$fortune"
But note that will replace each newline with a space.
Whenever i push through git all my bash scripts seem to be corrupted with the \r character. It doesn't affect the code, but it just adds a significant amount of noise to my work. Looked all over the web, but can't seem to find a solution.
Example:
echo "*************************************************************************"\r
^
Every line in my bash scripts are always ended with this special character. I use STS on Windows 7. Any ideas?
Put this two lines into your .gitconfig file in the root of your repo or into your home if you need to make this settings global :
[core]
eol = lf
You can find more about this here : https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
Is there a way to ask Mercurial to read most/all of the commands, options, and arguments that I want to give it from a response file, instead of passing them on the command line?
For instance, instead of this:
hg commit -m "commit message" --INCLUDE file1 --INCLUDE file2 ...
I would create a text file containing
-m "commit message" --INCLUDE file1 --INCLUDE file2 ...
and then ask Mercurial to read it with this (hyphotetical) syntax:
hg commit #responses.txt
The reason I'm asking is that I'm creating a wrapper library for .NET around the Mercurial command line client, and this question on SO got me worried that the length of the command line might be a problem for me at some point: “Resulting command line for hg.exe too long” error in Mercurial.
There isn't a built-in way to do this as far as I know, but I think there is a way you can build what you need.
Use the Mercurial internal API and write your own wrapper script. Rather than trying to get it to read any and all commands and options, it'll be a lot easier to stick to your specific goal (i.e. "commit" and the options you need).
(Note the warnings on the API page. If this wrapper you're building is going to be distributed to other people, look into the licensing issue and have a plan for how to handle future Mercurial upgrades, which may break your wrapper.)
Here's a kludgy workaround...
Create a dummy, empty response file in the repo's .hg directory, for example .hg\response.
In the repo's .hg\hgrc, add the line
%include response
Before doing any repository operations, write the command line options to this response file. Use the [defaults] section to (I know it's deprecated) to specify your options.
[defaults]
commit = -m "This is a commit message" -I file1 -I file2 ...
(According to Microsoft's support, the maximum command line is 8,191 characters on XP and later. Might be useful to know if you even need to use this trick.)
I want to know if there's a way to turn off the default push, but keep the default pull when using Mercurial. I don't want to accidentally pollute the master repository by inadvertently pushing from an experimental repository.
I was able to solve this by putting the following in my .hg/hgrc file, but I was wondering if there's a better/official way.
[paths]
default = http://server/hg/repo
default-push = .
Your solution probably is the quickest and is certainly effective. If there's any official way it would be using a preoutgoing hook:
[hooks]
preoutgoing = bash -c 'read -p "Really push to $HG_URL? " -n 1 RESP ; [ "$RESP" == "y" ]'
which will ask you if you want to push and provide the URL to which it would go as a reminder.
I like your own answer of setting paths.default-push = . -- it is simple and it is clear that it will work.
Another option would be a pre-push hook:
[hooks]
pre-push = if [ $HG_PATS == "[]" -o $HG_PATS == "['default']" ]; then
read -p "Really push to default? " -n 1; echo
[ "$REPLY" == "y" ]
fi
(Here I'm taking advantage of how you can split a long value over several lines by indenting them in a Mercurial config file.)
A push to default looks this
% hg push
Really push to default? n
warning: pre-push hook exited with status 1
where I typed the n. The hooks checks for both no arguments ($HG_PATS == "[]") and a default as the argument ($HG_PATS == "['default']") and will only prompt you in those cases. The $HG_PATS variable was introduced in Mercurial 1.6.
PS: I saw you updated the question and asked for a solution in PowerShell, but I'm afraid I know nothing about that language. However, you should be able to lift the important concepts from this answer yourself.
The answer previously posted, in hgrc setting
default-push = .
is ALMOST but not quite correct. It can break, e.g. if you hg your home directory.
Here is the my current BKM to disable default-push:
I've embellished the idea of setting paths.default-push in ~/.hgrc, making it a little bit more self documenting and less error-prone - since, as I point out below, setting default-push = . does not always disable pushing.
in ~/.hgrc
[paths]
# my main project master repo
project-master = ...
#DISABLING IMPLICIT PUSH
# to prevent embarassment from accidentally pushing to the project master repo
# instead of, in my case, a repo that has fine grain commits
# that the rest of the team does not want to see in the project master repo
#default-push = .
# this works mostly, but NOT if you use hg on your home directory
# since '.' in ~/.hgrc seems to be interpreted as -R ~
#default-push = /NONEXISTENT_default-push_--_must_specify_push_target_explicity
# this works ok, but I can clean up the error message using blanks
# keeping this around because blanks in pathnames confuses many UNIX tools
default-push = /'NONEXISTENT default-push -- must specify push target explicitly'
# this amounts to disabling implicit push targets.