Am So., 5. Jan. 2025 um 20:19 Uhr schrieb Jim Meyering <[email protected]>: > On Sun, Jan 5, 2025 at 10:44 AM Andreas Grünbacher > <[email protected]> wrote: > > 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? > > 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
Indeed, rejecting patches because they contain filenames that aren't even used is not helpful. > 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-afflicted 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. How about we change diff and patch to accept but warn about newlines in filenames? Andreas
