home.social

#termcap — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #termcap, aggregated by home.social.

fetched live
  1. @rl_dane

    It's not quite right, but you might like to experiment with instead of running that second reset running

    stty cbreak; tput ti; kill -WINCH 0

    These are just a bodge. The #urwid library and #sncli should be fixed.

    #ncurses #termcap

  2. @rl_dane

    It's not quite right, but you might like to experiment with instead of running that second reset running

    stty cbreak; tput ti; kill -WINCH 0

    These are just a bodge. The #urwid library and #sncli should be fixed.

    #ncurses #termcap

  3. @cks

    Let me guess: historical termcap. (-:

    Might be Joy+Horton #vi, but my first guess is #termcap.

    The way that termcap, and even terminfo, handle switchable stuff like this is truly terrible, because it simply does not fit their model. They're poor on input sequences anyway.

    #FreeBSD still uses termcap(5), pretty much the only operating system left that does, and its manual page discusses how one might want to be compatible with AT&T #Unix S5R2 in the future.

    man.freebsd.org/cgi/man.cgi?qu

  4. @cks

    Let me guess: historical termcap. (-:

    Might be Joy+Horton #vi, but my first guess is #termcap.

    The way that termcap, and even terminfo, handle switchable stuff like this is truly terrible, because it simply does not fit their model. They're poor on input sequences anyway.

    #FreeBSD still uses termcap(5), pretty much the only operating system left that does, and its manual page discusses how one might want to be compatible with AT&T #Unix S5R2 in the future.

    man.freebsd.org/cgi/man.cgi?qu

  5. A destructive back space, to go alongside a destructive forward space, is an exceedingly unusual but valid choice. There are terminals in the termcap database that did this.

    If you want actual madness, however, look to u-boot, where BS is non-destructive *unless* the user is using TrueType fonts, when this code kicks in.

    github.com/u-boot/u-boot/blob/

    Just say no to using the BS character for text effects effects in boot loaders, kids! (-:

    #uboot #termcap #NetBSD #FreeBSD #EFI

  6. @b0rk Not only have I had this situation, I also have the reverse on my OpenBSD box, where pressing backspace inside tmux sends a control+h (0x08), so to actually backspace I need to type control+backspace (0x7F)

    It works fine outside tmux. Gotta get that sorted out at some point. #termcap #terminfo

  7. @b0rk Not only have I had this situation, I also have the reverse on my OpenBSD box, where pressing backspace inside tmux sends a control+h (0x08), so to actually backspace I need to type control+backspace (0x7F)

    It works fine outside tmux. Gotta get that sorted out at some point. #termcap #terminfo

  8. @cholling @bean

    This brings back memories of having to set up my own TERMCAP variable for a 910+ many years ago, because the supplied database entry turned out to be wrong, although all of these years later I don't remember exactly what was wrong with it.

    Joy's vi had an "open" mode that, if memory serves, didn't demand/use all of the capabilities that "visual" mode needed.

    #termcap #vi

  9. @bean

    Of course, there is the O'Reilly book on #termcap and #terminfo, which does have that sort of documentation. But it hasn't been updated since 1992, thus tending to reinforce your point. (-:

  10. @bean

    Of course, there is the O'Reilly book on #termcap and #terminfo, which does have that sort of documentation. But it hasn't been updated since 1992, thus tending to reinforce your point. (-:

  11. @zirias @mpts

    Actually you did: "Using termcap/terminfo directly nowadays means using curses." I hope that you understand the point that I was making, now. I don't want to belabour it. (-:

    Things come along that expect either the #termcap compatibility functionality of #terminfo and break on true termcap, or the existence of true terminfo databases. Not often enough to press #FreeBSD to change, it appears, but still on a regular basis.

  12. @zirias @mpts

    Actually you did: "Using termcap/terminfo directly nowadays means using curses." I hope that you understand the point that I was making, now. I don't want to belabour it. (-:

    Things come along that expect either the #termcap compatibility functionality of #terminfo and break on true termcap, or the existence of true terminfo databases. Not often enough to press #FreeBSD to change, it appears, but still on a regular basis.

  13. @_bapt_ @mpts

    It's a good thing that I didn't say that it was, then. (-:

    The whole point is that contrary to what @zirias said there are multiple independent libraries in different softwares and using #termcap/#terminfo directly does *not* mean using (n)curses, nor any lower-level library that it provides.

    The world these days, especially the world outwith C/C++, rather works on the presumption that everyone is terminfo. #FreeBSD has brought porting up short several times.

  14. @_bapt_ @mpts

    It's a good thing that I didn't say that it was, then. (-:

    The whole point is that contrary to what @zirias said there are multiple independent libraries in different softwares and using #termcap/#terminfo directly does *not* mean using (n)curses, nor any lower-level library that it provides.

    The world these days, especially the world outwith C/C++, rather works on the presumption that everyone is terminfo. #FreeBSD has brought porting up short several times.

  15. @zirias @david_chisnall @mpts

    It might be worth checking how well Write-Progress and its ilk work with only #termcap. And colourization of the error stream and suchlike.

    #PowerShell #FreeBSD

  16. @zirias @david_chisnall @mpts

    It might be worth checking how well Write-Progress and its ilk work with only #termcap. And colourization of the error stream and suchlike.

    #PowerShell #FreeBSD

  17. @zirias @mpts

    That's not enough. There are plenty of things that use #termcap/#terminfo directly without using (n)curses. And as you've seen there are cases where the two aren't exactly the same.

    There is a persistent very slow trickle of instances where people come along with something new, which works with terminfo (or its termcap compatibility shims) on every other operating system, and true termcap turns out to be a gotcha in some subtle way. Because no-one targets it any more.

    #FreeBSD

  18. @zirias @mpts

    That's not enough. There are plenty of things that use #termcap/#terminfo directly without using (n)curses. And as you've seen there are cases where the two aren't exactly the same.

    There is a persistent very slow trickle of instances where people come along with something new, which works with terminfo (or its termcap compatibility shims) on every other operating system, and true termcap turns out to be a gotcha in some subtle way. Because no-one targets it any more.

    #FreeBSD

  19. @mpts @zirias

    No. #FreeBSD provides only #termcap as standard right now. #terminfo is only available as a port.

    It's possibly the only mainstream operating system where this is still the case. NetBSD and OpenBSD both provide terminfo. I haven't checked Illumos.

    github.com/freebsd/freebsd-src

  20. @mpts @zirias

    No. #FreeBSD provides only #termcap as standard right now. #terminfo is only available as a port.

    It's possibly the only mainstream operating system where this is still the case. NetBSD and OpenBSD both provide terminfo. I haven't checked Illumos.

    github.com/freebsd/freebsd-src

  21. @JdeBP AFAIK, base #curses in #FreeBSD 14 already uses #terminfo (instead of the bundled #termcap) *if* it is installed (as a package). But sure, having it directly in base and getting rid of termcap would be much nicer.

  22. @JdeBP AFAIK, base in 14 already uses (instead of the bundled ) *if* it is installed (as a package). But sure, having it directly in base and getting rid of termcap would be much nicer.

  23. Never say something is finished 🙈

    Browsing 16colo.rs/ I found some #ansiart file that immediately had my attention because it crashed my #terminfo writer. Turns out attempting fallback to #termcap names makes no sense with terminfo ... although it shouldn't hurt either, but it did with "xterm-256color" on #FreeBSD for the "blink"/"mb" capability, "mb" returned something, but something "else" 🙄 ... so I fixed that.

    This file was strange enough to use it for more testing, it had "blinking" characters (according to #SAUCE), although ignoring that and using bright colors instead looked much more sane, see two screenshots for comparison (oh wow, #xterm can actually blink? although not like #VGA would...)

    Anyways, I found a lot more things to optimize and fix in both my "plain ANSI" and "terminfo" color writers!

    So, there will be #dos2ansi v1.2 soon. Will probably add some small feature first, just "because" 😂

  24. Never say something is finished 🙈

    Browsing 16colo.rs/ I found some file that immediately had my attention because it crashed my writer. Turns out attempting fallback to names makes no sense with terminfo ... although it shouldn't hurt either, but it did with "xterm-256color" on for the "blink"/"mb" capability, "mb" returned something, but something "else" 🙄 ... so I fixed that.

    This file was strange enough to use it for more testing, it had "blinking" characters (according to ), although ignoring that and using bright colors instead looked much more sane, see two screenshots for comparison (oh wow, can actually blink? although not like would...)

    Anyways, I found a lot more things to optimize and fix in both my "plain ANSI" and "terminfo" color writers!

    So, there will be v1.2 soon. Will probably add some small feature first, just "because" 😂

  25. Here's a mystery on #FreeBSD using tput(1) in #xterm with $TERM set to xterm-256colors:

    $ tput colors
    80
    $ tput Co
    256

    I think this *should* query the exact same property, once by its #terminfo name, once by the short #termcap name.

    To add to the confusion, in the "dos2ansi" tool I currently write, I use tigetstr() and tigetnum() and prefer the terminfo names, but fall back to the termcap names. The response I get for "number of colors" there is 256, with the same configuration.

    Anyone got any ideas which weird magic is going on here? 🤔

  26. Here's a mystery on using tput(1) in with $TERM set to xterm-256colors:

    $ tput colors
    80
    $ tput Co
    256

    I think this *should* query the exact same property, once by its name, once by the short name.

    To add to the confusion, in the "dos2ansi" tool I currently write, I use tigetstr() and tigetnum() and prefer the terminfo names, but fall back to the termcap names. The response I get for "number of colors" there is 256, with the same configuration.

    Anyone got any ideas which weird magic is going on here? 🤔

  27. New pre-release of dos2ansi: v0.2

    * Works on #Windows, win32 binary (cross-compiled on #FreeBSD) attached
    * Selectable input #codepage (so far only #cp437, #cp850 and #cp858)
    * Selectable output format, #utf8, #utf16 or #utf16le, with or without #BOM

    Still a few things to add, e.g. use #termcap/#terminfo or Windows Console API for "color output" when applicable ... we will see 😎

    github.com/Zirias/dos2ansi/rel

  28. New pre-release of dos2ansi: v0.2

    * Works on , win32 binary (cross-compiled on ) attached
    * Selectable input (so far only , and )
    * Selectable output format, , or , with or without

    Still a few things to add, e.g. use /#terminfo or Windows Console API for "color output" when applicable ... we will see 😎

    github.com/Zirias/dos2ansi/rel

  29. @n Also, note that #FreeBSD moved from #termcap to #terminfo in newer releases, which might be why the troubleshooting tips you find online are not working.

  30. @n Also, note that #FreeBSD moved from #termcap to #terminfo in newer releases, which might be why the troubleshooting tips you find online are not working.

  31. @Raspberry_Pi Silly question, is there an issue tracker for the 32-bit #Raspbian OS?

    I can find the 64-bit tracker (on Github) but not the 32-bit tracker.

    `tput civis` ("hide cursor") worked in Raspbian OS release `2022-09-22-raspios-buster-armhf-lite` but broke (reports "unknown terminal capability") in `2023-05-03-raspios-buster-armhf-lite`.

    Clearly a #termcap and/or #ncurses issue -- but not quite sure where to start digging.

  32. Hi , has anyone got the WY-120 to work correctly on with any entries? Specifically, it has trouble with backspace/delete, arrow keys and general page layout. ?

    PS: I've seen @veronicaexplains's wonderful video on the WY-55 but this one unforunately seems to have different behaviour.

  33. Hi #hivemind, has anyone got the #Wyse WY-120 #serial #terminal to work correctly on #Linux with any #terminfo entries? Specifically, it has trouble with backspace/delete, arrow keys and general #curses page layout. #Halp?

    PS: I've seen @veronicaexplains's wonderful video on the WY-55 but this one unforunately seems to have different behaviour.

    #retro #retrocomputing #serialport #serialcommunications #termcap #tty #ttyusb #rs232 #ncurses

  34. I just realized that not even terminal output my father's generation did it correctly!

    There are bugs in terminfo. And Stallman only published a manual on the old termcap (not on the newer terminfo).

    If only the existance of termcap and terminfo was a good thing...

    What a mess!

    tldp.org/HOWTO/Text-Terminal-H

    #tty #terminal #linux #gnu #stallman #terminfo #termcap

  35. The update to libepoll-shim fixed the last big problem with porting #foot to #FreeBSD. Now i only have to find the motivation somewhere to manully port the #terminfo file to #termcap. Not looking forward to that one.

  36. @ajroach42
    honestly im still burned out on os9. The old #curses library clone i was porting (or maybe the ancient gnu #termcap) has bugs that i can't find, and i just dread the thought of getting back to it. 😣