bug-patch
[Top][All Lists]
Advanced

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

Re: [bug-diffutils] bug#68695: Please, fix documentation on whitespace i


From: Andreas Grünbacher
Subject: Re: [bug-diffutils] bug#68695: Please, fix documentation on whitespace in pathnames
Date: Sun, 5 Jan 2025 19:43:48 +0100

Am So., 5. Jan. 2025 um 18:47 Uhr schrieb Jim Meyering <jim@meyering.net>:
> 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 <eggert@cs.ucla.edu>
[] 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 <jim@meyering.net>
> 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 <mcepl@cepl.eu>
> Cc: <68695@debbugs.gnu.org>, Andreas Gruenbacher <agruen@linbit.com>
>
>
> 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]