Date: Wed, 8 Feb 2017 01:56:04 -0800 From: "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com> To: Sergey Kandaurov <pluknet@gmail.com> Cc: Ngie Cooper <ngie@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r313437 - head/lib/libutil Message-ID: <AC475F75-2468-4357-ACB0-4166EB14E95A@gmail.com> In-Reply-To: <779F34BC-816D-48E4-90B6-8DD3FCE401A4@gmail.com> References: <201702080922.v189MaUf075951@repo.freebsd.org> <CAE-mSO%2BmmQKQscFXHG2cBFz2Xgf8brt3csiczLyhXWh8Oi3uUQ@mail.gmail.com> <779F34BC-816D-48E4-90B6-8DD3FCE401A4@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > On Feb 8, 2017, at 01:52, Ngie Cooper (yaneurabeya) <yaneurabeya@gmail.com> wrote: > >> >> On Feb 8, 2017, at 01:38, Sergey Kandaurov <pluknet@gmail.com> wrote: >> >> On 8 February 2017 at 12:22, Ngie Cooper <ngie@freebsd.org> wrote: >> Author: ngie >> Date: Wed Feb 8 09:22:35 2017 >> New Revision: 313437 >> URL: https://svnweb.freebsd.org/changeset/base/313437 >> >> Log: >> Create link from hexdump(3) to sbuf_hexdump(9) as the manpage describes >> sbuf_hexdump(9)'s behavior >> >> MFC after: 3 weeks >> Sponsored by: Dell EMC Isilon >> >> Modified: >> head/lib/libutil/Makefile >> >> Modified: head/lib/libutil/Makefile >> ============================================================================== >> --- head/lib/libutil/Makefile Wed Feb 8 09:19:49 2017 (r313436) >> +++ head/lib/libutil/Makefile Wed Feb 8 09:22:35 2017 (r313437) >> @@ -35,6 +35,7 @@ MAN+= expand_number.3 flopen.3 fparseln. >> property.3 pty.3 quotafile.3 realhostname.3 realhostname_sa.3 \ >> _secure_path.3 trimdomain.3 uucplock.3 pw_util.3 >> MAN+= login.conf.5 >> +MLINKS+=hexdump.3 sbuf_hexdump.9 >> >> This looks odd imho also that sbuf_hexdump(3) is part of libsbuf. >> Note also hexdump(3) taht's essential copy of hexdump(9). >> If go this duplicating route why not copy sbuf_hexdump description as well. >> >> I like more how that's done with sbuf(9) that's the only man page, ymmv. > > Ack. The implementation is spread between iexdump(3) and sbuf(9), but probably should just be in sbuf(9). … for sbuf_hexdump(9). The point behind sbuf(3) and the separation in documentation with the kernel and user interface is a bit curious. > I’ll look at cleaning this up further after I talk with scottl@ a bit more. Thanks! -Ngie [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYmus0AAoJEPWDqSZpMIYVDRMQALUY3tnDel1QXeP6iT/Fjkc+ I0yhBBaRqI6RL3IuK3VczyilfswoqBj/h4kIFnCyySE0RxCKBoXAmDrvFL8gcEaT BY1awO1XpMhwwsksyxuhbWUueh2YL6i7sbgCRbClBzm4im71tEQfl+n3HwNI7U8a JGPdXIU2OlB3xSHMIx5DhWWdUuAsRnnEg6c7gR5GsSSPvoE5szap2z69BQF6xNyN Vrh69COpn3aBWJN1xh9LYwmI0b0tW4kwm8U0iOyPB/p1/Phwo8rspQBhXHsv23gu tHoKCsiicGmYFXstYYqYiTLHb/4UWuM3TVoMSUGwD2DLya3Xln/6fEB98CnqUXWq oWMPLmkxHcU6yi/clYpvbdsVHyR8q4vKeJmfZDEbklrYWA2dgYjsCXzv+33TnwFe x0QcVUEoui6XO0R/5jI/QnwBEPr7VSYMT1H7VFVC0sjiuhJtTX+0RD2VkMEV5lRZ /WHnyWd+EXe+Sq5u70TqMDx0WFRE4MP37cFdgmvLWRizWIzsXl1ujPKujSMOS0U7 sCWzliM44PW8QtYptMWccvLoecVZq0Zc9KTSvqO598mRtBv5CG4z7RfQ/vH+6V/n Q0r6+1/+ydjG3wI9zb3P7xqmB3XEBBG/I5ZTYX3nJso0uGmaG+ljQ60e/4MXpxUh 2xlrvtDPTy0hGlJreB6y =IgYX -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC475F75-2468-4357-ACB0-4166EB14E95A>