# t4109-apply-multifrag.sh problem on solaris -- looks like problem w/ solaris patch cmd

2 messages from 2008-03-04 to 2008-03-04. Participants: Whit Armstrong, Junio C Hamano.
Thread: https://gitlist.dev/t/12500

## Whit Armstrong, 2008-03-04 16:22

Subject: t4109-apply-multifrag.sh problem on solaris -- looks like problem w/ solaris patch cmd
Message-ID: <8ec76080803040822n5e463b50sff6639777246de7b@mail.gmail.com>
URL: https://gitlist.dev/e/8ec76080803040822n5e463b50sff6639777246de7b%40mail.gmail.com

```
using git current: c95b3ad9ea310ec89e31a21edecaaf2c374e2c46

xs5-trd-p1.grn:warmstro> sh t4109-apply-multifrag.sh -v -i
* expecting success: git apply patch1.patch patch2.patch
*   ok 1: S = git apply (1)

* expecting success: cat patch1.patch patch2.patch | patch -p1
  Looks like a unified context diff.
File to patch: ^CFATAL: Unexpected exit with code 3
xs5-trd-p1.grn:warmstro> sh t4109-apply-multifrag.sh -i -v
* expecting success: git apply patch1.patch patch2.patch
*   ok 1: S = git apply (1)

* expecting success: cat patch1.patch patch2.patch | patch -p1
  Looks like a unified context diff.
File to patch: ^CFATAL: Unexpected exit with code 3
xs5-trd-p1.grn:warmstro>

the test just hangs at "File to patch:" and I have to C^ to exit.

and that's exactly what I get executing the patch command myself:

xs5-trd-p1.grn:warmstro> cd trash/
xs5-trd-p1.grn:warmstro> cat patch1.patch patch4.patch | patch -p1
  Looks like a unified context diff.
File to patch:
No file found -- skip this patch? [no]
File to patch:
No file found -- skip this patch? [no] yes
Skipping patch...
  The next patch looks like a unified context diff.
File to patch: ^Cxs5-trd-p1.grn:warmstro>
xs5-trd-p1.grn:warmstro>


but with GNU patch-2.5.4 the test works (not sure what the failure is
at the end, but it looks like all the individual tests pass):


xs5-trd-p1.grn:warmstro> sh t4109-apply-multifrag.sh -i -v
* expecting success: git apply patch1.patch patch2.patch
*   ok 1: S = git apply (1)

* expecting success: cat patch1.patch patch2.patch | patch -p1
patching file main.c
patching file main.c
*   ok 2: S = patch (1)

* expecting success: cmp main.c.git main.c
*   ok 3: S = cmp (1)

* expecting success: git apply patch1.patch patch2.patch patch3.patch
*   ok 4: S = git apply (2)

* expecting success: cat patch1.patch patch2.patch patch3.patch | patch -p1
patching file main.c
patching file main.c
patching file main.c
*   ok 5: S = patch (2)

* expecting success: cmp main.c.git main.c
*   ok 6: S = cmp (2)

* expecting success: git apply patch1.patch patch4.patch
*   ok 7: S = git apply (3)

* expecting success: cat patch1.patch patch4.patch | patch -p1
patching file main.c
patching file main.c
*   ok 8: S = patch (3)

* expecting success: cmp main.c.git main.c
*   ok 9: S = cmp (3)

* passed all 9 test(s)
FATAL: Unexpected exit with code 0
xs5-trd-p1.grn:warmstro>


Again, this is on a Solaris 5.9 machine:
xs5-trd-p1.grn:warmstro> uname -a
SunOS xs5-trd-p1.grn.tudor.com 5.9 Generic_118558-38 sun4u sparc
SUNW,Sun-Fire-V240 Solaris
xs5-trd-p1.grn:warmstro>

Is the answer to use GNU patch? Or is there a trick to make the
Solaris version of patch work?

Thanks,
Whit

```

## Junio C Hamano, 2008-03-04 19:32

Subject: Re: t4109-apply-multifrag.sh problem on solaris -- looks like problem w/ solaris patch cmd
Message-ID: <7v3ar670aj.fsf@gitster.siamese.dyndns.org>
URL: https://gitlist.dev/e/7v3ar670aj.fsf%40gitster.siamese.dyndns.org
In-Reply-To: <8ec76080803040822n5e463b50sff6639777246de7b@mail.gmail.com>

```
"Whit Armstrong" <armstrong.whit@gmail.com> writes:

> * expecting success: git apply patch1.patch patch2.patch patch3.patch
> *   ok 4: S = git apply (2)
>
> * expecting success: cat patch1.patch patch2.patch patch3.patch | patch -p1
> patching file main.c
> patching file main.c
> patching file main.c
> *   ok 5: S = patch (2)
> ...
>
> Is the answer to use GNU patch? Or is there a trick to make the
> Solaris version of patch work?

If we are reasonably sure that we will not be needing to change these test
vectors (and because "git apply" is now solid, I think we are), I think
the best way to address this is to prepare a new t/t4109 directory, store
the expected output in there, and compare output from "git apply" that is
being tested with the precomputed test vectors.



```