Re: [PATCH 1/2 (fix broken test)] rebase -i: add exec command to launch a shell command
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:49:17
Possibly related (same subject, not in this thread)
- 2016-06-15 · Re: [PATCH 1/2 (fix broken test)] rebase -i: add exec command to launch a shell command · Matthieu Moy <hidden>
Matthieu Moy [off-list ref] writes:
The typical usage pattern would be to run a test (or simply a compilation command) at given points in history. The shell command is ran (from the worktree root), and the rebase is stopped when the command fails, to give the user an opportunity to fix the problem before continuing with "git rebase --continue". This needs a little rework of skip_unnecessary_picks, which wasn't robust enough to deal with lines like exec >"file name with many spaces" in the todolist. The new version extracts command, sha1 and rest from each line, but outputs the line itself verbatim to avoid changing the whitespace layout.
Thanks.
quoted hunk ↗ jump to hunk
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index 9f03ce6..93b181e 100755 --- a/t/t3404-rebase-interactive.sh +++ b/t/t3404-rebase-interactive.sh@@ -64,6 +64,67 @@ test_expect_success 'setup' ' done ' +# "exec" commands are ran with the user shell by default, but this may +# be non-POSIX. For example, if SHELL=zsh then ">file" doesn't work +# to create a file. Unseting SHELL avoids such non-portable behavior +# in tests. +SHELL=
Tricky but true. Do we have other callouts that we use $SHELL from the environment? execv_shell_cmd() just runs "sh -c" from $PATH so diff (when running external diff) nor ll-merge (when running external merge driver) that call it via run_command_v_opt(RUN_USING_SHELL) are immune to this issue.