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

[Jim Meyering]

On Sun, Jan 5, 2025 at 10:44 AM Andreas Grünbacher
<andreas.gruenbacher@gmail.com> wrote:
> 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?

Hi Andreas,

Thanks for the speedy response and those references.
Technically, I don't see how that POSIX guidance for patch can justify
this behavior, since patch's output file name is just "b" in this
example:

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

But their suggestion to diagnose or even fail for NL-afflicted file
names is fine advice, so I shouldn't be splitting hairs with the
example above. IMHO, it is fine and even desirable to discourage
NL-afflcted files.

Re my current question (how to adjust that diff manual section), I'm
happy to make it say that all special characters are covered,
**except** newline, whose presence in any file name is strongly
discouraged.