Re: Compiling ncurses-6.1 on OpenBSD
On Mon, Jul 22, 2019 at 10:21:28AM +0900, Robert Smith wrote:
> Dear Thomas, here is my build script for 5.9, when I change the source file
> to 6.1 all it does it duplicate this 5.6 file to a 6.1 file, and I have to
> manually add any tweaks if necessary.
>
> root@h1up:/usr/src/build_system_v2/build_scripts# cat ncurses-5.9_ug
> echo Compiling and Installing ncurses-5.9
I revisited this, and can see half of the problem, which offers a different
workaround. Comparing the specs files for the compiler in 6.2 and 6.5,
I see that someone added a fallback for -L/usr/lib, apparently to compensate
for some other change.
I'm looking at this file:
/usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1/specs
which has a line with this information:
%{!static:--eh-frame-hdr} %{!shared:%{!nostdlib:%{!r*:%{!e*:-e
__start%{shared:-shared} %{R*}%{static:-Bstatic}
%{!static:-Bdynamic}%{rdynamic:-export-dynamic}%{assert*}
%{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}%{!nostdlib:-L/usr/lib}
That
%{!nostdlib:-L/usr/lib}
is the added text. Using ktrace, I could see that the arguments passed
to collect2 (part of the compiler) put a "-L/usr/lib" before any of the
command-line arguments:
[0] = "/usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1/collect2"
[1] = "--eh-frame-hdr"
[2] = "-e"
[3] = "__start"
[4] = "-Bdynamic"
[5] = "-dynamic-linker"
[6] = "/usr/libexec/ld.so"
[7] = "-L/usr/lib"
[8] = "-o"
[9] = "clear"
[10] = "/usr/lib/crt0.o"
[11] = "/usr/lib/crtbegin.o"
[12] = "-L../lib"
[13] = "-L/usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1"
[14] = "../obj_s/clear.o"
[15] = "../obj_s/clear_cmd.o"
[16] = "../obj_s/tty_settings.o"
[17] = "-lncurses"
[18] = "-lgcc"
[19] = "-lc"
[20] = "-lgcc"
[21] = "/usr/lib/crtend.o"
So the loader gets libncurses.so immediately without bothering to pay
any attention to its parameters.
Just reverting that change doesn't work (won't link), so I can see it's
just half the story. But it's enough to see that it probably wasn't
intended behavior.
You might want to open a bug report with the OpenBSD developers here:
http://www.openbsd.org/report.html
(cc'ing them, anyway).
According to
https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
you could make a custom "specs" file with a -L../lib before the -L/usr/lib,
using the "-specs=" flag and pass that in your $CFLAGS
(In a quick check, that works for me).
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: xterm killed with pledge dns violation
On Wed, Jan 08, 2020 at 12:24:56PM +0100, Benjamin Baier wrote: > On Wed, 8 Jan 2020 04:31:42 -0500 > Thomas Dickey wrote: > > > On Wed, Jan 08, 2020 at 09:01:32AM +0100, Benjamin Baier wrote: > > ... > > > > Thomas Dickey wrote: > > ... > > > > > Reading the source, it seems that the client is asking for the target > > > > > with this information, that libXmu is "merely" capable of honoring it > > > > > for some time. Take a look at > > > > > > > > > > https://gitlab.freedesktop.org/xorg/lib/libxmu/blob/master/src/CvtStdSel.c > > > > > > > > > > (very likely, disabling the XA_HOSTNAME (and XA_IP_ADDRESS) chunks > > > > > in that file wouldn't hurt xterm, though claws-mail might be annoyed). > > ... > > > I masked this bug with a patch to claws-mail. > > > https://marc.info/?l=openbsd-ports=157843792723639=2 > > > But who knows which other applications trigger this as well? Can't test > > > all > > > of them. So I don't consider this fixed. > > > > I did point to the appropriate place to make a change. > > Perhaps someone will read my response today. > I did read and investigate, just not that knowledgeable about xterm and X11. > The offending code in LibXmu is in a #if defined(TCPCONN) block. > What's the downside of compiling this with undefined TCPCONN? > What features are we losing? The feature's ~30 years old, so intent is hard to get, but looking down to line 309 (XA_TARGETS) that's one of several properties that someone (probably) thought would be useful for identifying the origin of a selection. Perhaps they had some authentication scheme in mind. You'd lose that -- but ordinary selections would work. Some application _may_ ask for XA_TARGETS and blindly fetch all of the properties, or it _may_ ask specifically for XA_IP_ADDRESS. I thought the former was more likely, and hinted (for OpenBSD's purposes) that limiting both to the local system would be what's needed. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Compiling ncurses-6.1 on OpenBSD
On Thu, Dec 26, 2019 at 01:13:11PM +, Stuart Henderson wrote: > On 2019/12/25 16:23, Thomas Dickey wrote: > > Since my message to bugs@openbsd.org was ignored, > > I'll have to assume that they're not interested in discussing it, > > and will keep in mind to document it as a pitfall in upcoming releases. > > The toolchain isn't my area, but I suspect there's little enthusiasm > for fixing a gcc-related problem especially one reported on amd64 - it's > pretty much only still built there so that developers have an easy way > to run it if they need to fix things in the base OS on the non-clang > platforms which many developers don't have direct access to. > > If the problem remains with /usr/bin/cc (which is clang on > amd64/i386/arm/aarch64/mips64) then it would be useful to include the > full steps to repeat the problem - the script is mentioned but not > included in the bugs@openbsd.org mail. I took a quick look at the clang (cc) build, but don't see that problem. I haven't investigated the i386 configuration for a while - probably should... > > > > > I revisited this, and can see half of the problem, which offers a > > > > > different > > > > > workaround. Comparing the specs files for the compiler in 6.2 and > > > > > 6.5, > > > > > I see that someone added a fallback for -L/usr/lib, apparently to > > > > > compensate > > > > > for some other change. > > The commit log was "Pass -L/usr/lib to the linker in preparation for > switching to lld, which does not have a default search path." > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Compiling ncurses-6.1 on OpenBSD
On Wed, Aug 14, 2019 at 04:10:17PM -0400, Thomas Dickey wrote:
> On Wed, Aug 14, 2019 at 12:22:44PM -0500, Robert Smith wrote:
> > Thank you for the hard work on this Thomas. Have we heard anything back
> > from
> > OpenBSD team on this?
>
> nothing. My cc' on the weekend was returned, and I attempted to subscribe
> using the link which the majordomo gave without success.
>
> But visiting
>
> https://lists.openbsd.org/cgi-bin/mj_wwwusr?user===lists-long-full=bugs
>
> and subscribing there got it to accept it. (today). Then I bounced my
> mail at the mailing list, to see if that would work, but went to find
> an archive - found here
>
> http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-bugs-f183916.html
>
> ...which appears to have my earlier attempt actually succeeded.
>
> (I didn't use sendbug, because my mail routing is a little complicated,
> and I only keep it working on the Debian machines).
>
> > I see progress made on several different parts, but I'm not of any wholistic
> > solution to get this to link correctly.
> >
> > I'm going to give the spec file a shot.
>
> I think that if you added that to the $CFLAGS, it would work (sort of ugly,
> but a workaround)
I noticed that there's an OpenBSD 6.6 from October.
However, this linker defect exists in that version as well.
Since my message to bugs@openbsd.org was ignored,
I'll have to assume that they're not interested in discussing it,
and will keep in mind to document it as a pitfall in upcoming releases.
> > -Robert
> >
> >
> > > On Aug 10, 2019, at 5:19 PM, Thomas Dickey wrote:
> > >
> > > On Mon, Jul 22, 2019 at 10:21:28AM +0900, Robert Smith wrote:
> > >> Dear Thomas, here is my build script for 5.9, when I change the source
> > >> file to 6.1 all it does it duplicate this 5.6 file to a 6.1 file, and I
> > >> have to manually add any tweaks if necessary.
> > >>
> > >> root@h1up:/usr/src/build_system_v2/build_scripts# cat ncurses-5.9_ug
> > >> echo Compiling and Installing ncurses-5.9
> > >
> > > I revisited this, and can see half of the problem, which offers a
> > > different
> > > workaround. Comparing the specs files for the compiler in 6.2 and 6.5,
> > > I see that someone added a fallback for -L/usr/lib, apparently to
> > > compensate
> > > for some other change.
> > >
> > > I'm looking at this file:
> > > /usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1/specs
> > >
> > > which has a line with this information:
> > > %{!static:--eh-frame-hdr} %{!shared:%{!nostdlib:%{!r*:%{!e*:-e
> > > __start%{shared:-shared} %{R*}%{static:-Bstatic}
> > > %{!static:-Bdynamic}%{rdynamic:-export-dynamic}%{assert*}
> > > %{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}
> > > %{!nostdlib:-L/usr/lib}
> > >
> > > That
> > > %{!nostdlib:-L/usr/lib}
> > >
> > > is the added text. Using ktrace, I could see that the arguments passed
> > > to collect2 (part of the compiler) put a "-L/usr/lib" before any of the
> > > command-line arguments:
> > >
> > > [0] = "/usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1/collect2"
> > > [1] = "--eh-frame-hdr"
> > > [2] = "-e"
> > > [3] = "__start"
> > > [4] = "-Bdynamic"
> > > [5] = "-dynamic-linker"
> > > [6] = "/usr/libexec/ld.so"
> > > [7] = "-L/usr/lib"
> > > [8] = "-o"
> > > [9] = "clear"
> > > [10] = "/usr/lib/crt0.o"
> > > [11] = "/usr/lib/crtbegin.o"
> > > [12] = "-L../lib"
> > > [13] = "-L/usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1"
> > > [14] = "../obj_s/clear.o"
> > > [15] = "../obj_s/clear_cmd.o"
> > > [16] = "../obj_s/tty_settings.o"
> > > [17] = "-lncurses"
> > > [18] = "-lgcc"
> > > [19] = "-lc"
> > > [20] = "-lgcc"
> > > [21] = "/usr/lib/crtend.o"
> > >
> > > So the loader gets libncurses.so immediately without bothering to pay
> > > any attention to its parameters.
> > >
> > > Just reverting that change doesn't work (won't link), so I can see it's
> > > just half the story. But it's enough to see that it probably wasn't
> > > intended behavior.
> > >
> > > You might want to open a bug report with the OpenBSD developers here:
> > >
> > > http://www.openbsd.org/report.html
> > >
> > > (cc'ing them, anyway).
> > >
> > > According to
> > >
> > > https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
> > >
> > > you could make a custom "specs" file with a -L../lib before the
> > > -L/usr/lib,
> > > using the "-specs=" flag and pass that in your $CFLAGS
> > >
> > > (In a quick check, that works for me).
> > >
> > > --
> > > Thomas E. Dickey
> > > https://invisible-island.net
> > > ftp://ftp.invisible-island.net
> >
>
> --
> Thomas E. Dickey
> https://invisible-island.net
> ftp://ftp.invisible-island.net
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: Compiling ncurses-6.1 on OpenBSD
On Sun, Dec 29, 2019 at 11:41:29PM +0100, Robert Smith wrote:
> Dear Thomas,
>
> It's interesting to see some new discussion around this whereas I am
> attempting to build it again.
>
> I was just reviewing some of the correspondence from earlier in the year to
> see if there was anything I could do to get some kind of build working. Even
> ugly.
>
> Is there a work around available that I can test?
The workaround is to use clang, with the _XOPEN_SOURCE symbol predefined.
I just did a build, modifying my routine build from
build-my-ncurses
to
CPPFLAGS='-D_XOPEN_SOURCE=800' with-clang build-my-ncurses
"with-clang" is a local script:
#!/bin/sh
# $Id: with-clang,v 1.3 2011/05/21 17:05:49 tom Exp $
# use clang for compiler and lint
# xen-fedora12
export CC=clang
export CXX=clang++
export LINT=clang-lint
exec "$@"
and "build-my-ncurses" is a script that I use to build/install several
configurations.
The configure script checks if _XOPEN_SOURCE is already defined,
and skips adding what's requested if overridden.
>
> -Robert
>
>
> > On Dec 28, 2019, at 11:08 PM, Thomas Dickey wrote:
> >
> > On Thu, Dec 26, 2019 at 05:12:56PM -0500, Thomas Dickey wrote:
> >> On Thu, Dec 26, 2019 at 01:13:11PM +, Stuart Henderson wrote:
> >>> On 2019/12/25 16:23, Thomas Dickey wrote:
> >>>> Since my message to bugs@openbsd.org was ignored,
> >>>> I'll have to assume that they're not interested in discussing it,
> >>>> and will keep in mind to document it as a pitfall in upcoming releases.
> >>>
> >>> The toolchain isn't my area, but I suspect there's little enthusiasm
> >>> for fixing a gcc-related problem especially one reported on amd64 - it's
> >>> pretty much only still built there so that developers have an easy way
> >>> to run it if they need to fix things in the base OS on the non-clang
> >>> platforms which many developers don't have direct access to.
> >>>
> >>> If the problem remains with /usr/bin/cc (which is clang on
> >>> amd64/i386/arm/aarch64/mips64) then it would be useful to include the
> >>> full steps to repeat the problem - the script is mentioned but not
> >>> included in the bugs@openbsd.org mail.
> >>
> >> I took a quick look at the clang (cc) build, but don't see that problem.
> >> I haven't investigated the i386 configuration for a while - probably
> >> should...
> >>
> >>>>>>> I revisited this, and can see half of the problem, which offers a
> >>>>>>> different
> >>>>>>> workaround. Comparing the specs files for the compiler in 6.2 and
> >>>>>>> 6.5,
> >>>>>>> I see that someone added a fallback for -L/usr/lib, apparently to
> >>>>>>> compensate
> >>>>>>> for some other change.
> >>>
> >>> The commit log was "Pass -L/usr/lib to the linker in preparation for
> >>> switching to lld, which does not have a default search path."
> >>>
> >
> > Taking a look at the i386, I see that as you hinted cc==clang.
> >
> > That's okay. But there's an error in OpenBSD's header files which
> > I'll have to work around for the time being. It would be nice
> > if someone fixed it:
> >
> > /usr/include/ctype.h has
> >
> > #if __POSIX_VISIBLE >= 200809
> > #ifndef _LOCALE_T_DEFINED_
> > #define _LOCALE_T_DEFINED_
> > typedef void*locale_t;
> > #endif
> > #endif
> >
> > and (since ncurses uses no feature newer than this) my default build
> > does this:
> >
> > -D_BSD_SOURCE -D_XOPEN_SOURCE=600
> >
> > which produces this error:
> >
> > compiling cursesmain (obj_s)
> > In file included from ../c++/cursesmain.cc:39:
> > In file included from /usr/include/c++/v1/iostream:38:
> > In file included from /usr/include/c++/v1/ios:216:
> > In file included from /usr/include/c++/v1/__locale:32:
> > In file included from /usr/include/c++/v1/support/newlib/xlocale.h:26:
> > /usr/include/c++/v1/support/xlocale/__strtonum_fallback.h:24:64: error:
> > unknown type name 'locale_t'
> >char **endptr, locale_t) {
> > ^
> > because the locale_t use from iostream is improperly ifdef'd.
> >
> > --
> > Thomas E. Dickey
> > https://invisible-island.net
> > ftp://ftp.invisible-island.net
>
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: xterm killed with pledge dns violation
On Tue, Jan 07, 2020 at 09:00:04PM +0100, Benjamin Baier wrote: > >Synopsis:xterm pledge dns violation > >Category:X11 / libc? / ports? > >Environment: > System : OpenBSD 6.6 > Details : OpenBSD 6.6-current (GENERIC.MP) #0: Mon Jan 6 20:17:42 > CET 2020 > > b...@x220.home.netzbasis.de:/home/cvsgit/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > > >Description: > While copy paste with middle mousebutton from xterm to claws-mail (into > new email window) Reading the source, it seems that the client is asking for the target with this information, that libXmu is "merely" capable of honoring it for some time. Take a look at https://gitlab.freedesktop.org/xorg/lib/libxmu/blob/master/src/CvtStdSel.c (very likely, disabling the XA_HOSTNAME (and XA_IP_ADDRESS) chunks in that file wouldn't hurt xterm, though claws-mail might be annoyed). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Compiling ncurses-6.1 on OpenBSD
On Thu, Dec 26, 2019 at 05:12:56PM -0500, Thomas Dickey wrote:
> On Thu, Dec 26, 2019 at 01:13:11PM +, Stuart Henderson wrote:
> > On 2019/12/25 16:23, Thomas Dickey wrote:
> > > Since my message to bugs@openbsd.org was ignored,
> > > I'll have to assume that they're not interested in discussing it,
> > > and will keep in mind to document it as a pitfall in upcoming releases.
> >
> > The toolchain isn't my area, but I suspect there's little enthusiasm
> > for fixing a gcc-related problem especially one reported on amd64 - it's
> > pretty much only still built there so that developers have an easy way
> > to run it if they need to fix things in the base OS on the non-clang
> > platforms which many developers don't have direct access to.
> >
> > If the problem remains with /usr/bin/cc (which is clang on
> > amd64/i386/arm/aarch64/mips64) then it would be useful to include the
> > full steps to repeat the problem - the script is mentioned but not
> > included in the bugs@openbsd.org mail.
>
> I took a quick look at the clang (cc) build, but don't see that problem.
> I haven't investigated the i386 configuration for a while - probably should...
>
> > > > > > I revisited this, and can see half of the problem, which offers a
> > > > > > different
> > > > > > workaround. Comparing the specs files for the compiler in 6.2 and
> > > > > > 6.5,
> > > > > > I see that someone added a fallback for -L/usr/lib, apparently to
> > > > > > compensate
> > > > > > for some other change.
> >
> > The commit log was "Pass -L/usr/lib to the linker in preparation for
> > switching to lld, which does not have a default search path."
> >
Taking a look at the i386, I see that as you hinted cc==clang.
That's okay. But there's an error in OpenBSD's header files which
I'll have to work around for the time being. It would be nice
if someone fixed it:
/usr/include/ctype.h has
#if __POSIX_VISIBLE >= 200809
#ifndef _LOCALE_T_DEFINED_
#define _LOCALE_T_DEFINED_
typedef void*locale_t;
#endif
#endif
and (since ncurses uses no feature newer than this) my default build
does this:
-D_BSD_SOURCE -D_XOPEN_SOURCE=600
which produces this error:
compiling cursesmain (obj_s)
In file included from ../c++/cursesmain.cc:39:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:32:
In file included from /usr/include/c++/v1/support/newlib/xlocale.h:26:
/usr/include/c++/v1/support/xlocale/__strtonum_fallback.h:24:64: error: unknown
type name 'locale_t'
char **endptr, locale_t) {
^
because the locale_t use from iostream is improperly ifdef'd.
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: xterm killed with pledge dns violation
On Wed, Jan 08, 2020 at 09:01:32AM +0100, Benjamin Baier wrote: ... > > Thomas Dickey wrote: ... > > > Reading the source, it seems that the client is asking for the target > > > with this information, that libXmu is "merely" capable of honoring it > > > for some time. Take a look at > > > > > > https://gitlab.freedesktop.org/xorg/lib/libxmu/blob/master/src/CvtStdSel.c > > > > > > (very likely, disabling the XA_HOSTNAME (and XA_IP_ADDRESS) chunks > > > in that file wouldn't hurt xterm, though claws-mail might be annoyed). ... > I masked this bug with a patch to claws-mail. > https://marc.info/?l=openbsd-ports=157843792723639=2 > But who knows which other applications trigger this as well? Can't test all > of them. So I don't consider this fixed. I did point to the appropriate place to make a change. Perhaps someone will read my response today. bye. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Locale not supported by C library.
On Fri, May 01, 2020 at 07:13:02PM +0200, Daniele Bonini wrote: > Hello, > > I need to work on unicode characters, expecially Chinese characters. > > So I set this in my .profile: > >export LC_CTYPE=zh_CN.GB18030 > > But launching Terminal in Xfce4 I get: well... in principle, you could use luit (even in xfce4-terminal, though it would be clumsy to start up). OpenBSD has the (abandoned) xorg fork of luit, which does list GB18030 for encoding, as you can see using luit -list But to make it work, you'd have to have a workable LC_CTYPE locale. Since it's not a prepackaged locale, you'd have to find some more extensive documentation for mklocale. This looks like a place to start: http://openbsd-archive.7691.n7.nabble.com/Remove-build-machinery-for-non-UTF-8-charsets-td291943.html -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: TPUT expects an incorrect number of arguments
On Wed, Jun 15, 2022 at 06:30:27PM +, 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 > dera...@amd64.openbsd.org:/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 ). 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 https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: TPUT expects an incorrect number of arguments
On Wed, Jun 15, 2022 at 09:31:44PM +, 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=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 +, 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 > >> dera...@amd64.openbsd.org:/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 b
Re: xterm segfaults when selecting missing font
- Original Message - | From: "Ryan Kavanagh" | To: "bugs" | Sent: Thursday, January 26, 2023 6:58:00 PM | Subject: xterm segfaults when selecting missing font |>Synopsis: xterm segfaults when selecting missing font |>Category: system |>Environment: I don't see the version of xterm, but supposing it is this: https://github.com/openbsd/xenocara/blob/master/app/xterm/version.h that's #375. Current version is 378 https://invisible-island.net/xterm/xterm.log.html For instance, 376 has add null-pointer checks in x_strcasecmp and x_strncasecmp, to help with error-recovery for a missing font (Debian #1022942). and 377 has change default for xftTrackMemUsage to false, because libXft does not handle certain fonts. -- Thomas E. Dickey https://invisible-island.net
Re: xterm bug
On Tue, Dec 19, 2023 at 05:46:49AM +, cml55uk wrote:
> Hi dickey,
>
> A bug in the OpenBSD sense of a man text error
>
> man xterm and under the -ti switch section it examples "vtvt100" instead of
> just "vt100"
The manpage has several places which are adjusted during the build.
The original on this chunk hasn't changed for a while:
1.466(tom 16-Jul-10): .BI \-ti " term_id"
1.545(tom 08-Oct-12): Specify the name used by \fI\*n\fP to select
the
1.58 (tom 21-Jan-99): correct response to terminal ID queries.
1.58 (tom 21-Jan-99): It also specifies the emulation level,
1.58 (tom 21-Jan-99): used to determine the type of response to a
DA control sequence.
1.565(Ross.Com 28-May-13): Valid values include vt52, vt100, vt101,
vt102, vt220, and vt240
1.492(tom 04-Jul-11): (the \*(``vt\*('' is optional).
1.502(tom 16-Aug-11): The default is
\*(``vt__default_termid__\*(''.
1.687(tom 24-Sep-16): The \fIterm_id\fP argument specifies the
terminal ID to use.
1.272(tom 06-Jul-04): (This is the same as the \fBdecTerminalID\fP
resource).
and minstall.in (my script) hasn't changed that recently:
1.18 (tom 01-Jan-13): -e 's%^'"$APP_name"' \\- %'"$USE_name"'
\- %' \
1.26 (tom 27-Jan-21): -e
"s%__default_termname__%@default_TERM@%" \
1.26 (tom 27-Jan-21): -e
"s%__default_termid__%@default_termid@%" \
1.26 (tom 27-Jan-21): -e
"s%__alt_sends_esc__%@alt_sends_esc@%" \
OpenBSD doesn't actually use any of the configure/install scripts,
replacing those by patches. The configure script does this:
AC_MSG_CHECKING(for default terminal-id)
AC_ARG_WITH(terminal-id,
[ --with-terminal-id=Vset default decTerminalID (default: vt420)],
[default_termid=$withval],
[default_termid=vt420])
AC_MSG_RESULT($default_termid)
case $default_termid in
(vt*) default_termid=`echo $default_termid | sed -e 's/^..//'`
producing this chunk for the sed script:
s,@default_termid@,420,;t t
However, OpenBSD's makefile
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/app/xterm/Makefile?rev=1.37=text/plain
does this:
-e s%__default_termid__%vt100% \
> Well at least it does in my OpenBSD 7.4 install
that's a bug in OpenBSD's patches.
--
Thomas E. Dickey
https://invisible-island.net
Re: xterm bug
- Original Message - | From: "Bryan Steele" | To: "bugs" | Cc: "Thomas Dickey" , "cml55uk" | Sent: Tuesday, December 19, 2023 11:09:00 AM | Subject: Re: xterm bug | On Tue, Dec 19, 2023 at 08:58:09AM -0700, Todd C. Miller wrote: |> On Tue, 19 Dec 2023 10:56:42 -0500, Bryan Steele wrote: |> |> > There's two instances of __default_termid__ in xterm.man, I think this |> > will chang the second one to "100", is that correct? |> |> Yes, the "vt" prefix is optional. |> |> - todd see https://invisible-island.net/xterm/manpage/xterm.html#OPTIONS:-ti -ti term_id Specify the name used by xterm to select the correct response to terminal ID queries. It also specifies the emulation level, used to determine the type of response to a DA control sequence. Valid values include vt52, vt100, vt101, vt102, vt220, and vt240 (the "vt" is optional). The default is "vt420". The term_id argument specifies the terminal ID to use. (This is the same as the decTerminalID resource). Perhaps I should have said "include, but are not limited to:" There's a few checks for specific values, e.g., in https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:decGraphicsID but vt420 has been the default since https://invisible-island.net/xterm/xterm.log.html#xterm_280 Patch #280 - 2012/06/24 -- Thomas E. Dickey https://invisible-island.net
Re: xterm bug
- Original Message - | From: "Thomas Dickey" | To: "Bryan Steele" | Cc: "bugs" , "cml55uk" | Sent: Tuesday, December 19, 2023 2:58:03 PM | Subject: Re: xterm bug ... | | but vt420 has been the default since | | https://invisible-island.net/xterm/xterm.log.html#xterm_280 | | Patch #280 - 2012/06/24 The reason for a given terminal id is that some features (such as the left/right margins used by tmux) are not available by default -- https://invisible-island.net/xterm/xterm.faq.html#why_vt420 -- Thomas E. Dickey https://invisible-island.net
