Re: I've been caught out

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

gene heskett wrote:
> > > gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch

I wrote:
> > Does ../patches/*.patch evaluate to a single file ?

gene heskett wrote:
> No, its a directory with many patches.

So you effectively ran something like

  patch -p1  ../patches/abc.patch ../patches/bla.patch [maybe more] ../patches/zzzz.patch

This does not match any of the use cases in the man page.

At most two file paths are expected with:

       patch [options] [originalfile [patchfile]]

No file path at all is expected by

       patch -pnum <patchfile

because here - as tomas already explained - the shell opens patchfile
and sends its content into standard input of the "patch" program.
"patch" then takes the victim file paths from the patch text that comes
via standard input.

You seem to intend the latter use case which inherently is for a single
patch file. If they'd all get concatenated, then the "leading garbage" of
the second and further patch files would probably sabotage this task
description from the man page of "patch":

  patch  tries to skip any leading garbage, apply the diff, and then skip
  any trailing garbage.  Thus you could feed an article or  message  con‐
  taining  a  diff  listing  to patch, and it should work.


> IMO patch should take them, in
> their sorted order, until its out of patches.

That would be possible with the first use case. But there the developers
obviously decided to accept only a single patch file.
Well, you don't want this use case anyways. (Because you have no single
originalfile to give as argument before the .patch files.)


The shell offers means to create a workaround. Try:

  for i in ../patches/*.patch ; do patch <"$i" ; done

The for-do-done loop will run patch separately for each of your .patch
files.


Have a nice day :)

Thomas