Re: [nmh-workers] Handling empty components

[Bob Carragher]

Sorry to take so long to do this!

I'm actually having trouble building the sources on Ubuntu 18.04
(Bionic Beaver).  This is clearly not impossible, since 1.7.1 is
the version of the NMH package built for 18.04, but there are
some odd hangups.

For example, build_nmh is failing during the "configuring" step
because one of the checks, which builds a small program that
includes "gdbm-ndbm.h", fails because that include file is no
longer provided with the libgdbm-dev package (only "gdbm.h" is).
Thus, even the "configure" script under the 1.7.1-4 tree on
sources.debian.org would fail at this point (because it is
expecting "gdbm/ndbm.h").

     https://sources.debian.org/src/nmh/1.7.1-4/configure/

I was wondering if the person who builds the Ubuntu package can
point me to which patches -- and packages, as Ubuntu has reduced
what gets installed by default, like the curses package -_-## --
need to be applied to get it built?  (I can probably work this
out myself, but I don't want to make changes/assumptions that
might be wrong.  Also, I'm hoping I can be lazy.  B-)

Thanks!

                                Bob

On Sat, 23 Mar 2019 11:07:18 -0400 Ken Hornstein <address@hidden> sez:

> >... Though, if you would like me to test this (and see if I can
> >come up with format code that is not ridiculously complex/long)
> >to see if it solves my particular issue (which it seems like it
> >should), I'm happy to pull down and build from sources!
>
> If you want to build from HEAD, that's an option (we don't run
> that through testing like we do for a release, though).  But
> you could always pull down the sources from 1.7.1 and apply the
> patch; it really is one line (see below).  I think wrapping
> every component in a %(trimr) function would do it.
>
> --Ken
>
> commit 9530e8f7f96f79ebe9afaeeecf0f2a2b373bb429
> Author: Ken Hornstein <address@hidden>
> Date:   Fri Mar 22 11:59:04 2019 -0400
>
>     Add support for %(trimr) format function
>     
>     Add support for a %(trimr) format function, which behaves exactly
>     like %(trim) but also returns a string.  Turns out this is literally
>     a one-line change that does not require a new format instruction.
>
> diff --git a/man/mh-format.man b/man/mh-format.man
> index 104b8212..8b43eda6 100644
> --- a/man/mh-format.man
> +++ b/man/mh-format.man
> @@ -285,6 +285,7 @@ decode    expr    string  decode \fIstr\fR as RFC 2047 
> (MIME-encoded)
>                       component
>  unquote      expr    string  remove RFC 2822 quotes from \fIstr\fR
>  trim expr            trim trailing whitespace from \fIstr\fR
> +trimr        expr    string  Like %(trim), also returns string
>  kilo expr    string  express in SI units: 15.9K, 2.3M, etc.
>                       %(kilo) scales by factors of 1000,
>  kibi expr    string  express in IEC units: 15.5Ki, 2.2Mi.
> diff --git a/sbr/fmt_compile.c b/sbr/fmt_compile.c
> index e8a80279..3ada1d41 100644
> --- a/sbr/fmt_compile.c
> +++ b/sbr/fmt_compile.c
> @@ -160,6 +160,7 @@ static struct ftable functable[] = {
>       { "decodecomp", TF_COMP,        FT_LS_DECODECOMP, 0,            
> TFL_PUTS },
>       { "decode",     TF_EXPR,        FT_LS_DECODE,   0,              
> TFL_PUTS },
>       { "trim",       TF_EXPR,        FT_LS_TRIM,     0,              0 },
> +     { "trimr",      TF_EXPR,        FT_LS_TRIM,     0,              
> TFL_PUTS },
>       { "kilo",       TF_EXPR,        FT_LS_KILO,     0,              
> TFL_PUTS },
>       { "kibi",       TF_EXPR,        FT_LS_KIBI,     0,              
> TFL_PUTS },
>       { "compval",    TF_COMP,        FT_LV_COMP,     0,              
> TFL_PUTN },