On Tue, Apr 05, 2005 at 03:40:44AM -0400, A. Costa wrote:
> 4) After 'diff -u' it looks like:
>
> zdiff -u /usr/share/man/man1/bash.1.gz /tmp/bash.1.gz | nl
> 1 --- - 2005-04-05 02:46:14.076698000 -0400
> 2 +++ /tmp/bash1.gz.12990 2005-04-05 02:46:14.070147316 -0400
> 3 @@ -5558,7 +5558,7 @@
> 4 semicolons where necessary to preserve syntactic correctness.
> 5 The
> 6 .B lithist
> 7 -shell option causes the shell to save the command with embedded
> newlines
> 8 +swell shell option causes the shell to save the command with
> embedded newlines
> 9 instead of semicolons. See the description of the
> 10 .B shopt
> 11 builtin below under
> 12 @@ -5568,7 +5568,7 @@
> 13 .SH "HISTORY EXPANSION"
> 14 .PP
> 15 The shell supports a history expansion feature that
> 16 -is similar to the history expansion in
> 17 +is so similar to the history expansion in
> 18 .BR csh.
> 19 This section describes what syntax features are available. This
> 20 feature is enabled by default for interactive shells, and can be
>
> Longer!
It's supposed to be longer. This is a feature. :-)
> So, my question is about the 'FROM-FILE' and 'TO-FILE'. In my 'bash'
> example, 'FROM-FILE' was "-", and 'TO-FILE' was "/tmp/bash1.gz".
> Transient names.
>
> So I'm worrying if such transient local filenames are useful, or
> harmful if they cause patching programs to look for files that don't
> exist on a maintainer's system.
They're useless in this case, but generally harmless. It's the job of
'patch' to figure out which files should be patched. If it can't figure
it out, there are alternative ways of invoking 'patch' to make it do the
right thing (you can give it an explicit file to patch).
I would suggest generating patches using the source package, not the man
page that happens to be installed on your system. Man pages are often
generated automatically from other formats, and in that event the patch
will have to be applied by hand anyway if you created it using the
generated version. Patches against files in binary packages are only
haphazardly useful at best.
> Plain vanilla 'diff' seemed safer, and nobody complained until now,
> though maybe they should have.
They probably should have complained, yes. The lack of context in plain
'diff' makes it unsafe; if you send patches like that, they can easily
end up patching the wrong lines. Plain 'diff' output is there for
purposes other than sending patches to maintainers, and for historical
reasons.
I imagine most maintainers ended up applying your changes by hand, and
your patches were small enough that it was less effort to just do that
than to ask for patches that could be applied automatically.
> Now IF it's possible to know what values of 'FROM-FILE' and 'TO-FILE'
> are most harmless, or better yet, are most useful for maintainers, I'd
> be glad to code that in to my man page typo bug report helper script
> ffffoooorrrrr the higher orthographic good!
>
> In a nutshell: What should 'FROM-FILE' and 'TO-FILE' be set to?
As long as the basename (everything from the last / onwards) of one of
those filenames, is the same as the file in the source package that the
maintainer will want to patch, it's easy for maintainers to deal with it
using well-known invocations of 'patch'.
It's conventional to send patches such that they can be applied by a
maintainer using 'patch -p0' or 'patch -p1' when standing in the top
level of the source package. This generally involves either:
* copying the original versions of some files in the source package to
their original names plus ".orig", making your changes, changing to
the top level of the source package, and then running 'diff -u
foo/bar/baz.orig foo/bar/baz' or similar for each in turn (patch
-p0);
* copying the entire original source package to its original name plus
".orig", making your changes, changing to the parent directory of
the source package, and then running 'diff -ru packagename-1.0.orig
packagename-1.0' or similar (patch -p1).
If you want to discuss this further, please remove
[EMAIL PROTECTED] from the Cc: line.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
