Re: I've been caught out
On Monday, January 24, 2022 5:27:45 AM EST tomas@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>
Reply to: