The quoting rules of `cmd.exe` are really, really quirky. In particular,
if there are more than two quotes, the entire set of rules changes. That
is the reason why
CMD /C "C:\Program Files\Git\usr\bin\bash.exe" -l -i
works, but
CMD /C "C:\Program Files\Git\usr\bin\bash.exe" -l -i "test.sh"
fails with this error message:
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
The recommended fix is to pass the /S option to `cmd.exe` and surround
the entire command-line by an extra set of quotes. And here lies the
rub: for that to work, we have to append an extra quote. At the end of
the command-line. *After* the last argument was appended, if any.
This commit supports that use case by introducing the option
"APPEND_QUOTE". The intended usage is to use the following string
resource:
SHOW_CONSOLE=1 APPEND_QUOTE=1
@@COMSPEC@@ /S /C \"\"@@EXEPATH@@\\usr\\bin\\bash.exe\" --login -i
(Note that there are only three quotes on that command-line, the fourth
to be appended due to the `APPEND_QUOTE` setting.)
This is (1/3) to fix https://github.com/git-for-windows/git/issues/396
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Git wrapper is also used as a redirector for Git for Windows'
bin\bash.exe dropin: for backwards-compatibility, bin\bash.exe exists
and simply sets up the environment variables before executing the
*real* bash.
However, due to our logic to use the directory in which the `.exe`
lives as top-level directory (or one directory below for certain, known
basenames such as `git.exe` and `gitk.exe`), the `PATH` environment
variable was prefixed with the `/bin/bin` and `/bin/mingw/bin`
directories -- which makes no sense.
Instead, let's just auto-detect the top-level directory in the common
case.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We should not conflate the 'exepath' with the 'top-level
directory'. The former should be the directory in which the executable
lives while the latter should be the top-level directory ("POSIX root
directory") as far as Git is concerned.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Windows 7 allows users to pin running applications to the task bar. By
setting the application ID, multiple processes can share a single task
bar entry, and this is exactly what we need for `git-bash.exe` which
wants to share the task bar entry with the `mintty.exe` instance it
launches.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The idea of `git-bash.exe` automatically running the Git Bash in the
home directory was to support the start menu item `Git Bash` (which
should not start in C:\Program Files\Git, but in $HOME), and to make
that behavior consistent with double-clicking in `git-bash.exe`
portable Git.
However, it turns out that one of the main use cases of portable Git is
to run the Git Bash in GitHub for Windows, and it should start in the
top-level directory of a given project. Therefore, the concern to keep
double-clicking `git-bash.exe` consistent with the start menu item was
actually unfounded.
As to the start menu item: it can easily be changed to launch
`git-bash.exe` with a command-line option. So let's introduce the
--cd-to-home option for that purpose.
As a bonus, the Git wrapper can now also serve as a drop-in redirector
/bin/bash.exe to provide backwards-compatibility of Git for Windows 2.x
with 1.x: some 3rd-party software expects to find that executable there,
and it also expects it to leave the working directory unchanged.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
By embedding string resources into the Git wrapper executable, it
can be configured to execute custom commands (after setting up the
environment in the way required for Git for Windows to work properly).
This feature is used e.g. for `git-bash.exe` which launches a Bash in
the configured terminal window.
Here, we introduce command-line options to override those string
resources. That way, a user can call `git-bash.exe` (which is a copy of
the Git wrapper with `usr\bin\bash.exe --login -i` embedded as string
resource) with command-line options that will override what command is
run.
ConEmu, for example, might want to call
...\git-bash.exe --needs-console --no-hide --minimal-search-path ^
--command=usr\\bin\\bash.exe --login -i
In particular, the following options are supported now:
--command=<command-line>::
Executes `<command-line>` instead of the embedded string resource
--[no-]minimal-search-path::
Ensures that only `/cmd/` is added to the `PATH` instead of
`/mingw??/bin` and `/usr/bin/`, or not
--[no-]needs-console::
Ensures that there is a Win32 console associated with the spawned
process, or not
--[no-]hide::
Hides the console window, or not
Helped-by: Eli Young <elyscape@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We will enhance the function in the next commit to support @@VAR@@
expansion in the upcoming `--command=<command>` option.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Using different code pages for console input (SetConsoleCP()) and console
output (SetConsoleOutputCP()) doesn't make much sense and may be hazardous
for native Windows programs.
Git uses UTF-8 internally, so it actually needs 'SetConsoleCP(CP_UTF8)'
rather than 'SetConsoleCP(GetACP())'. However, ReadFile() / ReadConsoleA()
are broken with CP_UTF8 (and thus any higher level APIs such as fgetc(),
getchar() etc.). Unicode-aware console input would have to be implemented
via mingw_* wrappers using ReadConsoleW(). As Git typically launches an
editor for anything more complex than ASCII-only, yes/no-style questions,
this is currently not a problem.
Drop 'SetConsoleCP()' from the git-wrapper, so that input and output code
pages stay in sync.
Signed-off-by: Karsten Blees <blees@dcon.de>
When we fall back to starting the Git Bash in the regular Windows
console, we need to show said console's window... So let's introduce yet
another configuration knob for use via string resources.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With a recent change in Cygwin (which is the basis of the msys2-runtime),
a GUI process desiring to launch an MSys2 executable needs to allocate a
console for the new process (otherwise the process will just hang on
Windows XP). _Git Bash_ is such a GUI process.
While at it, use correct handles when inheriting the stdin/stdout/stderr
handles: `GetStdHandle()` returns NULL for invalid handles, but the
STARTUPINFO must specify `INVALID_HANDLE_VALUE` instead.
Originally, the hope was that only this `NULL` => `INVALID_HANDLE_VALUE`
conversion would be required to fix the Windows XP issue mentioned above
(extensive debugging revealed that starting _Git Bash_ on Windows XP would
yield invalid handles for `stdin` and `stderr`, but *not* for `stdout`).
However, while _Git Bash_ eventually showed a `mintty` when not allocating
a new console, it took around one second to show it, and several seconds
to close it. So let's just include both fixes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With the resource-driven command-line configuration, we introduced the
option to ensure that only the PATH environment variable is edited only
minimally, i.e. only /cmd/ is added (as appropriate for _Git CMD_).
We are about to add another option, so let's refactor the equivalent of
Git's `strip_prefix()` function; It is not *quite* the same because we
have to `memmove()` the remainder to the beginning of the buffer.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-wrapper fails to initialize HOME correctly if $HOMEDRIVE$HOMEPATH
points to a disconnected network drive.
Check if the directory exists before using $HOMEDRIVE$HOMEPATH.
Signed-off-by: Karsten Blees <blees@dcon.de>
This change accompanies the `--no-cd` option when configured via
resources. It is required to support `Git Bash Here`: when
right-clicking an icon in the Explorer to start a Bash, the working
directory is actually the directory that is displayed in the Explorer.
That means if the clicked icon actually refers to a directory, the
working directory would be its *parent* directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To avoid that ugly Console window when calling \cmd\git.exe gui...
To avoid confusion with builtins, we need to move the code block
handling gitk (and now git-gui, too) to intercept before git-gui is
mistaken for a builtin.
Unfortunately, git-gui is in libexec/git-core/ while gitk is in bin/,
therefore we need slightly more adjustments than just moving and
augmenting the gitk case.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When *Git for Windows* is installed into a directory that has spaces in
it, e.g. `C:\Program Files\Git`, the `git-wrapper` appends this directory
unquoted when fixing up the command line. To resolve this, just quote the
provided `execpath`.
Signed-off-by: nalla <nalla@hamal.uberspace.de>
The idea of having the Git wrapper in the /cmd/ directory is to allow
adding only a *tiny* set of executables to the search path, to allow
minimal interference with other software applications. It is quite
likely, for example, that other software applications require their own
version of zlib1.dll and would not be overly happy to find the version
Git for Windows ships.
The /cmd/ directory also gives us the opportunity to let the Git wrapper
handle the `gitk` script. It is a Tcl/Tk script that is not recognized
by Windows, therefore calling `gitk` in `cmd.exe` would not work, even
if we add all of Git for Windows' bin/ directories.
So let's use the /cmd/ directory instead of adding /mingw??/bin/ and
/usr/bin/ to the PATH when launching Git CMD.
The way we implemented Git CMD is to embed the appropriate command line
as string resource into a copy of the Git wrapper. Therefore we extended
that syntax to allow for configuring a minimal search path.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We recently added the ability to configure copies of the Git wrapper to
launch custom command-lines, configured via plain old Windows resources.
The main user is Git for Windows' `git-bash.exe`, of course. When the
user double-clicks the `git bash` icon, it makes sense to start the Bash
in the user's home directory.
Third-party software, such as TortoiseGit or GitHub for Windows, may
want to start the Git Bash in another directory, though.
Now, when third-party software wants to call Git, they already have to
construct a command-line, and can easily pass a command-line option
`--no-cd` (which this commit introduces), and since that option is not
available when the user double-clicks an icon on the Desktop or in the
Explorer, let's keep the default to switch to the home directory if the
`--no-cd` flag was not passed along.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When we rewrite the command-line to call the *real* Git, we want to skip
the first command-line parameter. The previous code worked in most
circumstances, but was a bit fragile because it assumed that no fancy
quoting would take place.
In the next commit, we will want to have the option to skip more than
just one command-line parameter, so we have to be much more careful with
the command-line handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In the meantime, Git for Windows learned to handle those subcommands
quite well itself; There is no longer a need to special-case them in the
wrapper.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In a push to polish Git for Windows more, we are moving away from
scripts toward proper binaries.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Git wrapper does one thing, and does it well: setting up the
environment required to run Git and its scripts, and then hand off to
another program.
We already do this for the Git executable itself; in Git for Windows'
context, we have exactly the same need also when calling the Git Bash or
Git CMD. However, both are tied to what particular shell environment you
use, though: MSys or MSys2 (or whatever else cunning developers make
work for them). This means that the Git Bash and Git CMD need to be
compiled in the respective context (e.g. when compiling the
mingw-w64-git package in the MSys2 context).
Happily, Windows offers a way to configure compiled executables:
resources. So let's just look whether the current executable has a
string resource and use it as the command-line to execute after the
environment is set up. To support MSys2's Git Bash better (where
`mintty` should, but might not, be available), we verify whether the
specified executable exists, and keep looking for string resources if it
does not.
For even more flexibility, we expand environment variables specified as
`@@<VARIABLE-NAME>@@`, and for convenience `@@EXEPATH@@` expands into
the directory in which the executable resides.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Otherwise the output of Git commands cannot be caught by, say, Git GUI
(because it is running detached from any console, which would make
`git.exe` inherit the standard handles implicitly).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We are about to use the Git wrapper to call the Git Bash of Git for
Windows. All the wrapper needs to do for that is to set up the
environment variables, use the home directory as working directory and
then hand off to a user-specified command-line.
We prepare the existing code for this change by introducing flags to set
up the environment variables, to launch a non-Git program, and to use
the home directory as working directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The original purpose of the Git wrapper is to run from inside Git for
Windows' /cmd/ directory, to allow setting up some environment variables
before Git is allowed to take over.
Due to differences in the file system layout, MSys2 requires some
changes for that to work.
In addition, we must take care to set the `MSYSTEM` environment variable
to `MINGW32` or `MINGW64`, respectively, to allow MSys2 to be configured
correctly in case Git launches a shell or Perl script.
We also need to change the `TERM` variable to `cygwin` instead of
`msys`, otherwise the pager `less.exe` (spawned e.g. by `git log`) will
simply crash with a message similar to this one:
1 [main] less 9832 cygwin_exception::open_stackdumpfile:
Dumping stack trace to less.exe.stackdump
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This reduces the disk footprint of a full Git for Windows setup
dramatically because on Windows, one cannot assume that hard links are
supported.
The net savings are calculated easily: the 32-bit `git.exe` file weighs
in with 7662 kB while the `git-wrapper.exe` file (modified to serve as a
drop-in replacement for builtins) weighs a scant 21 kB. At this point,
there are 109 builtins which results in a total of 813 MB disk space
being freed up by this commit.
Yes, that is really more than half a gigabyte.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git started out as a bunch of separate commands, in the true Unix spirit.
Over time, more and more functionality was shared between the different
Git commands, though, so it made sense to introduce the notion of
"builtins": programs that are actually integrated into the main Git
executable.
These builtins can be called in two ways: either by specifying a
subcommand as the first command-line argument, or -- for backwards
compatibility -- by calling the Git executable hardlinked to a filename
of the form "git-<subcommand>". Example: the "log" command can be called
via "git log <parameters>" or via "git-log <parameters>". The latter
form is actually deprecated and only supported for scripts; calling
"git-log" interactively will not even work by default because the
libexec/git-core/ directory is not in the PATH.
All of this is well and groovy as long as hard links are supported.
Sadly, this is not the case in general on Windows. So it actually hurts
quite a bit when you have to fall back to copying all of git.exe's
currently 7.5MB 109 times, just for backwards compatibility.
The simple solution would be to install really trivial shell script
wrappers in place of the builtins:
for builtin in $BUILTINS
do
rm git-$builtin.exe
printf '#!/bin/sh\nexec git %s "$@"\n' $builtin > git-builtin
chmod a+x git-builtin
done
This method would work -- even on Windows because Git for Windows ships a
full-fledged Bash. However, the Windows Bash comes at a price: it needs to
spin up a full-fledged POSIX emulation layer everytime it starts.
Therefore, the shell script solution would incur a significant performance
penalty.
The best solution the Git for Windows team could come up with is to extend
the Git wrapper -- that is needed to call Git from cmd.exe anyway, and
that weighs in with a scant 19KB -- to also serve as a drop-in replacement
for the builtins so that the following workaround is satisfactory:
for builtin in $BUILTINS
do
cp git-wrapper.exe git-$builtin.exe
done
This commit allows for this, by extending the module file parsing to
turn builtin command names like `git-log.exe ...` into calls to the main
Git executable: `git.exe log ...`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This prepares the wrapper for modifications to serve as a drop-in
replacement for the builtins.
This commit's diff is best viewed with the `-w` flag.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We take care to embed the manifest, too, because we will modify the
wrapper in the next few commits to serve as a drop-in replacement for
the built-ins, i.e. we will want to call the wrapper under names such
as 'git-patch-id.exe', too.
To allow 32-bit and 64-bit builds in the same directory, we let
git-wrapper.o depend on GIT-PREFIX so that it gets recompiled when
compiling for a different architecture.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, Git is faced by the challenge that it has to set up certain
environment variables before running Git under special circumstances
such as when Git is called directly from cmd.exe (i.e. outside any
Bash environment).
This source code was taken from msysGit's commit 74a198d:
https://github.com/msysgit/msysgit/blob/74a198d/src/git-wrapper/git-wrapper.c
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Many a test requires either POSIXPERM (to change the executable bit) or
SYMLINKS, and neither are available on Windows.
This lets t9100-git-svn-basic.sh pass in Git for Windows' SDK.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The file was renamed in 4ad21f5 (README: use markdown syntax,
2016-02-25), but that commit forgot to update git.spec.in, which
caused the rpmbuild target in the Makefile to fail.
Reported-by: Ron Isaacson <isaacson.ljits@gmail.com>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The CreateProcessW() function does not really support spaces in its
first argument, lpApplicationName. But it supports passing NULL as
lpApplicationName, which makes it figure out the application from the
(possibly quoted) first argument of lpCommandLine.
Let's use that trick (if we are certain that the first argument matches
the executable's path) to support launching programs whose path contains
spaces.
This fixes https://github.com/git-for-windows/git/issue/692
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
GDB cannot handle executables compiled with ASLR support, and it has
serious problems figuring out source code locations corresponding to the
current instruction pointer when compiled with -O2.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When a 1-line file is augmented by a second line, and the user tries to
stage that single line via the "Stage Line" context menu item, we do not
want to see "apply: corrupt patch at line 5".
The reason for this error was that the hunk header looks like this:
@@ -1 +1,2 @@
but the existing code expects the original range always to contain a
comma. This problem is easily fixed by cutting the string "1 +1,2"
(that Git GUI formerly mistook for the starting line) at the space.
This fixes https://github.com/git-for-windows/git/issues/515
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This fixes an issue where the Git wrapper would terminate upon Ctrl+C,
even in the case when its child process would *not* terminate.
Note: while the original intention was to fix running Git Bash in
ConsoleZ, the bug fix applies also to running
C:\Program Files\Git\bin\bash -l -i
in a cmd window.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
