Hi Thomas, Thanks for your fast response. To clarify, the only issue that I am reporting with tput is that it *fails* when the capability string returned by tigetstr() contains conditionals. The string returned by tigetstr() is fine, it is just that tput calculates the number of arguments expected wrongly. Hence when a user (or more likely an application script) calls tput with the correct number of parameters, the tput program will abort, abandoning the change and returning an error status.
The problem can be worked around by passing the tput command some dummy arguments to make up for the extra arguments that it thinks it is supposed to get. * Instead of [ tput setaf 3 ], you can use [ tput setaf 3 '' '' ] or [ tput setaf 3 0 0 ], etc. The correct invocation is "tput setaf 3". Passing it the dummy arguments will make the command work, but most 3rd party apps won't be aware that they need that tweak to make their app work for OpenBSD. Your notes on the ncurses library, how it works, and the various compatibility issues are extensive and informative. And obviously your recommendations for upgrading the suite, while not a simple task, is the appropriate one. Assumedly that should resolve the issue, since other platforms seem to not have that specific tput issue. One thing that your notes do not cover is how to correctly calculate the expected number of args. In https://invisible-island.net/ncurses/ncurses-openbsd.html#issue_tput, you make note that the argument expectation calculation is done to handle specific scenarios that could not be handled otherwise (e.g. the "tput cl cm 5 10" example). That implies that the calculation for the number of expected args is required, though from looking at tput.c I don't see how the tput code enables that. As far as I can see it is just a sensibility check. One that doesn't work for common cases such as setaf and setab. The notes I included in my bug report were not a fix, they were just a possibly flawed description of how to interpret conditionals within a capability string. I was thinking of writing a patch for the tput bug, and was hoping that somebody else might have further feedback. Obviously you have the situation well in hand, and I agree with your analysis; maintaining forward compatibility by upgrading the entire library suite is the more reasonable path. */Mi/*/chael Hambly/ Blackbird Software Design Ltd. * * On 2022-06-15 13:28, Thomas Dickey wrote: > On Wed, Jun 15, 2022 at 06:30:27PM +0000, Michael Hambly wrote: >>> Synopsis: /usr/bin/tput expects an incorrect number of arguments. >>> Category: system/user >>> Environment: >> System : OpenBSD 7.0 >> Details : OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021 >> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> >> Architecture: OpenBSD.amd64 >> Machine : amd64 >> >>> Description: >> The tput command can be used to query or set terminal behaviour, and is often >> used by application scripts for this purpose. The OpenBSD version of this > ... >> This problem has been noted before (search for tput on the sendbug mailing >> list), and there is a workaround. Unfortunately that workaround is unlikely >> to be implemented on 3rd party apps, and hence it limits some packages from >> attaining OpenBSD compatibility. > This report doesn't appear to clarify that workaround. > > (discarding OpenBSD's variant of tput would be an improvement all around). > >> In order for the process function to figure out how many arguments it should >> be passing to tparm for the target string capability, it tries to figure out >> how many arguments the capability string consumes and how many it spits out. >> In essence the code looks like it might work fine for simple cases, but it's >> kind of smelly. It doesn't process the code the same way that the terminfo >> library would and so it while it might work, its not a good implementation. >> Furthermore, as noted, it does fail for cases where the capability string >> includes conditionals. >> >> - Apple does it different, they use a lookup function though they note that >> their method is imperfect and has extensibility issues (see the tparm_type >> function in >> https://opensource.apple.com/source/ncurses/ncurses-7/ncurses/progs/tput.c.auto.html). > Apple is a distributor, not a developer. > So this does not describe "their method", > > The file you indicate was from ncurses 5.2 20010721 (an upstream development). > Apple's involvement with ncurses has been minor: > > 20011208 > + modify the build to name dynamic libraries according to the > convention used on OS X and Darwin. Rather than something like > libncurses.dylib.5.2, Darwin would name it libncurses. 5.dylib. > There are a few additional minor fixes, such as setting the library > version and compatibility version numbers (patch by Jason Evans > <[email protected]>). > > and the source shown is not what Apple uses on MacOS: > > $ usr/bin/tput -V > ncurses 5.7.20081102 > > fwiw - > > https://invisible-island.net/ncurses/ncurses.faq.html#platform-portable > >> Again, this is my first time looking into the details of the termcap/terminfo >> libraries, so I may have misinterpreted some of the details, but overall I >> think the essence of my analysis is correct. > (I don't agree). > > The situation with OpenBSD is described here: > > https://invisible-island.net/ncurses/ncurses-openbsd.html >
