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 20:37:57 +0100

Am So., 5. Jan. 2025 um 20:19 Uhr schrieb Jim Meyering <jim@meyering.net>:
> 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

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



reply via email to

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