diff(1) -N behaviour - Bug 233402
Chris
bsd-lists at BSDforge.com
Thu May 28 16:50:32 UTC 2020
On Thu, 28 May 2020 11:21:16 +0200 Baptiste Daroussin bapt at FreeBSD.org said
> On 2020-05-28 08:26, Chris wrote:
> > On Wed, 27 May 2020 11:06:52 +0200 Baptiste Daroussin bapt at FreeBSD.org
> > said
> >
> >> On Wed, May 27, 2020 at 08:52:38PM +1200, Fehmi Noyan ISI via
> >> freebsd-hackers
> >> wrote:
> >> > > > > On 23/05/2020, at 11:47 PM, Yuri Pankov <ypankov at fastmail.com>
> > wrote:
> >> > > > > Fehmi Noyan ISI via freebsd-hackers wrote:
> >> > >>> On 23/05/2020, at 11:21 PM, Yuri Pankov <ypankov at fastmail.com> wrote:
> >> > >>> > >>> Fehmi Noyan ISI via freebsd-hackers wrote:
> >> > >>>> Hiya
> >> > >>>> Apparently, after we switched from GNU diff to BSD diff, the -N flag
> > no
> >> > longer assumes absent files as empty.
> >> > >>>> There is a bug report about GNU diff compatibility but when I look
> > at
> >> > diff(1) man page, I see that not treating absent files as empty is
> > intentional
> >> > rather than a missing functionality.
> >> > >>>> If this is not the case, I can work on patch to match to GNU diff
> >> > behaviour, otherwise, this bug report can be closed I think.
> >> > >>>> What’s your take on this?
> >> > >>>> -N --new-file
> >> > >>>> If a file is found in only one directory, act as if it was found
> >> > >>>> in the other directory too but was of zero size.
> >> > >>>> man for GNU diff
> >> > >>>> -N, --new-file
> >> > >>>> treat absent files as empty
> >> > >>> > >>> I think both descriptions say the same, i.e. "zero size" ==
> > "empty”?
> >> > >> Maybe it’s my interpretation, but if you do not supply the second
> >> > argument to diff(1), it complains
> >> > >> $ echo “test” > a.txt
> >> > >> $ diff -N a.txt nofile
> >> > >> diff: nofile: No such file or directory
> >> > >> $
> >> > >> GNU diff assumes an empty file for the missing second file and makes
> > the
> >> > comparison
> >> > >> $ echo “test” > a.txt
> >> > >> $ diff -N a.txt nofile
> >> > >> 1d0
> >> > >> < test
> >> > >> $
> >> > > > > I must admit that I never used -N without -r, so it's probably the
> > only
> >> > case that needs fixing?
> >> > > > > $ mkdir a b
> >> > > $ echo bar > a/foo
> >> > > $ diff -ruN a b
> >> > > diff -ruN a/foo b/foo
> >> > > --- a/foo 2020-05-23 14:44:34.525932000 +0300
> >> > > +++ b/foo 1970-01-01 03:00:00.000000000 +0300
> >> > > @@ -1 +0,0 @@
> >> > > -bar
> >> > > > > Took me a while to reply…
> >> > With -N, GNU diff does not give an ENOENT
> >> > > % echo foo > bar
> >> > % diff bar nofile.txt
> >> > diff: nofile.txt no such file or directory
> >> > % diff -N bar nofile.txt
> >> > 1d0
> >> > < foo
> >> > > Do we want BSD diff do the same, i.e. match the -N functionality of GNU
> >> > diff?
> >> > Yes we do,
> > Why? If someone wants a GNU diff. Can't they simply install it? If
> > FreeBSD diff is to become like GNU diff, what's the point of having
> > a FreeBSD version.
> > Apologies in advance if I'm missing anything here.
> >
>
> Because When I switched from GNU diff to BSD diff recently, the intent
> was to be mostly compatible with GNU diff (the one we had for very long,
> not necessary the very latest version if it) it has been requested by
> many users to avoid breakage in most script and usage of diff people
> were having for a long time.
>
> while what has been committed is not 100% compatible it is very close,
> and there is a file that documents what is missing from this
> implementation.
>
> Now back to the -N the behaviour Fehmi is proposing to fix is a bug in
> what I did implement the intent as always been to get the behaviour he
> describes not the one we currently have.
>
> Side note: the motivation for switching from GNU diff to BSD diff in
> base is the same as for the rest of the removal of the GNU components in
> base: we cannot get any update because newer version are in GPLv3).
Thank you very much for taking the time to reply. That all makes perfect sense.
Apologies for my ignorance, and thanks again.
--Chris
>
> Best regards,
> Bapt
More information about the freebsd-hackers
mailing list