On Wed, Jun 15, 2022 at 09:31:44PM +0000, Michael Hambly wrote: > 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.
Well, as I pointed out in the rather lengthy discussion of ncurses in OpenBSD, the basic problem with OpenBSD's tput is that it uses a bit of code adapted from the ncurses library long ago -- while the implementation in the library has been improved far beyond that (and is used for more than just tput). > 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 actually I was able to upgrade OpenBSD, replacing ncurses (and utilities) without breakage. https://invisible-island.net/ncurses/ncurses-openbsd.html#fixing_issues (I tested with 6.8, 6.9 and 7.0, which came out while I was working on that) Owing to the time involved, there are probably a few nonportable scripts which happen to work with OpenBSD's tput (and nowhere else). Those should be fixed. > 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 In ncurses 6.3, https://invisible-island.net/ncurses/NEWS.html#t20210925 that's done by splitting it up to be like tput cl tput cm 5 10 (after all, there are 2 calls to tigetstr). See https://github.com/ThomasDickey/ncurses-snapshots/blob/3f2a6304d4066d0b256b0b8b8109d1f437973cbc/progs/tput.c#L442 argnum -= used; argnow += used; In OpenBSD... https://cvsweb.openbsd.org/src/usr.bin/tput/tput.c?rev=1.24&content-type=text/x-cvsweb-markup that's done by manipulating the return value of process(). return (argv + arg_need); > 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. yes - in either case, to be able to handle multiple capabilities on a single line, tput has to be able to calculate the number of parameters. > 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. :-) > 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 > > > -- Thomas E. Dickey <[email protected]> https://invisible-island.net ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
