I'm just getting started trying to use command line and gitbash, and I've run into some basic issues.
As I understand it from the lesson I'm trying to go through online, I can run gitbash on windows instead of standard command line I would find on Mac and Linux(?)
The blurb about it was:
"WINDOWS USERS: You might want to jump ahead to the Installations Assignment and use the "Git Bash" application you'll install there instead of using the default Command Prompt. That way you can be sure all the commands will be the same."
So I downloaded Gitbash via Railsinstaller but the first command, man/man ls, gives me this error.
Am I misunderstanding the function of Gitbash? Do I need to install something to add on or something else entirely?
Unfortunately, one of the notable faults of Git Bash is that it does not ship with a man command, so no, you are not misunderstanding anything. If you try to ls or cd or grep you'll see that it works fine.
Without going into too much background, Git Bash is a shell environment on Windows that emulates standard POSIX terminal behavior and makes some common Linux tools available. I'm not personally prone to the reasoning behind this decision, but I just double-checked and man (and man-db, etc.) are available in the ecosystem behind the tool that Git Bash derives from. If you want to fight for it, you might want to open an issue on the Git for Windows GH repository; Johannes Schindelin is the lead maintainer there and is very active.
Related
I have been stuck for two days looking for a solution. Could anybody please tell me how to install shell commands in Atom to enable the atom command at the command line under Windows. I know that it is not installed because when I typed which atom, it returns nothing.
Reading your other thread, I understand that you want to install a package who emulates shell commands within Atom. If so, you just have to follow the installation steps for Windows on Atom's website (I think you got confused with this which command story on the other thread, which explains how to install it on Linux and macOS).
I don't really know how to execute programs with command-line in Windows, if you don't master it either, I'd recommend using the graphics mode, and simply open your README.md file with the FILE button, like in any other software.
When you have Atom properly installed, there'll be some packages created to emule a terminal with shell commands, like this one. But this is independant from executing Atom from your computer. It emulates a terminal within Atom. I hope this is a little bit clearer.
I understand that console applications using git bash invoke sh.exe but I wonder how they continue to use sh.
I see on console apps often you do a sh.exe --login. I would guess this creates a session somewhere and I would presume that the console application would execute commands against it somehow?
Essentially I switched from UNIX to Windows. I have tried a lot of console apps (best being console2 and just git-bash) but they still do not work for me well.
Ia m annoyed enough that I fancy trying to programming a simple shell in Java. (I am a Java developer by trade.)
Any help would be great thanks to understand this, looking but searchs with console or git-bash in google generate so much random noise.
If you are using one of the various Unix shells ported to Windows, you should be aware that most of these shells use some heuristic to make Windows look like Unix, either to build a compatibility layout or for user convenience.
For instance, the git command is probably stored in a git.exe file but your shell scripts imported from your Unix workstation all say git so the shell will lookup git.exe if it does not find git.
Nobe of these heuristics works perfectly, so you have to expect regular inconsistencies and disagreements, especially if your are mixing several Unix ports together.
As for the meaning of --login, it is synonymous to -l and its main effect is to decide which initialization files are read by bash on startup`
-l Make bash act as if it had been invoked as a login shell (see
INVOCATION below).
I've just started with Git, and I can't figure out how to enable command line for Git. I see many posts suggesting the use of msysgit to enable the Git command line, and I also see many other tools that can work around it. But currently I just get the Git client tools for Windows from GitHub. Then I can use the git command in my windows command console. I don't know if it includes the msysgit in it.
The git client tools will include msysgit. You might need to add the git bin directory into your path for ssh to work correctly with cmd (and powershell)
Also, I would highly recommend "posh git" which is a powershell module that gives you some tab completion and a git prompt in powershell, if you are a windows person, its likely you are more comfortable scripting in PS than in bash, and posh git is great for that.
find instructions here on how to install it.
Note on Windows usage: you should use Git with the provided msysGit
shell (Unix style), it allows to use the complex lines of command
given in this book. If you need, for some reason, to use the native
Windows shell / command line console, you have to use double quotes
instead of simple quotes (for parameters with spaces in them) and you
must quote the parameters ending with the circumflex accent (^) if
they are last on the line, as it is a continuation symbol in Windows.
http://git-scm.com/book/en/Getting-Started-Installing-Git
Are you using the msygit shell?
Problem:
git add -p seems unusable in either emacs shell or eshell
magit (a frequently suggested alternative to using git from the shell in emacs) sucks balls on Windows (it's horrendously slow.)
Keeping a cygwin window open and using that for git add -p and then going back and forth between that and emacs is doable, but more than a little annoying.
Is there any way that under Microsoft Windows I can get either git add -p to work well in shell or eshell or alternatively get magit to be somewhat usable?
If magit is slow, that probably indicates problems with your windows git client?
I would look into that first and foremost (because git add -p really doesn't hold a candle to magit's interface, IMO).
What are the exact tools (and versions thereof) which you are using?
You should definitely check the magit issue tracker to see if there are known reasons why magit might be slow.
Have you tried:
% EDITOR=emacsclient git add -e <files>
and then using the diff-mode commands in your running emacs to interactively edit the hunks of the patch?
Then you will be able to split hunks within the patch at any particular line with diff-split-hunk and remove hunks entirely with diff-hunk-kill (and of course these commands are bound to shorter key sequences for quick interactive use). When you are done editting the patch, use C-x # to save it and quit the emacsclient session (so that you can go back to your shell).
(emacsclient, if you are not familiar with it, is a program that will let you open files in an already-running emacs, as long as the latter has started up a server for emacsclient to connect to; see the M-x describe-function server-start)
Note that you will probably want to customize how emacsclient interacts with git a little bit; for example, see these answers: Using ediff as git mergetool and How to set the exit status for emacsclient.
I'm using msysgit 1.7.7.1 on Windows. I get an error when using git diff. What is causing this? Is there no diff tool included in msysgit? What should I do?
WARNING: terminal is not fully functional
If you are having issues in cmd.exe, for instance, see the warning here:
Then simply set your environment variables and include TERM=msys. After that, each time you open a cmd.exe, your variable will be set correctly.
NOW YOU MUST RESTART YOUR SHELL (CMD.EXE). Just run a new one. And from there, you should have no more issues. Again:
For Git Bash, this can be fixed by adding the following line to ~/.bashrc:
export TERM=cygwin
-or-
export TERM=msys
The first seems to be the original by git for windows, the second a popular known form to "heal" as well.
The problem can be caused if some other program (like for example Strawberry Perl) sets the TERM system environment variables.
http://code.google.com/p/msysgit/issues/detail?id=184
Above answers was not fully worked for me, so I did:
Add
export TERM=msys
to "[githome]/etc/profile" at the top but it made changes only for git bash. Then I added
#set TERM=msys
to "[githome]/cmd/git.cmd" after #setlocal (I installed only git run from command line). May be this decision not truly good but it works for me and there are not any terminal warnings. (I use git version 1.7.10.msysgit.1).
The answer can be found here, in which the author of the solution claims that:
the environment variable TERM was set to dumb
that was instead of
TERM=cygwin
You can change that to
TERM=msys
to solve the problem at hand.
I work in powershell and I have the git executable directly in my path.
None of the suggested answers worked, but I found a solution that works for me.
I added a line in my powershell profile:
$env:TERM="msys"
Which fixed the problem for me.
A quick & dirty solution in my case turned out to be to use the --no-pager option.
By default, some git commands (like log) will use a pager like less if they expect the output to be long. Pagers require things like scrolling text up and down with the arrow keys, which sometimes doesn't work if the assumptions about what kind of terminal you're on are wrong (this is what the "not fully functional" means).
If you know ahead of time that your output will be short, or you just want it to dump output to the terminal and leave the scrolling up to your terminal program, you can override this and not use a pager at all, e.g.:
git --no-pager log
In case someone gets this launching bash from Git Extensions, check the setting for Path to linux tools.... Mine was set to C:\cygwin. Changing it to C:\Program Files (x86)\Git\bin\ fixed it for me. I didn't have to set the TERM variable to launch bash this way.