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
