A solution similar to neighboring code posted as part of https://github.com/networkupstools/nut/pull/3042 - thanks again for raising this point.
@Greg: can you please check that branch with pkgsrc et al? Jim On Sat, Aug 2, 2025, 21:15 Jim Klimov <[email protected]> wrote: > Thanks Greg, > > Regarding `\s` - good catch, as I read your post, I was sure it is used > all over the place... but in fact only in perl code (also Java/groovy in CI > libs), so not quite a GNU-only extension. Native Sun and BSD sed's were > okay with that too. Most shell code went with "[ ${TABCHAR}]" where > TABCHAR="`printf '\t'`" because indeed many sed's or especially grep's > treat direct `\t` as escaped character "t". Missed doing that here. Once! > And you got me on that! :D > > Truth be told, one script does mention `[[:blank:]]`. > > Regarding commentary on docs, fair enough about the configure.ac > script, but does at least `docs/configure.txt` explain it satisfactorily? > > Jim > > On Sat, Aug 2, 2025, 18:43 Greg Troxel via Nut-upsuser < > [email protected]> wrote: > >> Jim Klimov via Nut-upsdev <[email protected]> writes: >> >> > FWIW, I did merge the previously queued "small PRs", >> >> Great, thanks. >> >> > now probably gotta >> > figure out what Greg found with pkgsrc's `sed` (or await his PR with a >> fix >> > that would work everywhere - can't reproduce the problem so far), and >> > planned changes will be done. >> >> This is not about pkgsrc's sed; it's about the sed that is part of the >> NetBSD base system, which is believed to conform to POSIX. (When >> building under pkgsrc, the base sed is used even if gsed is installed, >> as part of repeatable build hygiene.) >> >> I am 99% sure that the problem is this, from doc/Makefile.am, building >> ChangeLog.adoc from ChangeLog: >> >> -e 's,^\(\s\s*\)\([0-9]\),\1{empty}\2,g' >> >> resulting in >> >> "s,^\(\s\s*\)\([0-9]\),\ ..." >> >> >> I think the problem is that \s is a GNU beyond-POSIX extension and the >> standards-compliant way to write this is >> >> -e 's,^\([:blank:][:blank:]*\)\([0-9]\),\1{empty}2\,g' \ >> >> instead. >> >> >> (In general, I find the sed magic surrounding docs builds too hard to >> understand, even for someone who has used sed, probably starting with >> Seventh Edition.) >> >> > On one hand, a build is expected to deliver man pages. Historically >> *roff >> > files were directly edited and served by projects; nowadays it is >> asciidoc >> > or similar, rendered into man pages as one of many output formats. Dist >> > tarballs include those page files so they can be installed even where >> > asciidoc renderer is not available. So some options manage this part. >> >> ok, but which options actually do what precisely? Does --without-doc >> say "don't build them" or "don't install them"? What happens if you >> give --without-doc, and you don't, or do, have them built? One could >> make an argument that "don't build them, and install what should have >> been built into distfile, erroring out if not there" is mild/acceptable, >> resulting in a correct package. And that "don't build and don't >> install" is, while useful to some, an instruction that results in a >> defective install. >> >> This is not understandable from reading configure.ac. >> >> > Another issue is the codes assigned to man page sections in different >> OSes >> > - this was previously bolted to what is seen in Linux and FreeBSD; now >> can >> > be amended for package builds (especially on other platforms), to avoid >> > clumsy distro-specific patch files or scripts in their recipes. >> >> sure, good to have --do-foo to accomodate. So far that's not my issue! >> >> _______________________________________________ >> Nut-upsuser mailing list >> [email protected] >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >> >
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
