📄 00000064.htm
字号:
<HTML><HEAD> <TITLE>BBS水木清华站∶精华区</TITLE></HEAD><BODY><CENTER><H1>BBS水木清华站∶精华区</H1></CENTER>发信人: reden (鱼 ~ 君子律己以利人), 信区: Linux <BR>标 题: Patch for Beginners <BR>发信站: BBS 水木清华站 (Mon Oct 5 00:14:17 1998) WWW-POST <BR> <BR>"Linux Gazette...making Linux just a little more fun!"
<BR>
<BR>
<BR>
<BR> Patch for Beginners
<BR>
<BR> By Larry Ayers
<BR>
<BR>
<BR>
<BR> Introduction
<BR>
<BR>The aim of this article is to introduce new Linux users to an invaluable <BR>resource, Larry Wall's patch program. Patch is an
<BR>interface to the GNU diff utility, which is used to find differences between <BR>files; diff has a multitude of options, but it's most often
<BR>used to generate a file which lists lines which have been changed, showing <BR>both the original and changed lines and ignoring lines
<BR>which have remained the same. Patch is typically used to update a directory <BR>of source code files to a newer version, obviating the
<BR>need to download an entire new source archive. Downloading a patch in effect <BR>is just downloading the lines which have been
<BR>changed.
<BR>
<BR>Patch originated in the nascent, bandwidth-constrained internet environment <BR>of a decade ago, but like many Unix tools of that era
<BR>it is still much-used today. In the February issue of the programmer's <BR>magazine Dr. Dobb's Journal Larry Wall had some
<BR>interesting comments on the early days of patch:
<BR>
<BR>
<BR>
<BR> DDJ: By the way, what came first, patch or diff?
<BR>
<BR> LW: diff, by a long ways. patch is one of those things
<BR> that, in retrospect, I was totally amazed that nobody had
<BR> thought of it sooner, because I think that diff predated
<BR> patch by at least ten years or so.
<BR>
<BR> I think I know why, though. And it's one of these little
<BR> psychological things. When they made diff, they added an
<BR> option called -e, I think it was, and that would spit out an
<BR> ed script, so people said to themselves, "Well, if I wanted
<BR> to automate the applying of a diff, I would use that." So it
<BR> never actually occurred to someone that you could write a
<BR> computer program to take the other forms of output and apply
<BR> them. Either that, or it did not occur to them that there
<BR> was some benefit to using the context diff form, because you
<BR> could apply it to something that had been changed and still
<BR> easily get it to do the right thing.
<BR>
<BR> It's one of those things that's obvious in retrospect. But
<BR> to be perfectly honest, it wasn't really a brilliant flash
<BR> of inspiration so much as self defense. I put out the first
<BR> version of rn, and then I started putting out patches for
<BR> it, and it was a total mess. You could not get people to
<BR> apply patches because they had to apply them by hand. So,
<BR> they would skip the ones that they didn't think they needed,
<BR> and they'd apply the new ones over that, and they'd get
<BR> totally messed up. I wrote patch so that they wouldn't have
<BR> this excuse that it was too hard.
<BR>
<BR> I don't know whether it's still the case, but for many
<BR> years, I told people that I thought patch had changed the
<BR> culture of computing more than either rn or Perl had. Now
<BR> that the Internet is getting a lot faster than it used to
<BR> be, and it's getting much easier to distribute whole
<BR> distributions, patches tend to be sent around only among
<BR> developers. I haven't sent out a patch kit for Perl in
<BR> years. I think patch has became less important for the
<BR> whole thing, but still continues to be a way for developers
<BR> to interchange ideas. But for a while in there, patch
<BR> really did make a big difference to how software was
<BR> developed.
<BR>
<BR>Larry Wall's assessment of the diminishing importance of patch to the <BR>computing community as a whole is probably accurate, but
<BR>in the free software world it's still an essential tool. The ubiquity of <BR>patch makes it possible for new users and non-programmers to
<BR>easily participate in alpha- and beta-testing of software, thus benefiting <BR>the entire community.
<BR>
<BR>It occurred to me to write this article after noticing a thread which <BR>periodically resurfaces in the linux-kernel mailing list. About
<BR>every three months someone will post a plea for a split Linux kernel source <BR>distribution, so that someone just interested in, say, the
<BR>i386 code and the IDE disk driver wouldn't have to download the Alpha, Sparc, <BR>etc. files and the many SCSI drivers for each new
<BR>kernel release. A series of patient (and some not-so-patient) replies will <BR>follow, most urging the original poster to use patches to
<BR>upgrade the kernel source. Linus Torvalds will then once again state that he <BR>has no interest in undertaking the laborious task of
<BR>splitting the kernel source into chunks, but that if anyone else wants to, <BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -