I've been caught out

[gene heskett]

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,
And while it finds the patch file without it, its reporting an extra
operand. So whats todays syntax for a ../dir full of patches?

Example:
gene@coyote:~/Debian-arm/linux$ patch -p1 ../patches/*.patch
patch: ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on-
PREEMPT.patch: extra operand

And the man page doesn't address the 'extra operand' error.

Thanks all.

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>

[Thomas Schmitt]

Hi,

> gene@coyote:~/Debian-arm/linux$ patch -p1 ../patches/*.patch
> patch: ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on-
> PREEMPT.patch: extra operand

man patch says

patch [options] [originalfile [patchfile]]

With "patchfile" being singular i'd expect that it refuses if you give
more than one.
Further it does not look as if you give an "originalfile", which is demanded
by the common []-bracket around "originalfile [patchfile]".

So what file do you want to change by the patch ?
Does ../patches/*.patch evaluate to a single file ?

(I get that error if i give three dummy file arguments.
If i give two i get a lot of "Hunk ... FAILED at .." because my second
file is no properly formatted patch.
If i give one, the program waits for standard input.)


Have a nice day :)

Thomas

[to...@tuxteam.de]

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.

Cheers
--
t

[gene heskett]

On Monday, January 24, 2022 5:19:13 AM EST Thomas Schmitt wrote:
> Hi,
>
> > gene@coyote:~/Debian-arm/linux$ patch -p1 ../patches/*.patch
> > patch: ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on-
> > PREEMPT.patch: extra operand
>
> man patch says
>
> patch [options] [originalfile [patchfile]]
>
> With "patchfile" being singular i'd expect that it refuses if you give
> more than one.
> Further it does not look as if you give an "originalfile", which is
> demanded by the common []-bracket around "originalfile [patchfile]".
>
> So what file do you want to change by the patch ?
> Does ../patches/*.patch evaluate to a single file ?
>

No, its a directory with many patches. IMO patch should take them, in
their sorted order, until its out of patches. Or do we have a gui to
oversee that, something like kompare maybe? I'll take a look.

> (I get that error if i give three dummy file arguments.
> If i give two i get a lot of "Hunk ... FAILED at .." because my second
> file is no properly formatted patch.
> If i give one, the program waits for standard input.)
>
>
> Have a nice day :)
>
> Thomas
>

Thanks Thomas, stay well now.

[to...@tuxteam.de]

On Mon, Jan 24, 2022 at 06:08:57AM -0500, gene heskett wrote:
> On Monday, January 24, 2022 5:19:13 AM EST Thomas Schmitt wrote:
> > Hi,
> >
> > > gene@coyote:~/Debian-arm/linux$ patch -p1 ../patches/*.patch
> > > patch: ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on-
> > > PREEMPT.patch: extra operand
> >
> > man patch says
> >
> > patch [options] [originalfile [patchfile]]
> >
> > With "patchfile" being singular i'd expect that it refuses if you give
> > more than one.
> > Further it does not look as if you give an "originalfile", which is
> > demanded by the common []-bracket around "originalfile [patchfile]".
> >
> > So what file do you want to change by the patch ?
> > Does ../patches/*.patch evaluate to a single file ?
> >
> No, its a directory with many patches. IMO patch should take them, in
> their sorted order, until its out of patches.

The man page disagrees with you on that, as Thomas notes :)

> Or do we have a gui to
> oversee that, something like kompare maybe? I'll take a look.

See my other answer for a quick-and-dirty proposal. There are several
patch managers around which help you on that -- quilt is one of them.

Cheers
--
tomás

[Thomas Schmitt]

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.

[Mark Allums]

There exist tools for this. What about quilt?

Mark A.

[Greg Wooledge]

On Mon, Jan 24, 2022 at 05:01:21AM -0500, gene heskett wrote:

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

That's not how you do it. patch(1) can only accept one patch at a time,
and it expects to see it on standard input.

for p in ../patches/*.patch; do patch -p1 < "$p"; done

[to...@tuxteam.de]

On Mon, Jan 24, 2022 at 03:15:17PM -0500, gene heskett wrote:

[...]

> And that might be the magic twanger, thank you Thomas. I'm finding it
> harder and harder to think 'outside the box'.

very glad if some of my wall of text helps :)

take care
--
tomás

[gene heskett]

And once I had wrapped my brain around quilt, it just worked, the result
is building right now. Thanks a bunch.

> Cheers
Take care Thomas.

[gene heskett]

And that might be the magic twanger, thank you Thomas. I'm finding it
harder and harder to think 'outside the box'.

> Cheers

[Urs Thuermann]

You can even do the somewhat easier

cat ../patches/*.patch | patch -p1

which will do the same.

However, often the order of patches is important when some patch
depends on another being applied before. Then *.patch will probably
not work since it applies patches in alphabetical order. That's, why
I also like to work with quilt a lot. With quilt, the patches/series
file describes the patch series, i.e. the order in which patches have
to be applied. With "quilt push" and "quilt pop" you can apply and
remove single patches, or go to a specific patch with "quilt push
<name>" (or "quilt pop <name>"), or apply/remove all patches with
"quilt push -a" and "quilt pop -a". Always in the correct order.

urs

[Greg Wooledge]

On Tue, Jan 25, 2022 at 09:12:52AM +0100, Urs Thuermann wrote:
> Greg Wooledge <gr...@wooledge.org> writes:
>
> > On Mon, Jan 24, 2022 at 05:01:21AM -0500, gene heskett wrote:
> > > gene@coyote:~/Debian-arm/linux$ patch -p1 ../patches/*.patch
> >
> > That's not how you do it. patch(1) can only accept one patch at a time,
> > and it expects to see it on standard input.
> >
> > for p in ../patches/*.patch; do patch -p1 < "$p"; done
>
> You can even do the somewhat easier
>
> cat ../patches/*.patch | patch -p1
>
> which will do the same.
>
> However, often the order of patches is important when some patch
> depends on another being applied before. Then *.patch will probably
> not work since it applies patches in alphabetical order.

It will work if whoever distributed the patches has half a clue. Any
such individual will name the patches with a sortable prefix, like
00- 01- 02- . Or *something* similar, so that the glob returns the
patches in the correct order.

If this hasn't been done, then the end user would somehow have to deduce
the correct order in which to apply the patches. How an end user would
guess this is beyond me.

[Vincent Lefevre]

On 2022-01-25 09:12:52 +0100, Urs Thuermann wrote:
> Greg Wooledge <gr...@wooledge.org> writes:
> > On Mon, Jan 24, 2022 at 05:01:21AM -0500, gene heskett wrote:
> > > gene@coyote:~/Debian-arm/linux$ patch -p1 ../patches/*.patch
> >
> > That's not how you do it. patch(1) can only accept one patch at a time,
> > and it expects to see it on standard input.
> >
> > for p in ../patches/*.patch; do patch -p1 < "$p"; done
>
> You can even do the somewhat easier
>
> cat ../patches/*.patch | patch -p1
>
> which will do the same.

Even easier (works with zsh, multios enabled, which is the default):

patch -p1 < ../patches/*.patch

> However, often the order of patches is important when some patch
> depends on another being applied before. Then *.patch will probably
> not work since it applies patches in alphabetical order.

Sometimes patch names are prepended with a number with a fixed number
of digits (e.g., 3) to make sure that this works.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[to...@tuxteam.de]

On Tue, Jan 25, 2022 at 01:33:45PM +0100, Vincent Lefevre wrote:
> On 2022-01-25 09:12:52 +0100, Urs Thuermann wrote:
> > Greg Wooledge <gr...@wooledge.org> writes:

[...]

> > You can even do the somewhat easier
> >
> > cat ../patches/*.patch | patch -p1
> >
> > which will do the same.
>
> Even easier (works with zsh, multios enabled, which is the default):
>
> patch -p1 < ../patches/*.patch

But exactly that was the original poster's problem. With his shell (most
probably bash) this leads to an "ambiguous redirect". Your zsh does an
implicit cat when it sees multiple files.

> > However, often the order of patches is important when some patch
> > depends on another being applied before. Then *.patch will probably
> > not work since it applies patches in alphabetical order.
>
> Sometimes patch names are prepended with a number with a fixed number
> of digits (e.g., 3) to make sure that this works.

Yes, this is an independent issue. The OP's patches (at least one of
them, but we do induction :) are prepended by leading-zero four-digit
numbers, so assuming they are intended to be ordered by that seems low
risk ;-)

Cheers
--
t

[gene heskett]

> .
Now, now, all we have to do it learn how to use quilt. So
sudo apt install quilt.

The man page isn't very explicit, other than giving you an ascii graphic
of the directory tree it expects to run in. But does point you at the
.pdf site, and after re-reading it several times and putting the
directory full of unpacked patches where it wants it to be, it got
simple. The secret is that the patches.xz file when unpacked, contains a
"series" file as the whole archive was created by quilt in the first
place. This file gives the order to apply them in.

quilt push

up arrow, hit return, does it one at a time in the correct order until
its out of patches and complains, or from further reading

quilt push -a

would have done them all in the same order. But I wasn't that brave.

So now the newest, bleeding edge kernel has been built, on the pi running
uptodate buster, and I've written 2 cards with the raspios release image,
edited both of those images to add a fallback net config to /etc/
dhcpdp.conf so I stand a small chance of having a working network on the
first boot, and will hand carry those cards to my rpi4b and test them in
the next hour or so.

Theoretically, all _I_ should have to do once its booted is open a shell,
and

sudo mkdir /mnt/sdb1
sudu mount -text4 /dev/sdb1 /mnt/sdb1
cd to /mnt/sdb1/arm.src/apt-rt.stf/linux
sudo make modules_install dtbs_install install

look to see if it did. and then reboot the pi. In my case, and a reboot
works, a uname -a should show a v5.16.3-rt kernel is running.

Theoretically... But have a 12 gauge loaded with 00 buck handy in case
that guy Murphy has snuck around and drunk your last beer. :-(