I've installed Git Bash 2.5.1 64-bit on a fresh Windows 10 machine:
mark#Foo MINGW64 ~/Documents/FsCheck (master)
$ git --version
git version 2.5.1.windows.1
When I list the contents of a directory, I can see a shell script:
mark#Foo MINGW64 ~/Documents/FsCheck (master)
$ ls
appveyor.yml build.cmd build.sh* Docs/
bin/ build.fsx Contributors.txt examples/ FsCheck.sln
(Some files and folders removed for clarity.)
Notice that the shell script build.sh has an asterisk after the extension. In the console, it's also coloured green, where other files are light grey. I haven't seen this before, so I don't know if it means anything.
When I try to run the script, I get an error message:
mark#Foo MINGW64 ~/Documents/FsCheck (master)
$ build.sh
bash: build.sh: command not found
Also, there's no tab completion for any of the build files.
How can I run the shell script from Git Bash?
You probably have ls aliased to ls -F. So when an trailing asterisk appears that means that the file is executable.
In POSIX systems, you can't directly execute files in current directory (for safety reasons). If you want to, you can use this trick:
./build.sh
You can, of course, edit your PATH by adding ";." at the END of the current value. In mingw64_shell.bat do
SET PATH=%PATH%;.
Note: I'm looking at my MSYS2 installation, so you may need to look for the ".bat" file that launches bash. The biggest security problem with the WINDOWS default path that had "." in front of the path is that it allows a user to over-ride a system executable -- that would make your scripts do some weird stuff, especially if you import them from someone else.
Related
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 ;-)
It is possible to view shorter path in my terminal (VS Code & Hyper) with WSL (Ubuntu). On top of the Ubuntu, I have installed zsh. Currently, I am using a git bash and path looks Lukas#Y50-70 ~/Coding but with the Ubuntu, I have something like this lukas#Y50-70 /mnt/c/Users/Lukas/Coding. When I have a project in another 2 folders or so and I have a long branch name it is annoying to have a full row unnecessary info (for me).
Here is a comparison of Ubuntu and git bash:
Thanks
I was able to solve this using Named Directories - by adding this line to your ~/.zshrc file
hash -d c=/mnt/c
you will see '~c/' in your prompt rather than '/mnt/c/' which I think is a lot nicer.
This has a similar effect to setting an alias for the directory but the name is reflected in how your path is displayed.
As an added bonus you can then switch to that directory at any time by typing ~c
Check if the zsh installation guide under WSL can help (from neurogenesis):
Install zsh with sudo apt-get install zsh
bash.exe is the entrypoint to the WSL / linux subsystem. You'll have to modify the windows shortcut to specify bash -c --login or modify ~/.bashrc with exec /bin/zsh to properly load a different shell.
/etc/passwd isn't consulted because it's not a full login process. Be sure to set your SHELL env var as well. See #846 for details.
Fix your umask before you start installing things, otherwise tools like zsh will complain.
Specifically, "group" and "other" permissions will have the same privileges that owner do. This causes zsh's compaudit and compinit to fail (both are related to command completion).
See #352 for details. umask 022 can be added to your ~/.bashrc.
NOTE: This should be done before trying to install zsh plugin managers like antigen (otherwise the directory/file permissions issues from git clones).
You should also do this before installing RVM or rbenv.
I ended up inserting a few lines to the top of my ~/.bashrc, something like the following:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
## Fix missing umask value
umask 022
## Launch Zsh
if [ -t 1 ]; then
cd $HOME
export SHELL=/bin/zsh
exec -cl $SHELL
fi
Issue 846 (mentioned in point 2) includes the comment:
A normal -c zsh symlink opened up in the wrong directory to me, but I managed using this (note the tilde):
C:\Windows\System32\bash.exe ~ -c /bin/zsh
See also "How to Use Zsh (or Another Shell) in Windows 10".
I know this isn't exactly the fix you were hoping for. I was looking to solve the same issue. The prompt was just too long and it was causing some of my commands to wrap to the next line. After seeing the comments on VonC's answer, I'm deciding to keep my next-best solution.
What I did in my ~/.bashrc file is this:
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u#\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\n\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u#\h:\w\n\$ '
fi
I added a \n right before the \$
So when I'm at my Windows home folder, it looks like this
ryan#DESKTOP-RSKAA4F:/mnt/c/Users/ryank
$
And I start typing my commands after the $. It takes up more vertical space, but at least I don't have to maximize my terminal window just to avoid text wrap.
It appears to me that just running 'cd' after starting the terminal session, re-bases the prompt to the normal '/home/(user)'
there should be no need for installing zsh or anything else. It works for me anyway.
also when starting the session at the root folder from windows, seems to do the trick.
I keep my sessions under
C:\vms
sample:
cd -d C:\vms\minikube\ubu_jenkinsX\rootfs
C:\vms\minikube\ubu_jenkinsX\rootfs>wsl -d ubu_jenkinsX
Yours may be under your userprofile in local data. Search for the rootfs folder
The reason your WSL prompt shows such a long path is because you're not actually in your home directory. You see, WSL has its own virtual filesystem separate from Windows, and Windows paths (like your C:\Users\Lukas\...) are stored under /mnt/c/Users/Lukas/.... Your WSL home directory would be /home/Lukas (since your WSL username is capitalized), but of course, that's not where your project is.
The fish shell has a prompt_pwd function that shortens a path to something like this:
0 ---- /m/c/U/L/Documents cd Something
0 ---- /m/c/U/L/D/Something prompt_pwd
/m/c/U/L/D/Something
Is that something you're interested in? You could port the function to Bash, or just switch to Fish, or just display the current directory name instead of path.
Just installed git on my Windows 7 laptop and desktop and it seems that some standard Unix commands are missing in the setup. I'm new to Git and not that great with Windows stuff.
I found out the issue by trying to configure the git bash using a .bashrc by adding a simple alias thus:
alias ls 'ls -F'
When the .bashrc is run (and it's getting executed when the shell starts), I get this message:
$ alias ls 'ls -F'
bash: alias: ls: not found
bash: alias: ls -F: not found
Upon closer examination of the bin directories (/bin, /usr/bin, i.e. C:\Program Files\Git\bin and C:\Program Files\Git\usr\bin, respectively) there is no alias or alias.exe.
I'm assuming this has something to do with Unix commands re-created into windows executable and not some branch of a path that I'm missing. I've checked on the path and cannot find some hidden bin directory.
I've seen several postings on installing Cygwin on it's own and I can do this but before launching into a protracted fix for both my laptop and desktop I'd like to know if I'm missing something or my git initial install is bad or if there's a package that I should be adding -- would appreciate any assistance.
The correct syntax would be:
alias ls='ls -F'
alias is a bash builtin command, so you won't find an alias.exe anywhere in the git distribution.
I am on git-for-windows Git Bash. I can't run an executable on the command line:
Pedr#Abc-07 MINGW64 /c/dev
$ ls sqlite3.exe
sqlite3.exe*
Pedr#Abc-07 MINGW64 /c/dev
$ sqlite3
bash: sqlite3: command not found
Why is it so?
To run a program in the current directory in bash, you put ./ in front of it. So in your case:
$ ./sqlite3.exe
When you run sqlite3, bash will look for a program with exactly that name in all directories of the PATH environment variable, which by default includes standard locations for executables like /usr/local/bin but not your current directory. See here for more info on that.
It's because you're under a is a runtime environment for gcc, that give you support to binaries native under Windows, but you can run any exe as shell using ./ (local execute)
Take a look to documentation of this tool: http://sourceforge.net/p/mingw-w64/wiki2/FAQ/
Your PATH is missing ./. Add it to your .profile file in the home directory (/c/Users/username):
$ cd
$ pwd
/c/Users/username
$ echo 'PATH=$PATH:./' >> .profile
Restart bash session and voilà! Now echo $PATH should output :./ as the last item. Note that you definitely need to add it as the last item for security (e.g. against malicious ls.exe).
I've tried executing the following:
#!C:\cygwin\bin\bash.exe
ls ${WORKSPACE}
But that doesn't find ls (even if it's on the windows path). Is there any way to set this up?
UPDATE: In other words, I want to be able to set up a build step that uses cygwin bash instead of windows cmd like this page shows you how to do with Python.
So put your cygwin's bin directory in your PATH.
In case you don't know how to do it (Control Panel -> System -> Advanced -> Environment Variables), see: http://support.microsoft.com/kb/310519
That shell-script has two errors: the hash-bang line should be "#!/bin/bash", and ${WORKSPACE} is not a shell-variable. Hudson has a bunch of variables of its own which are expanded in the commands you specify to be run (i.e. when you add commands in the web gui).
If you want to run Hudson build step on the Cygwin command line, you need to figure out what command Hudson runs and in which directory.
To give a more specific answer, you need to show us how your project is configured and what steps you want to run separately.
Provided cygwin's bin folder is in your path, the following works for me:
#!/bin/sh
ls ${WORKSPACE}
I find Hudson does not pick up environment variable changes unless you restart the server.
you might want to try to give a full path to ls
/cygdrive/c/cygwin/bin/ls
One other thing that seems to work is to use this:
#!C:\cygwin\bin\bash.exe
export PATH=$PATH:/usr/bin
ls
But it would be nice not to have to modify the path for every script.
Have you thought about power shell? as much as I like cygwin, it's always been a little flaky, powershell is a solid fully functional shell on windows, another option is Windows Services for UNIX it gives you korn shell or c shell not quite as nice as bash but it gets the job done
You will need to pass the --login (aka -l) option to bash so that it will source Cygwin's /etc/profile and set up the PATH variable correctly. This will cause the current directory to get changed to the default "home" but you can set the environment variable CHERE_INVOKING to 1 before running bash -l and it will stay in the current directory if you need to preserve that.