Date: Thu, 28 May 2020 20:17:40 +1200 From: Fehmi Noyan ISI <fnoyanisi@yahoo.com> To: "bsd-lists@bsdforge.com" <bsd-lists@BSDforge.com> Cc: Baptiste Daroussin <bapt@FreeBSD.org>, Yuri Pankov <ypankov@fastmail.com>, freebsd-hackers@freebsd.org Subject: Re: diff(1) -N behaviour - Bug 233402 Message-ID: <F7FD49A1-F5C4-4957-AAAB-48C9C0EF345D@yahoo.com> In-Reply-To: <3df104a8139d5252b3426ae1600bfc86@udns.ultimatedns.net> References: <3df104a8139d5252b3426ae1600bfc86@udns.ultimatedns.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 28/05/2020, at 6:26 PM, Chris <bsd-lists@BSDforge.com> wrote: >=20 > On Wed, 27 May 2020 11:06:52 +0200 Baptiste Daroussin bapt@FreeBSD.org = said >=20 >> 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@fastmail.com> wrote: >> > > > > Fehmi Noyan ISI via freebsd-hackers wrote: >> > >>> On 23/05/2020, at 11:21 PM, Yuri Pankov <ypankov@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=E2=80=99s 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" = =3D=3D "empty=E2=80=9D? >> > >> Maybe it=E2=80=99s my interpretation, but if you do not supply = the second >> > argument to diff(1), it complains >> > >> $ echo =E2=80=9Ctest=E2=80=9D > 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 =E2=80=9Ctest=E2=80=9D > 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=E2=80=A6 >> > 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. >=20 > Thanks. >=20 > --Chris >> if you do provide a patch I would be more than happy to review >> and >> apply it. >> Best regards, >> Bapt >=20 >=20 Maybe I should have said =E2=80=9Cfrom functionality=E2=80=9D wise. We = are not changing the behaviour of diff(1) for the sake of being like = GNU diff. diff(1) has an -N flag and it is not short of any capabilities in that = regard. However, there are minor differences in some edge cases, which, = IMO, GNU diff behaves slightly looser than diff(1).=20 Hence the question was asked in this mailing list; we are not missing = anything but do we want to have that extra functionality in diff(1)?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F7FD49A1-F5C4-4957-AAAB-48C9C0EF345D>