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.
https://github.com/u-boot/u-boot/blob/master/drivers/video/console_truetype.c#L480
Just say no to using the BS character for text effects effects in boot loaders, kids! (-:
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.
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.
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.
It might be worth checking how well Write-Progress and its ilk work with only #termcap. And colourization of the error stream and suchlike.
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.
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.
https://github.com/freebsd/freebsd-src/tree/main/share/termcap
Never say something is finished 🙈
Browsing https://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" 😂
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? 🤔
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 😎
@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.
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
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!
@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. 😣
