--exec doesn't work #542

ploeh · 2015-11-22T11:44:41Z

While doing an interactive rebase, --exec can be quite handy. Unfortunately, in the git-for-windows fork, this feature seems to no longer work.

Steps to reproduce

In summary:

Create a new repro
Add some commits
Add a script file
Interactively rebase, using --exec to run the script file between each commit.

Here are the detailed steps I used to reproduce the issue from Git Bash:

mark@Canopus MINGW64 ~/Desktop
$ mkdir exec-repro

mark@Canopus MINGW64 ~/Desktop
$ cd exec-repro/

mark@Canopus MINGW64 ~/Desktop/exec-repro
$ git init
Initialized empty Git repository in C:/Users/mark/Desktop/exec-repro/.git/

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ vim .gitignore

In .gitignore, I simply added one line:

*.sh

The I continued:

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ git add .gitignore
warning: LF will be replaced by CRLF in .gitignore.
The file will have its original line endings in your working directory.

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ git commit
[master (root-commit) 96bf28b] Added .gitignore
warning: LF will be replaced by CRLF in .gitignore.
The file will have its original line endings in your working directory.
 1 file changed, 1 insertion(+)
 create mode 100644 .gitignore

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ vim thefile.txt

In thefile.txt, I added first foo on one line, then, in two separate commits bar and baz:

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ git add .
warning: LF will be replaced by CRLF in thefile.txt.
The file will have its original line endings in your working directory.

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ git commit
[master 8a59b46] Added the file.
warning: LF will be replaced by CRLF in thefile.txt.
The file will have its original line endings in your working directory.
 1 file changed, 1 insertion(+)
 create mode 100644 thefile.txt

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ vim thefile.txt

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ git add .
warning: LF will be replaced by CRLF in thefile.txt.
The file will have its original line endings in your working directory.

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ git commit
warning: LF will be replaced by CRLF in thefile.txt.
The file will have its original line endings in your working directory.
[master warning: LF will be replaced by CRLF in thefile.txt.
The file will have its original line endings in your working directory.
c45a948] Added a line to the file.
warning: LF will be replaced by CRLF in thefile.txt.
The file will have its original line endings in your working directory.
 1 file changed, 1 insertion(+)

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ vim thefile.txt

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ git add .
warning: LF will be replaced by CRLF in thefile.txt.
The file will have its original line endings in your working directory.

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ git commit
warning: LF will be replaced by CRLF in thefile.txt.
The file will have its original line endings in your working directory.
[master warning: LF will be replaced by CRLF in thefile.txt.
The file will have its original line endings in your working directory.
6112987] Added a line to the file.
warning: LF will be replaced by CRLF in thefile.txt.
The file will have its original line endings in your working directory.
 1 file changed, 1 insertion(+)

Here's the log so far:

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ git log
commit 6112987c936ca3bff5b707d3e4655c8f1b60123d
Author: Mark Seemann <mark@ploeh.dk>
Date:   Sun Nov 22 12:11:16 2015 +0100

    Added a line to the file.

commit c45a948d2ebc268f24414bb5277d50bd85134b4d
Author: Mark Seemann <mark@ploeh.dk>
Date:   Sun Nov 22 12:10:34 2015 +0100

    Added a line to the file.

commit 8a59b460760551886c573c4059d83a560fd62155
Author: Mark Seemann <mark@ploeh.dk>
Date:   Sun Nov 22 12:10:10 2015 +0100

    Added the file.

commit 96bf28bc45c5a7e5d4b9f1fda02a62b127b4f499
Author: Mark Seemann <mark@ploeh.dk>
Date:   Sun Nov 22 12:09:25 2015 +0100

    Added .gitignore

Then I added a script file:

mark@Canopus MINGW64 ~/Desktop/exec-repro (master)
$ vim thescript.sh

The content of thescript.sh is simple:

#!/bin/bash
printf "Running the script."

Finally, I started an interactive rebase:

$ git rebase -i 8a59b460760551886c573c4059d83a560fd62155 --exec "./thescript.sh"

After having added some changes to thefile.txt, I issued git rebase --continue.

Expected result

I would expect the rebase to continue, executing thescript.sh between applying each commit.

Actual result

$ git rebase --continue
Executing: thescript.sh
/mingw64/libexec/git-core/git-rebase--interactive: line 613: C:/Program: No such file or directory
Execution failed: thescript.sh
You can fix the problem, and then run

        git rebase --continue

It's possible to execute thescript.sh manually from the command line:

$ ./thescript.sh
Running the script.

After each git rebase --continue, though, the above error happens.

Environment information

This is my environment:

$ git --version
git version 2.6.3.windows.1

I'm on Windows 10 Pro x64.

The text was updated successfully, but these errors were encountered:

kgybels · 2015-11-23T11:38:53Z

It fails at line 613 in the git-rebase--interactive script:
${SHELL:-/bin/sh} -c "$rest" # Actual execution

Because SHELL is set to C:/Program Files/Git/usr/bin/bash.

Adding quotes like this fixes the problem:
"${SHELL:-/bin/sh}" -c "$rest" # Actual execution

@dscho Should we get this change (i.e. adding the quotes to the shell invocation) to upstream git? Or do we need to figure out why SHELL is not set to /usr/bin/bash instead?

dscho · 2015-11-23T13:24:41Z

Or do we need to figure out why SHELL is not set to /bin/bash instead?

@kgybels we need to figure this one out. That will "kill a couple of tickets with one stone".

When calling a non-MSys2 binary, all of the environment is converted from POSIX to Win32, including the SHELL environment variable. In Git for Windows, for example, `SHELL=/usr/bin/bash` is converted to `SHELL=C:\Program Files\Git\usr\bin\bash.exe` when calling the `git.exe` binary. This is appropriate because non-MSys2 binaries would not handle POSIX paths correctly. Under certain circumstances, however, `git.exe` calls an *MSys2* binary in turn, such as `git config --edit` calling `vim.exe` unless Git is configured to use another editor specifically. Now, when this "improved vi" calls shell commands, it uses that $SHELL variable *without quoting*, resulting in a nasty error: C:\Program: No such file or directory Many other programs behave in the same manner, assuming that $SHELL does not contain spaces and hence needs no quoting, unfortunately including some of Git's own scripts. Therefore let's make sure that $SHELL gets "posified" again when entering MSys2 programs. This fixes git-for-windows/git#542, git-for-windows/git#498, and git-for-windows/git#468. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho · 2015-11-23T19:19:31Z

@ploeh @kgybels if you have time, would you please build the msys2-runtime from my posify_shell branch and test?

When calling a non-MSys2 binary, all of the environment is converted from POSIX to Win32, including the SHELL environment variable. In Git for Windows, for example, `SHELL=/usr/bin/bash` is converted to `SHELL=C:\Program Files\Git\usr\bin\bash.exe` when calling the `git.exe` binary. This is appropriate because non-MSys2 binaries would not handle POSIX paths correctly. Under certain circumstances, however, `git.exe` calls an *MSys2* binary in turn, such as `git config --edit` calling `vim.exe` unless Git is configured to use another editor specifically. Now, when this "improved vi" calls shell commands, it uses that $SHELL variable *without quoting*, resulting in a nasty error: C:\Program: No such file or directory Many other programs behave in the same manner, assuming that $SHELL does not contain spaces and hence needs no quoting, unfortunately including some of Git's own scripts. Therefore let's make sure that $SHELL gets "posified" again when entering MSys2 programs. Earlier attempts by Git for Windows contributors claimed that adding `SHELL` to the `conv_envvars` array does not have the intended effect. These reports just missed that the `conv_start_chars` array (which makes the code more performant) needs to be adjusted, too. Note that we set the `immediate` flag to `true` so that the environment variable is set immediately by the MSys2 runtime, i.e. not only spawned processes will see the POSIX-ified `SHELL` variable, but the MSys2 runtime *itself*, too. This fixes git-for-windows/git#542, git-for-windows/git#498, and git-for-windows/git#468. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

ploeh · 2015-11-30T09:02:09Z

I've now tested with the posify_shell branch, and it looks like it solves the problem:

$ git rebase --continue
Executing: ./thescript.sh
Executing: ./thescript.shng (3/6)
Executing: ./thescript.shng (5/6)
Running the script.Successfully rebased and updated refs/heads/master.

It looks funny that for some reason ng is appended to the shell output...

dscho · 2015-11-30T13:23:10Z

@ploeh thanks for testing.

It looks funny that for some reason ng is appended to the shell output...

That is not what is happening. When rebasing, the progress is shown as "Rebasing (m/n)" followed by a single carriage return without a line feed. The line then gets partially overwritten by the "Executing" line. (Yes, there is probably some prefix before the "Rebasing" line because it would otherwise not be long enough.)

This works around the problem described in git-for-windows#542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This works around the problem described in #542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho · 2015-12-15T14:16:57Z

This issue has been addressed in Git for Windows 2.6.4.

ploeh · 2015-12-27T17:46:02Z

Thank you for fixing this issue 👍

I finally had the opportunity to do an interactive rebase on a 'real' programming project with this new version of Git, and I can confirm that --exec now works 😄

This works around the problem described in #542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When calling a non-MSys2 binary, all of the environment is converted from POSIX to Win32, including the SHELL environment variable. In Git for Windows, for example, `SHELL=/usr/bin/bash` is converted to `SHELL=C:\Program Files\Git\usr\bin\bash.exe` when calling the `git.exe` binary. This is appropriate because non-MSys2 binaries would not handle POSIX paths correctly. Under certain circumstances, however, `git.exe` calls an *MSys2* binary in turn, such as `git config --edit` calling `vim.exe` unless Git is configured to use another editor specifically. Now, when this "improved vi" calls shell commands, it uses that $SHELL variable *without quoting*, resulting in a nasty error: C:\Program: No such file or directory Many other programs behave in the same manner, assuming that $SHELL does not contain spaces and hence needs no quoting, unfortunately including some of Git's own scripts. Therefore let's make sure that $SHELL gets "posified" again when entering MSys2 programs. Earlier attempts by Git for Windows contributors claimed that adding `SHELL` to the `conv_envvars` array does not have the intended effect. These reports just missed that the `conv_start_chars` array (which makes the code more performant) needs to be adjusted, too. Note that we set the `immediate` flag to `true` so that the environment variable is set immediately by the MSys2 runtime, i.e. not only spawned processes will see the POSIX-ified `SHELL` variable, but the MSys2 runtime *itself*, too. This fixes git-for-windows/git#542, git-for-windows/git#498, and git-for-windows/git#468. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This works around the problem described in git-for-windows#542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When calling a non-MSys2 binary, all of the environment is converted from POSIX to Win32, including the SHELL environment variable. In Git for Windows, for example, `SHELL=/usr/bin/bash` is converted to `SHELL=C:\Program Files\Git\usr\bin\bash.exe` when calling the `git.exe` binary. This is appropriate because non-MSys2 binaries would not handle POSIX paths correctly. Under certain circumstances, however, `git.exe` calls an *MSys2* binary in turn, such as `git config --edit` calling `vim.exe` unless Git is configured to use another editor specifically. Now, when this "improved vi" calls shell commands, it uses that $SHELL variable *without quoting*, resulting in a nasty error: C:\Program: No such file or directory Many other programs behave in the same manner, assuming that $SHELL does not contain spaces and hence needs no quoting, unfortunately including some of Git's own scripts. Therefore let's make sure that $SHELL gets "posified" again when entering MSys2 programs. Earlier attempts by Git for Windows contributors claimed that adding `SHELL` to the `conv_envvars` array does not have the intended effect. These reports just missed that the `conv_start_chars` array (which makes the code more performant) needs to be adjusted, too. Note that we set the `immediate` flag to `true` so that the environment variable is set immediately by the MSys2 runtime, i.e. not only spawned processes will see the POSIX-ified `SHELL` variable, but the MSys2 runtime *itself*, too. This fixes git-for-windows/git#542, git-for-windows/git#498, and git-for-windows/git#468. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This works around the problem described in git-for-windows#542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When calling a non-MSys2 binary, all of the environment is converted from POSIX to Win32, including the SHELL environment variable. In Git for Windows, for example, `SHELL=/usr/bin/bash` is converted to `SHELL=C:\Program Files\Git\usr\bin\bash.exe` when calling the `git.exe` binary. This is appropriate because non-MSys2 binaries would not handle POSIX paths correctly. Under certain circumstances, however, `git.exe` calls an *MSys2* binary in turn, such as `git config --edit` calling `vim.exe` unless Git is configured to use another editor specifically. Now, when this "improved vi" calls shell commands, it uses that $SHELL variable *without quoting*, resulting in a nasty error: C:\Program: No such file or directory Many other programs behave in the same manner, assuming that $SHELL does not contain spaces and hence needs no quoting, unfortunately including some of Git's own scripts. Therefore let's make sure that $SHELL gets "posified" again when entering MSys2 programs. Earlier attempts by Git for Windows contributors claimed that adding `SHELL` to the `conv_envvars` array does not have the intended effect. These reports just missed that the `conv_start_chars` array (which makes the code more performant) needs to be adjusted, too. Note that we set the `immediate` flag to `true` so that the environment variable is set immediately by the MSys2 runtime, i.e. not only spawned processes will see the POSIX-ified `SHELL` variable, but the MSys2 runtime *itself*, too. This fixes git-for-windows/git#542, git-for-windows/git#498, and git-for-windows/git#468. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho added bug msys2 labels Nov 23, 2015

dscho self-assigned this Nov 23, 2015

dscho added a commit to dscho/git that referenced this issue Nov 30, 2015

Merge branch 'rebase-i'

42939c6

This works around the problem described in git-for-windows#542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho added a commit that referenced this issue Dec 11, 2015

Merge branch 'rebase-i'

a996c85

This works around the problem described in #542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho added a commit that referenced this issue Dec 11, 2015

Merge branch 'rebase-i'

db866f8

This works around the problem described in #542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho closed this as completed Dec 15, 2015

dscho added a commit that referenced this issue Jan 5, 2016

Merge branch 'rebase-i'

b7006a8

This works around the problem described in #542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho added a commit to dscho/git that referenced this issue Jan 12, 2016

Merge branch 'rebase-i'

6b52d9f

This works around the problem described in git-for-windows#542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho added a commit to dscho/git that referenced this issue Jan 14, 2016

Merge branch 'rebase-i'

0f0e5d1

This works around the problem described in git-for-windows#542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho added a commit to dscho/git that referenced this issue Jan 23, 2016

Merge branch 'rebase-i'

55f9759

This works around the problem described in git-for-windows#542 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

git-for-windows-ci mentioned this issue Sep 6, 2022

[New msys2-runtime version] 19 new items #4009

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

--exec doesn't work #542

--exec doesn't work #542

ploeh commented Nov 22, 2015

kgybels commented Nov 23, 2015

dscho commented Nov 23, 2015

dscho commented Nov 23, 2015

ploeh commented Nov 30, 2015

dscho commented Nov 30, 2015

dscho commented Dec 15, 2015

ploeh commented Dec 27, 2015

--exec doesn't work #542

--exec doesn't work #542

Comments

ploeh commented Nov 22, 2015

Steps to reproduce

Expected result

Actual result

Environment information

kgybels commented Nov 23, 2015

dscho commented Nov 23, 2015

dscho commented Nov 23, 2015

ploeh commented Nov 30, 2015

dscho commented Nov 30, 2015

dscho commented Dec 15, 2015

ploeh commented Dec 27, 2015