From: Michael Montalbo <mmontalbo@gmail.com>

When the configured subprocess command contains shell metacharacters (such as a space), prepare_shell_cmd() wraps it in "sh -c <cmd>". The shell itself always starts successfully, so start_command() returns zero even if the tool inside does not exist. The subsequent handshake then reads from a dead pipe and calls die() via the non-gentle packet_read_line(), killing the parent process instead of letting it handle the error.

Before this change, a missing filter process at a path containing spaces produces a confusing error:

    $ git -c filter.lfs.process="/path with space/tool" \
          -c filter.lfs.required=true add file.txt
    fatal: the remote end hung up unexpectedly

After this change, the proper error is reported:

    $ git ... add file.txt
    error: initialization for subprocess '/path with space/tool' failed
    fatal: file.txt: clean filter 'lfs' failed

Switch the subprocess handshake from the dying packet_read_line() to packet_read_line_gently() so that a process that exits during startup produces an error return instead of killing the caller.

This affects any subprocess consumer whose command path contains spaces. On Windows this routinely happens because programs live under "C:/Program Files/...", and MSYS2 path conversion can rewrite absolute paths to include that prefix. On POSIX it triggers whenever the configured path naturally contains a space or other metacharacter. convert.c (filter.<driver>.process, used by git-lfs and custom clean/smudge filters) is the primary affected consumer.

Signed-off-by: Michael Montalbo <mmontalbo@gmail.com>
---
    sub-process: use gentle handshake to avoid die() on startup failure

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2133%2Fmmontalbo%2Fmm%2Fsubprocess-handshake-fix-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2133/mmontalbo/mm/subprocess-handshake-fix-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2133

 sub-process.c         | 11 ++++++-----
 t/t0021-conversion.sh | 17 +++++++++++++++++
 2 files changed, 23 insertions(+), 5 deletions(-)

"Michael Montalbo via GitGitGadget" <gitgitgadget@gmail.com> writes:

If `packet_read_line_gently()` returns `< 0` (due to an EOF or read error), `line` will be `NULL`. The error message printed will be:

    `Unexpected line '<flush packet>', expected filter-server`

This is misleading when the remote process didn't send a flush packet; it hung up or crashed.

Ditto.

We catch error return (< 0) or a line with payload (!!line) and report an error here, because we want to see <flush> here. OK.

While this correctly stops the loop if packet_read_line_gently() returns a non-positive value, doesn't it introduce a subtle bug?

`packet_read_line_gently()` returns:

  - `> 0` for a normal line (which keeps the loop running).

  - `0` for a flush packet (which we expect as the normal terminator
    of the capabilities list, stopping the loop).

  - `< 0` for an EOF or read error (which also stops the loop).

In the original code, an EOF or read error would have caused `packet_read_line()` to call `die()`, aborting the process.

With the new code, if the child process dies or closes its pipe during the capabilities handshake, the loop will terminate, and the function will return `0` (success). The parent process will proceed as if the capabilities were successfully negotiated. Any further communication with the child process would fail so the damage may not be huge, but somebody must check if the loop terminated because of a flush packet, or an error.

	while (1) {
	        const char *p;
        	int len = packet_read_line_gently(process->out, NULL, &line);

		if (len < 0)
			return error(_("subprocess `%s` failed to give capabilities"),
				process->args.v[0]);
		if (!skip_prefix(line, "capability=", &p))
			continue;
		...

or something, perhaps?

On Sun, May 31, 2026 at 11:43 PM Junio C Hamano <gitster@pobox.com> wrote:

Makes sense. Will fix.

Will fix.

Good catch, thank you. I will update the logic so a failure during capabilities handshake is correctly marked an error instead of silently succeeding.

From: Michael Montalbo <mmontalbo@gmail.com>

When the configured subprocess command contains shell metacharacters (such as a space), prepare_shell_cmd() wraps it in "sh -c <cmd>". The shell itself always starts successfully, so start_command() returns zero even if the tool inside does not exist. The subsequent handshake then reads from a dead pipe and calls die() via the non-gentle packet_read_line(), killing the parent process instead of letting it handle the error.

Before this change, a missing filter process at a path containing spaces produces a confusing error:

    $ git -c filter.myfilter.process="/path with space/tool" \
          -c filter.myfilter.required=true add file.txt
    /path with space/tool: line 1: /path: No such file or directory
    fatal: the remote end hung up unexpectedly

After this change, the proper error is reported:

    $ git ... add file.txt
    /path with space/tool: line 1: /path: No such file or directory
    error: could not read greeting from subprocess '/path with space/tool'
    error: initialization for subprocess '/path with space/tool' failed
    fatal: file.txt: clean filter 'myfilter' failed

Switch the subprocess handshake from the dying packet_read_line() to packet_read_line_gently() so that a process that exits during startup produces an error return instead of killing the caller.

This affects any subprocess consumer whose command path contains spaces. On Windows this routinely happens because programs live under "C:/Program Files/...", and MSYS2 path conversion can rewrite absolute paths to include that prefix. On POSIX it triggers whenever the configured path naturally contains a space or other metacharacter. convert.c (filter.<driver>.process, used by git-lfs and custom clean/smudge filters) is the primary affected consumer.

Signed-off-by: Michael Montalbo <mmontalbo@gmail.com>
---
    sub-process: use gentle handshake to avoid die() on startup failure

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2133%2Fmmontalbo%2Fmm%2Fsubprocess-handshake-fix-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2133/mmontalbo/mm/subprocess-handshake-fix-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/2133

Range-diff vs v1:

 1:  c11b01c156 ! 1:  cb7bd777dc sub-process: use gentle handshake to avoid die() on startup failure
     @@ Commit message
          Before this change, a missing filter process at a path containing
          spaces produces a confusing error:
      
     -        $ git -c filter.lfs.process="/path with space/tool" \
     -              -c filter.lfs.required=true add file.txt
     +        $ git -c filter.myfilter.process="/path with space/tool" \
     +              -c filter.myfilter.required=true add file.txt
     +        /path with space/tool: line 1: /path: No such file or directory
              fatal: the remote end hung up unexpectedly
      
          After this change, the proper error is reported:
      
              $ git ... add file.txt
     +        /path with space/tool: line 1: /path: No such file or directory
     +        error: could not read greeting from subprocess '/path with space/tool'
              error: initialization for subprocess '/path with space/tool' failed
     -        fatal: file.txt: clean filter 'lfs' failed
     +        fatal: file.txt: clean filter 'myfilter' failed
      
          Switch the subprocess handshake from the dying packet_read_line()
          to packet_read_line_gently() so that a process that exits during
     @@ sub-process.c: static int handshake_version(struct child_process *process,
       		return error("Could not write flush packet");
       
      -	if (!(line = packet_read_line(process->out, NULL)) ||
     -+	if (packet_read_line_gently(process->out, NULL, &line) <= 0 ||
     - 	    !skip_prefix(line, welcome_prefix, &p) ||
     +-	    !skip_prefix(line, welcome_prefix, &p) ||
     ++	if (packet_read_line_gently(process->out, NULL, &line) < 0)
     ++		return error("could not read greeting from subprocess '%s'",
     ++			     process->args.v[0]);
     ++	if (!line || !skip_prefix(line, welcome_prefix, &p) ||
       	    strcmp(p, "-server"))
       		return error("Unexpected line '%s', expected %s-server",
       			     line ? line : "<flush packet>", welcome_prefix);
      -	if (!(line = packet_read_line(process->out, NULL)) ||
     -+	if (packet_read_line_gently(process->out, NULL, &line) <= 0 ||
     - 	    !skip_prefix(line, "version=", &p) ||
     +-	    !skip_prefix(line, "version=", &p) ||
     ++	if (packet_read_line_gently(process->out, NULL, &line) < 0)
     ++		return error("could not read version from subprocess '%s'",
     ++			     process->args.v[0]);
     ++	if (!line || !skip_prefix(line, "version=", &p) ||
       	    strtol_i(p, 10, chosen_version))
       		return error("Unexpected line '%s', expected version",
       			     line ? line : "<flush packet>");
      -	if ((line = packet_read_line(process->out, NULL)))
     --		return error("Unexpected line '%s', expected flush", line);
     -+	if (packet_read_line_gently(process->out, NULL, &line) < 0 || line)
     -+		return error("Unexpected line '%s', expected flush",
     -+			     line ? line : "<read error>");
     ++	if (packet_read_line_gently(process->out, NULL, &line) < 0)
     ++		return error("could not read version flush from subprocess '%s'",
     ++			     process->args.v[0]);
     ++	if (line)
     + 		return error("Unexpected line '%s', expected flush", line);
       
       	/* Check to make sure that the version received is supported */
     - 	for (i = 0; versions[i]; i++) {
      @@ sub-process.c: static int handshake_capabilities(struct child_process *process,
       	if (packet_flush_gently(process->in))
       		return error("Could not write flush packet");
       
      -	while ((line = packet_read_line(process->out, NULL))) {
     -+	while (packet_read_line_gently(process->out, NULL, &line) > 0) {
     ++	for (;;) {
       		const char *p;
     ++		int len = packet_read_line_gently(process->out, NULL, &line);
     ++
     ++		if (len < 0)
     ++			return error("could not read capabilities from subprocess '%s'",
     ++				     process->args.v[0]);
     ++		if (!line)
     ++			break;
       		if (!skip_prefix(line, "capability=", &p))
       			continue;
     + 
      
       ## t/t0021-conversion.sh ##
      @@ t/t0021-conversion.sh: test_expect_success 'invalid process filter must fail (and not hang!)' '

 sub-process.c         | 26 ++++++++++++++++++++------
 t/t0021-conversion.sh | 17 +++++++++++++++++
 2 files changed, 37 insertions(+), 6 deletions(-)