bug-diffutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-diffutils] bug#68695: bug#68695: Please, fix documentation on whit


From: Jim Meyering
Subject: [bug-diffutils] bug#68695: bug#68695: Please, fix documentation on whitespace in pathnames
Date: Sun, 5 Jan 2025 09:44:20 -0800

On Wed, Jan 24, 2024 at 11:16 AM Matěj Cepl <mcepl@cepl.eu> wrote:
> https://www.gnu.org/software/diffutils/manual/html_node/Unusual-File-Names.html#Unusual%20File%20Names
> still contains rather disturbing information, that diffutils are
> incapable working with space in filenames/dirnames. I was just
> deciding to stop using quilt because of that information, when I
> was told clearly, that just the documentation is obsolete. Could
> somebody fix that page, please?

Thank you for reporting that. Here's the current text:

When a file name contains an unusual character like a newline or white
space, ‘diff -r’ generates a patch that ‘patch’ cannot parse.  The
problem is with format of ‘diff’ output, not just with ‘patch’, because
with odd enough file names one can cause ‘diff’ to generate a patch that
is syntactically correct but patches the wrong files.  The format of
‘diff’ output should be extended to handle all possible file names.

GNU diff's format now accommodates file names containing unusual
characters, GNU patch still fails to parse the resulting diff. Here's
a small demo:
This shows that the output format of diff -u **does** work with a
newline-afflicted file name:

$ f=$'a\na'; echo > "$f"; :>b; diff -u "$f" b
--- "a\na"      2025-01-05 09:32:36.678894920 -0800
+++ b   2025-01-05 09:32:36.678894920 -0800
@@ -1 +0,0 @@
-

Even "diff -r" encodes the unusually-named file:

$ mkdir -p 1 2; a=$'a\na'; echo > "1/$a"; :>"2/$a"; diff -r 1 2
diff -r "1/a\na" "2/a\na"
1d0
<

However, even the latest upstream version of GNU patch
(v2.7.6-202-g5bac274) cannot deal such an encoded file name:

$ f=$'a\na'; echo > "$f"; :>b; diff -u "$f" b |patch -R
patch: **** quoted string "a\n..." contains newline

So at the very least, I'll adjust the documentation to reflect the above.
Hoping that I can also soon say that upstream GNU patch handles these
encoded names.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]