On Tue, Mar 08, 2016 at 11:59:43PM +0100, Rüdiger Meier wrote:
> On Tuesday 08 March 2016 23:35:01 Sami Kerola wrote:
> > Does this happen with putp() only? The following should enable you to
> > test the fputs() output.
>
> It's only broken with putp, I tried it like this
It's BSD specific problem, putp (aka tputs) interprets the string.
That's fine as tputs is sensitive to sequences prefixed by $< and
everything else is printed to terminal.
BUT probably because BSD has origins in 70' LSD era there is a
special exception (ncurses sources tinfo/lib_tputs.c):
#if BSD_TPUTS
/*
* This ugly kluge deals with the fact that some ancient BSD
* programs (like nethack) actually do the likes of tputs("50") to
* get delays.
*/
if (isdigit(UChar(*string))) {
...
}
#endif
and the number is interpreted as argument for delay_output() and never
printed to the output.
It seems we're little bit fragile with putp() as it's primarily
designed for terminfo string variables than for a generic output.
Unfortunately mix tputs() and fputs() is also no perfect due to
buffering issues (commit 07ac4aa9d4f36a6618fd3ab1423bc33e3903ddbd).
The easy fix is to disable ncurses support for BSD (words like fuck
and suck are allowed in the commit message for this case:-).
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
