gitk is not working for me. I get the error saying "the term 'gitk' is not recognized as the name of a cmdlet, function, script file, ...."
One interesting thing I noted was that inside C:\Program Files(x86)\Git\bin\, there was a gitk file, but it had no extension. Most other files in that folder had a .exe extension.
I also made sure that C:\Program Files(x86)\Git\bin\ is specified in the PATH environment variable.
Also, I tried adding C:\Program Files(x86)\Git\cmd\ to PATH because it contains a gitk.cmd file, but that did not help either.
Edit : I was using Powershell earlier, since I have poshgit installed. I switched over to bash, and I was able to do gitk --all from there.
I just got it to work after having the same problem.
At the PowerShell prompt it typed: "Bash" and hit return.
This put me into a bash shell.
Then I typed "gitk" at the Bash prompt and it worked.
So that gitk file is a UNIX shell script and requires the shell to work.
I suppose you could always have one of your Power Shell window in Bash mode and then this tool is available.
Related
My goal is to write a shell script that will ensure that a bunch of Windows 10 computers with Python freshly installed on them can run the 'python' command from a git-bash command line in Windows Terminal by having the script check the PATH environment variable and modify it if necessary.
More specifically, I want my script to check if the following three paths are part of each computer's PATH, and if they aren't already a part of it, edit the PATH so that it permanently contains them.
C:\Program Files\Python311
C:\Program Files\Python311\Scripts
C:\Users\ <localUser>\AppData\Roaming\Python\Python311\Scripts
What threw me off is that I noticed that the PATH variable that I get from the 'env' command on the git-bash command line is different from the PATH variable that I can see in Windows 10's control panel. I tried adding a junk path to PATH from the command line by typing
export PATH=/c/someNonexistentPath in git bash but it didn't change the PATH that I could see in the Windows 10 control panel. Moreover, I couldn't even see if it changed the PATH I get from running env on the command line because for some reason after you run any export command git-bash gets amnesia and refuses to recognize the env command until you start a new session of git-bash.
Shouldn't there only be one PATH on a computer? If the two seemingly different PATHs that I have mentioned are not supposed to be the same, what is the difference between them, and how can I accomplish my goal of writing the script so that it does what I need it to do?
Please let me know if I need to include any more system-specific info. Thanks in advance for your help.
Problem summary
I'm trying to launch a .sh script via Windows 10 Cygwin (i.e. mintty.exe > bash.exe) but neither .profile, .bash_profile, or .bashrc are loading, which I need to update PATH env variable with Cygwin's bin directory.
Background
I'm trying to launch a script finder.sh:
#!/bin/bash
find .
read
from C:\Users\Bo\Temp\. It has unix line endings and executable bit set.
I have Cygwin installed at C:\Users\Bo\AppData\Local\Programs\cygwin64\. I do not have this path in either System or User Windows' Environment Variables (and I don't want to!). My runcoms all live in this directory under /home/Bo. My .bash_profile (and ATM .bashrc) have an export PATH="/cygdrive/c/Users/Bo/AppData/Local/Programs/cygwin64/bin":${PATH} in them.
I want to launch the script from Windows Explorer. I tried using the bash.exe and mintty.exe in the cygwin64\bin\ folder via Open > Choose another app > More apps > Look for another app on this PC. In either case the mintty window displays:
FIND: Parameter format not correct
meaning the Windows' find command was used not Cygwin's. So I have my script echo $PATH and the Cygwin/bin directory is not in PATH. If I add the proper export PATH statement from above to my own script it works fine. So, now to debug the launcher and runcoms...
I've put echo ${0} statements in .profile, .bash_profile, and .bashrc, none of which trigger which I run the .sh script, they are never run. I've read SO and the mans. I've tried creating a Shortcut to both mintty.exe and bash.exe passing a variety of -l -i -e - commands to each using Properties > Shortcut > Target and they are never run. E.g. running simply [..]\mintty.exe -h always doesn't even leave the window open.
How do I get my script to run in Windows Explorer via Cygwin's mintty.exe/bash.exe, and to read from a runcom to update PATH (to find Cygwin Linux commands, vs. updating Windows Environment Variable)?
Two part fix:
A) set a Windows Environment Variable for BASH_ENV to a .bash_env under your Cygwin HOME, and export the PATH variable to include the Cygwin/bin directory from that file. I cannot find a decent reference for this in Cygwin documentation because it seems to be simply a bash thing, but this variable is what bash looks for when running non login/interactively. Best reference: Cygwin shell doesn't execute .bashrc.
And B) run the .sh with bash.exe from Cygwin/bin using Open With....
ALSO, annoying Windows bug: when you select a program to Open With... your .sh script, it will always run 1x with a CWD from your C:\Windows\System32 directory(?!) and all other times will run fine with the CWD as the directory from your .sh script.
After installing win-bash from sourceforge.net and creating a command prompt label and setting the path, my bash recognizes some commands like "ls", "mkdir" but not "clear" or "clean"!
the label to command prompt has this in its properties:
the red arrows points to this setpath.bat, it has this:
#echo off
SET PATH=%PATH%;C:\win-bash
bash
exit
the folder win-bash has the content from win-bash downloaded file from sourceforge + setpath.bat file.
My bash recognizes ls, mkdir - creates folders, but can't "clean". What's the reason - some shell cmds recognized, and some don't?!
P.S. It does NOT recognize most commands - mkfile, lsblk, calendar(cal)
Not an expert on win-bash, but here are some clues:
other linux emulators on Windows like mingw32, GoW provide standalone executable .exe for each program, so it is easy to see which commands are implemented just by reviewing the emulator directory (the one it appends to path)
win-bash claims from documentation it is a single-file replacement for the shell, but rest of documentation is limited
if you want to clear screen 'cls' should work it is a native windows command. On internals of 'clear' see
https://superuser.com/questions/1161514/bash-on-ubuntu-on-windows-clearing-all-the-text-all-of-it
When starting a gvim session on windows 7, it appears that globally available commands like autopep8 or pylint cannot be executed. I.e. the command :!pylint opens up a console windows saying 'pylint' is not recognized as an internal or external command.
However, I can execute these commands from cmd.exe by just typing the respective names.
This is because I have added the path C:\Program Files (x86)\Python 3.5\Scripts; to the System Path environment variable. For some reason this is not picked up by the shell behind gvim.
The weird thing is that typing :echo $PATH shows a list or folders which includes C:\Program Files (x86)\Python 3.5\Scripts;.
I should also note that this problem does not occur when starting normal vim in a terminal like cmd.exe or git bash.
Any hints on what might be going wrong?
I have a ./configure file that I'm supposed to run by putting it in the command prompt. It works when I run it in the git prompt but when I run it in the Windows command prompt it gives me:
C:\cygwin\home\doxygen\configure> configure
'configure' is not recognized as an internal or external command,
operable program or batch file.
Even though I'm in the correct directory (and running dir shows me that the file is there) it still stays that it cannot find the file. This is the same for all files that don't have an extension on them. Why does this happen and how can I get this to work?
./configure is not a program. It's more of a shell script usually. My analogy may not be good but consider it to be the equivalent of windows batch files (in this case you can say it's a .sh without the extension).
It will only run from a cygwin/unix shell.