On Monday, January 24, 2022 5:27:45 AM EST to...@tuxteam.de wrote: > On Mon, Jan 24, 2022 at 05:01:21AM -0500, gene heskett wrote: > > Greetings all; > > > > I must admit its been quite a few years since the last time I used > > patch. Basck in the early 90's when the amiga was king in the > > graphic arts. And it then had a syntax of 'patch -p1 < > > path/to/patchfile' > > But now I have a ../patch directory with 50 or so files in it, and > > patch is spanking me, starting with an ambiguous redirect if the < > > is used, > This ain't patch. This is the shell. If you do > > foo < file > > ... then it's the shell's job to present file's content to foo on > stdin. Foo doesn't even get to see file "as a file on your file > system", just its content. Doing > > foo < file1 file2 file3... > > will lead the shell to present the complaint above. > > This might seem like superfluous nitpicking, but you won't understand > what's going on unless you know that. > > > And while it finds the patch file without it, its reporting an extra > > operand. So whats todays syntax for a ../dir full of patches? > > Now if you go to the patch man page (I know, I know :) you'll see that > patch can take /the/ patch file either on stdin or as an optional > second argument, instead of taking stdin. I emphasised /the/, because, > according to the man page, it doesn't expect more than one. So that > might be the extra operand complaint you are seeing... > > > Example: > > gene@coyote:~/Debian-arm/linux$ patch -p1 ../patches/*.patch > > patch: ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on- > > PREEMPT.patch: extra operand > > Yes, that's it: the expression "../patches/*.patch" gets expanded by > the shell to "../patches/foo.patch ../patches/bar.patch ..." and so > on, so your little /usr/bin/patch gets so see this long list of args. > No good. > > And the man page doesn't address the 'extra operand' error. > > Indirectly, yes: > > SYNOPSIS > patch [options] [originalfile [patchfile]] > but usually just > patch -pnum <patchfile > > ...means it takes options, optionally an orig file name, and only then, > optionally a patch file name (so if you want to provide the patch file > name, you /have/ to provide the original file name, it seems). > > Conclusion: you have to arrange for all those patches to be applied one > after the other, in some order. Guessing from your first one, they are > prefixed by a number, so that is most probably the one encoding that > order. > > You could try doing something along the lines of > > for f in ../patches/*.patch ; do > patch -p1 < "$f" > done > > Or you could have a look into quilt, which is supposed to automate such > things. > And that might be the magic twanger, thank you Thomas. I'm finding it harder and harder to think 'outside the box'. > Cheers
Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>