fzf not workign with git bash (installation via scoop) - bash

I installed fzf via scoop on windows 10 but unfortunately it works well on cmd but impossible to make it work on git bash. I found a similar topic here: Is it possible to use fzf (command line fuzzy finder) with windows 10 git-bash?
but i don't understand these commands at all.
I checked the shims( the Windows command-line installer.) files of fzf and I have this as path
path = "C:\Users\<user name>\scoop\apps\fzf\current\fzf.exe"
fzf works fine on cmd but I need the bash interpreter. It's very annoying, anyone have an idea?
When I write
`fzf --help`
the command is recognized on git bash, it means that the command works but it returns nothing.

For Windows 10 (git bash) - try winpty fzf
You can also set an alias in .bashrc:
alias fzf="winpty fzf"

Related

Why is $OSTYPE returning "linux-gnu" on Windows?

Problem
When I run a bash script on Windows:
bash my_script.sh
I get linux-gnu for $OSTYPE inside the script.
Why is this like this?
I assume that i have WSL installed is relevant here.
Tested in PowerShell and CMD.
Git bash is returning msys like expected! Thx #user1934428
Background
I want to start some python scripts from bash, but not inside WSL.
From my command line I reach different python versions on windows, but from inside the bash scripts it is using the one inside WSL (except for GitBash).
You're right, running the bash command in PowerShell or CMD will launch WSL to run your script. You confirm this (and see which version of WSL) by running cat /etc/issue in your bash script. Your WSL environment will have an independent set of environment variables (not just $OSTYPE). You can see this by comparing the output of Get-ChildItem -Path Env:\ in PowerShell to the output of env (after you launch bash from PowerShell).
I suspect that the python version discrepancy you're seeing is a result of the PATH variable in your WSL runtime not matching what you have set in your PowerShell environment. You can fix your version issue by setting an alias containing a path to the python executable you want to use by adding alias python=/c/path/to/python.exe to the start of your bash scripts.
Alternatively, you can use a tool like Cygwin or git-bash to run your scripts. I'm not sure if they will use the same path variables as Windows so you may need to set those manually too.

Run a shell script using Cygwin bash instead of Git Bash for Windows from Eclipse

Clicking on a .sh script inside Eclipse (on Windows) executes it using Git Bash for Windows. However, I'd like to use Cygwin bash instead.
There is an option which looks like this:
I removed the shown entry for Git Bash and added an entry with a path to the Cygwin bash executable. However, this doesn't change anything - Git Bash for Windows is still used - and after closing and opening Eclipse the Git Bash entry is there again.
How can I configure Eclipse to use Cygwin bash?
You could also use https://marketplace.eclipse.org/content/bash-editor
Here you can customize the command
A description how to launch the scripts can be found at
https://github.com/de-jcup/eclipse-bash-editor/wiki/FAQ#how-can-i-execute-shell-scripts-with-bash-editor
The plugin contains also an integrated bash debugger which should work with cygwin bash as well. For the debugger in action on a Windows 10 machine you can look at YouTube Video - Bash editor debugging on Windows 10. Here you can see the default configuration done to execut git bash. Of course you have to customize start command a bit, but I think it's feasable.
PS: I am the maintaner of the mentioned plugin

When I run the git-gui in git bash on windows 10 I get "line 3: exec: wish: not found"

I've been using git and the git gui command on windows for about 2 years with no issues. Recently, I installed ubuntu on windows 10 and enabled the windows subsystem for linx (wsl) and installed git in the ubuntu bash, thinking I'd run git command from there. Ever since, git is quite broken when I use the git bash as part of git for windows.
When I run git gui in the git bash prompt in git for windows I get
C:/Program Files/Git/mingw64/libexec/git-core\git-gui: line 3: exec: wish: not found
One thing I find really mystifying about the above output is that the slash before git-gui is a '\' backslash while the others are forward slashes, though it's probably irrelevent?
I can still successfully run git gui from the windows context menu (when I right click a folder).
Things I've tried:
uninstalled git from ubuntu
uninstalled ubuntu
uninstalled git for windows and reinstalled after restart
uninstalled git for windows, removed git folder from program files, and reinstalled after restart
installed wish by installing tk on windows https://tkdocs.com/tutorial/install.html#installwin
reinstalled git to C drive (avoiding the space in "program files" which can cause bugs).
Added c:\Git\mingw64\bin to my user path variable
activeTCl/bin (which contains the wish.exe) is on my system path. When I run 'wish --version' in git bash a little empty window pops up, wish seems accessible, whatever it is. Never needed wish or ActiveTcl to run git commands before, so I'm a bit mystified by that as well! Anyhelp would be appreciated! If wish is needed by git for windows why isn't it installed by the git for windows installer?
As requested, Here's the options I used when installing git for windows:
Installed to C:/Git
Components: ✔️ git Bash Here, ✔️ git Gui Here, ✔️ Associate .git* configuration files with the default text editor, ✔️ Associate .sh files to be run with Bash.
Use Visual Studio Code as Git's Default editor.
Path: How would you like to use Git form the command line? Git from the command line and also from 3rd-party software.
https transport backend: use the openSSL library
line endings: checkout windows-style, commit unix-style
terminal emulator: use MinTTY
extra options: ✔️ enable file system caching, ✔️ enable git credential manager, ✔️ enable symbolic links
did not opt for experimental built-in add -i/-p
I did a fresh installation of git with version 2.24.0.windows.2 with similar options as mentioned in the question.
I ran the which command on git-bash to get the path from where git-gui is being executed.
$ which -a git-gui
/cmd/git-gui
Check if /cmd is there in your PATH using echo $PATH in git bash or check if C:/Git/cmd is there in your PATH using echo %PATH% in Windows cmd. If not, then you can add it to your PATH variable (either Windows cmd or git-bash).
If the which command yields multiple paths, check if /cmd/git-gui executes well from git bash and remove the other paths(caution! refers to multiple paths found for git-gui) from the PATH variable.
I get the same error though when I assume that /cmd is not in my path
# Simulate an empty PATH variable
$ export PATH=:
# Run git-gui from git-core directory
$ C:/Git/mingw64/libexec/git-core/git-gui
C:/Git/mingw64/libexec/git-core/git-gui: line 3: exec: wish: not found
Another case where multiple paths exist for git-gui :
# Simulate PATH variable with the following directories
$ export PATH=/usr/bin:/mingw64/libexec/git-core/:/cmd
# Run git-gui
$ git-gui
/mingw64/libexec/git-core/git-gui: line 3: exec: wish: not found
# Lists the paths
$ which -a git-gui
/mingw64/libexec/git-core/git-gui
/cmd/git-gui
Note:
which command can be used to Write the full path of COMMAND(s) to standard output. and the argument
-a is used to Print all matches in PATH, not just the first
I found a closed issue on git for Windows GitHub repository. Seems unrelated at first sight, however on seeing the commit message of the fix it provides some background on why you might be facing the error.
git-gui (Windows): use git-gui.exe in Create Desktop Shortcut
When calling Repository>Create Desktop Shortcut, Git GUI assumes
that it is okay to call wish.exe directly on Windows. However, in
Git for Windows 2.x' context, that leaves several crucial environment
variables uninitialized, resulting in a shortcut that does not work.
To fix those environment variable woes, Git for Windows comes with a
convenient git-gui.exe, so let's just use it when it is available.
This fixes #448
Signed-off-by: Johannes Schindelin
As highlighted in the commit message above, the author clearly points out to use git-gui.exe located in the /cmd directory.
As a final note, I would suggest OP to :
Check PATH variable of Windows cmd and git-bash for conflicting directories containing git-gui using where and which commands respectively (Windows cmd PATH env is passed on to git-bash)
Simulate an empty PATH variable as I have shown above and add only /cmd to the PATH variable of git-bash and then check if you are able to run git-gui from git-bash
Confirm if git-gui runs in Windows cmd
Check if you are adding the directory to the env variable PATH correctly
(Windows cmd and git bash)
Try running git-gui and git gui, do both the commands in git-bash give the same error ?
I've been using git and the git gui command on windows for about 2
years with no issues. Recently, I installed ubuntu on windows 10 and
enabled the windows subsystem for linx (wsl) and installed git in the
ubuntu bash, thinking I'd run git command from there. Ever since, git
is quite broken when I use the git bash as part of git for windows.
To reproduce this, I
Setup a Windows 10 VM (Build 1909, Single Language Home Edition)
Install git for windows version 2.24.0.windows.2
Git installation location : C:\Git
Similar options as you mention in the question except for the editor
Observations
C:\Git\cmd is added to the PATH environment variable of Windows cmd (and therefore git-bash too)
Both the commands git-gui and git gui work from git-bash
Turn on Windows feature Windows Subsystem for linux for Bash on Ubuntu Windows
Install Ubuntu app from Microsoft store (Ubuntu 18.04)(git was pre-installed)
Update git to the latest version using this
git works both for bash and windows running at 2.24.0 and 2.24.0.windows.2 respectively
Both the commands git gui and git-gui work as expected from git-bash
Uninstalled ubuntu for bash and turned off wsl, and it still works
Further debugging can be done using git's environment variables.
GIT_EXEC_PATH determines where Git looks for its sub-programs (like
git-commit, git-diff, and others). You can check the current setting
by running git --exec-path.
Run this command git --exec-path on git-bash, and verify if it
shows : C:/Git/mingw64/libexec/git-core
GIT_TRACE controls general traces, which don’t fit into any
specific category. This includes the expansion of aliases, and
delegation to other sub-programs.
Run this command GIT_TRACE=1 git gui, and show the output
(which includes the resolved exec directory for git-gui)
GIT_CONFIG_NOSYSTEM, if set, disables the use of the system-wide
configuration file. This is useful if your system config is
interfering with your commands, but you don’t have access to change or
remove it.
Try running this command GIT_CONFIG_NOSYSTEM=1 git gui
You can open a new issue here, if nothing else works.
So this is too long for a comment: Have a look here:
So why doesn't the following attempt work?
exec wish "$0" "$#"
The reason is that some versions of sh have a bug. If there are no
arguments, these broken sh's will still expand "$#" into a single
empty argument. Oops.
The sh syntax ${VAR+VALUE} expands to VALUE if $VAR is set, and
nothing otherwise. We abuse this syntax to work around the buggy sh
implementations. Recall that the first argument is named $1. If it
exists, then we use "$#"; otherwise we do nothing:
exec wish "$0" ${1+"$#"}
I assume you are on Windows:
Go to ...\Git\mingw64\libexec\git-core. Then you should find git-gui. If you open it with an editor, it looks like
#!/bin/sh
# Tcl ignores the next line -*- tcl -*- \
exec wish "$0" -- "$#"
...
in my case.
I am not an expert here and I don't unerstand the details in the link above, but as it is only a skript and you already re-installed everything, I would give it a try
#!/bin/sh
# Tcl ignores the next line -*- tcl -*- \
exec wish "$0" ${1+"$#"}
...
I hope that helps and that it doesn't destroy anything ;-)

How to make optional tools of Git For Windows 2.7 load customized configuration?

I installed Git For Windows 2.7.2 a few days ago. Now I have some problems with using optional tools Git For Windows provides from cmd.exe. In the previous version of Git For Windows(or say msysgit), I could configure these tools by modifying Git/etc/git-completion.bash. For example:
alias ls='ls --show-control-chars --color=auto'
I used this way to make ls display file names that contained Chinese characters normally. Now it seems this way doesn't work. In fact there is no git-completion.bash under Git/etc/. There is a git-completion.bash under the folder Git/mingw64/share/git/completion. I tried to copy it to Git/etc and add the alias above, which didn't work either. These tools only works fine in Git Bash. So how should I configure these tools together with git to use them from cmd.exe?
This answer explains why you no longer have this functionality. In short, msysgit provided a unix shell emulator, mingw. Git for Windows is git compiled in a Windows environment.
Therefore, ls is simply an alias for dir in a Windows shell, not mingw's ls. If you want to create some Windows aliases, you can use doskey. Here's an answer for that.
Alternatively, I would suggest that you just start using PowerShell, where you'll be able to set up the $profile variable with some powerful commands like these.

Colored files in Windows terminal via Cygwin?

I have Cygwin installed on my Win7 laptop and by editing my Windows path variable I'm able to get Linux commands in my Windows command terminal. My Question is there a way to get colored file output to transfer to the Windows command line?
Through Cygwin I obviously just alias my .bashrc file, but from Googling and checking Cygwin FAQs I can't find any way to reference that file in a Windows prompt. Although 'ls --color=auto' does work, is there a way to alias this through the Windows command line in any way?
#Al G - Yes. I already can use commands by editing my PATH to include the Cygwin /bin directory but I was wondering if there was a way to carryover aliases. However I was able to answer my own question:
Using naitve Windows aliasing via DOSKEY I can create an alias for ls to auto color file types like this:
DOSKEY ls=ls --color=auto
Put the alias in the .bash_profile (create if not present), not in .bashrc.
In my case:
alias ls='ls --color=auto -la'

Resources