Am So., 5. Jan. 2025 um 18:47 Uhr schrieb Jim Meyering <[email protected]>: > Hi Andreas, > > Do you have plans to make GNU patch handle diff output with > encoded (newline-containing) names like in the examples below?
GNU patch did accept newlines in filenames until the following commit from Paul: [] commit 4278b919422cdafa94118bd4f1435911c435c23a [] Author: Paul Eggert <[email protected]> [] Date: Wed Aug 28 13:51:55 2024 -0700 [] [] Reject output file names containing '\n' [] [] This is encouraged by POSIX.1-2004. This should probably refer to POSIX 1003.1-2024 which seems to be when the following statement was added (https://pubs.opengroup.org/onlinepubs/9799919799/utilities/patch.html): [] FUTURE DIRECTIONS [] [] If this utility is directed to create a new directory entry that contains any bytes that have the encoded value of a <newline> character, [] implementations are encouraged to treat this as an error. [] A future version of this standard may require implementations to treat this as an error. The corresponding statement for diff (https://pubs.opengroup.org/onlinepubs/9799919799/utilities/diff.html) reads: [] FUTURE DIRECTIONS [] [] If this utility is directed to display a pathname that contains any bytes that have the encoded value of a <newline> character [] when <newline> is a terminator or separator in the output format being used, implementations are encouraged to treat this as an error. [] A future version of this standard may require implementations to treat this as an error. I'm not sure about the intention behind those two conflicting statements. Any thoughts? Thanks, Andreas > Thanks, > Jim > > ---------- Forwarded message --------- > From: Jim Meyering <[email protected]> > Date: Sun, Jan 5, 2025 at 9:44 AM > Subject: Re: [bug-diffutils] bug#68695: Please, fix documentation on > whitespace in pathnames > To: Matěj Cepl <[email protected]> > Cc: <[email protected]>, Andreas Gruenbacher <[email protected]> > > > On Wed, Jan 24, 2024 at 11:16 AM Matěj Cepl <[email protected]> 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.
